@modudraft/mcp 0.21.0 → 0.22.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +15 -1
- package/dist/index.js +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -96,6 +96,10 @@ Every MCP tool is listed by default. If that is too much context for your client
|
|
|
96
96
|
- `load_toolset(name)` adds a group at runtime and sends a tools-changed notification. If your client doesn't refresh tools after `load_toolset`, set `MODUDRAFT_TOOLSETS` instead.
|
|
97
97
|
- Calling any tool by name always works, even when it isn't listed: the server loads its group and runs it.
|
|
98
98
|
|
|
99
|
+
### Upgrading to 0.22.0
|
|
100
|
+
|
|
101
|
+
- Adds Structurizr import: `import_file` and `import_directory` read a `workspace.dsl` (with its `!include`d files) or a Structurizr `workspace.json`, and re-importing updates the diagram in place. `sync_project`, `watch_project` and the `modudraft-mcp check` command also compare a `workspace.dsl` source. Nothing is removed.
|
|
102
|
+
|
|
99
103
|
### Upgrading to 0.21.0
|
|
100
104
|
|
|
101
105
|
- Architecture diagrams have levels: a component can contain other items. New optional inputs: `inside` (a component id or label; empty or `null` means the top level) on `add_node`, `bulk_add_nodes`, `add_boundary`, `add_note` and `update_node`; `c4_kind` and `description` on `update_node`; `inside: "delete" | "lift"` on `delete_node`; `level` on `render_diagram_text`, `layout_diagram`, `export_mermaid`, `export_plantuml`, `export_drawio` and `export_to_file`.
|
|
@@ -282,7 +286,7 @@ The old `request_body`, `request_format`, `body`, `body_format` and top-level `r
|
|
|
282
286
|
| `import_file` | Import a file into a diagram - auto-detects format. Re-importing the same file updates it in place (see [Re-import](#re-import)) |
|
|
283
287
|
|
|
284
288
|
**Supported import formats:**
|
|
285
|
-
- **Architecture:** `docker-compose.yml` → nodes + edges
|
|
289
|
+
- **Architecture:** `docker-compose.yml` → nodes + edges; a Structurizr workspace (`workspace.dsl` with its `!include`d files, or `workspace.json`) → levels, groups, relationships and dynamic views as sequences, with deployment on the cloud tab and docs/ADRs in the notes
|
|
286
290
|
- **Cloud:** Kubernetes YAML, Terraform `.tf`, AWS CloudFormation YAML/JSON
|
|
287
291
|
- **DB schema:** SQL DDL, `schema.prisma`, DBML, `schema.rb` (Rails), TypeORM entities, SQLAlchemy models, dbt `schema.yml`
|
|
288
292
|
- **API:** OpenAPI 2.x/3.x, GraphQL SDL, Protocol Buffers `.proto`, Postman collection, Insomnia export v4, AsyncAPI
|
|
@@ -413,6 +417,16 @@ A node with an explicit `x`/`y` (`add_node`, `add_boundary`) is pinned. Nodes th
|
|
|
413
417
|
|
|
414
418
|
Items from other files are never touched. Existing items without import history whose name matches an item in the file (a table, endpoint, service or resource of the same name) are adopted and from then on kept in sync with the file; the response lists them under `adopted` in `changes`. Other items you made by hand are never touched. `import_directory` reports each file's `changes`, `also_removed` and `warnings`, plus a `removed` total. A parse that finds nothing is refused unless you pass `allow_empty: true`, so an empty or broken file cannot wipe a diagram. `target_tab` accepts `db-schema`, `api`, `cloud` or `network`. Terraform dependencies are recorded as `config.dependsOn`.
|
|
415
419
|
|
|
420
|
+
**Structurizr workspaces.** Items are matched by their Structurizr canonical names (for example `Container://Shop.Web Store`), so matched items keep their id, position and pin. A few things follow from that:
|
|
421
|
+
|
|
422
|
+
- Renaming a software system or container in the DSL gives it, and everything inside it, a new name: they are imported again as new items (the positions inside it start fresh) and the old ones are removed. Items you made by hand inside a removed system or container are moved up a level, not deleted.
|
|
423
|
+
- A `runsOn` link stays when you remove the `containerInstance` that set it, as long as its deployment node still exists. Links you set by hand are kept too.
|
|
424
|
+
- The workspace's documentation and ADRs go into one marked block of the notes per workspace, replaced on re-import. Changes to docs, ADRs or dynamic views only are not reported as drift by `sync_project` or the CI check (applying a sync still updates the notes block and the sequences).
|
|
425
|
+
- A colour the workspace sets wins on re-import; a colour you set by hand on an item the workspace gives no colour stays, and is not drift.
|
|
426
|
+
- A diagram made by importing the workspace on the web is picked up by the first `import_file` of the same workspace: its items are matched, not added a second time.
|
|
427
|
+
- Only the files the workspace uses (`!include`, `!docs` and `!adrs` targets, and the `.json` files beside it, checked for a layout) are read from its folder, up to 50 MB in all; `node_modules` and `.git` are skipped. A Structurizr `workspace.json` may be up to 20 MB (other files: 2 MB).
|
|
428
|
+
- `watch_project` / `check_project_drift` track the workspace file itself (`workspace.dsl`), not the files it includes. After editing an included file, run `sync_project` (or the CI check), which reads the whole workspace, to see the change.
|
|
429
|
+
|
|
416
430
|
## Project drift
|
|
417
431
|
|
|
418
432
|
`check_project_drift` only reports; it no longer consumes the drift. Drift stays reported until you pass `acknowledge: true`. Re-importing a modified file with `import_file` also clears it for that file; a new file stays reported as added until you acknowledge. A truncated scan (too many files) is flagged in the result.
|