Jardis via MCP

Everything the Designer can do in the browser, you can also drive headless: via the MCP server. An AI agent drives the same workspace without a browser: the same sequence, just via MCP calls instead of UI clicks.

jardis mcp

On startup, the process binds to a project root (the workspace). It is stateless: every call operates against the current on-disk state.

Tools vs. Resources

The two basic building blocks:

• Tools = actions (create, save, validate, build). Writing; they return a result or a structured error.
• Resources = read-only projections of the current on-disk state (e.g. jardis://tree, jardis://schema/{domain}/{bc}). No push, no subscribe: after a write you call the resource again to see the effect.

The Workflow

The same chain as in the Designer, step by step via tools; every step can be checked beforehand against its own resource:

1. Workspace — the process points at the project root. If the domain structure is missing, build it structurally first (domain / BC / aggregate), then the schema.
2. Import schema (import_schema) — a DB connection or a hand-written Schema.yaml into the bounded context.
3. Save aggregate (save_aggregate) — the Designer graph: entities, relations, keys.
4. Confirm naming (save_naming) — the BC's field-mapping conventions, before the build.
5. Model process (create_process / save_process / validate_process) — build the BC process graph, iterate, validate structurally.
6. Build (build) — long-running, generates the code tree on disk and sends progress notifications.
7. Read code — via the resource templates code-tree and code-file (chunked, with an offset/limit window), the replacement for "open in editor".

The strategic layer is also fully reachable: save_glossary, save_steckbrief, the planned BCs (create_planned_bc … promote_bc) and the Context Map edges (create_context_map_edge …). The drift check sits read-only under jardis://context-map/{domain}/drift: including call evidence per real edge.

Retrieve the pattern catalog, don't hard-wire it

An agent reads the eight canonical DDD patterns as a resource (context-map-patterns) instead of hard-coding the names.

The GUI Replacement

Browser affordances without their own MCP button become data operations:

• Choose output directory (instead of a file dialog) → update_domain_manifest, field outputDir.
• Open in editor (instead of an IDE) → the code-file resource, read chunked.
• Switch project (instead of the workspace switcher) → no in-process switch. One workspace = one process: for a different root you start a second jardis mcp.

Workspace registry

The host-wide registry of known projects (for the UI start screen) deliberately has no MCP tool. For a different workspace, simply start a new process: registry membership is irrelevant to MCP.

Error Envelopes

Every error arrives as a structured envelope, never as a bare string: code, optionally ruleId + location (for validator findings), message (human-readable) and hint (actionable).

Code	Meaning
CONFLICT	Resource was changed concurrently (mtime) — reload + retry, or treat as confirmation.
CONFIRM_REQUIRED	Destructive call (delete/rename with real impact) — needs an explicit confirm flag; check the preview resource first.
BUILD_RUNNING	Parallel build on the same scope.
DRAFT_EXISTS	An unsaved draft blocks the build.
VALIDATION	Structural finding — details in the details field, don't resend unchanged.
NOT_FOUND	Target doesn't exist.

For VALIDATION and CONFIRM_REQUIRED: fix the cause resp. supply the confirmation first, never resend unchanged.

Depth on design thinking and Sorte-A usage is in the jardis-mcp-consumer skill (see Skills).