@endiagram/mcp 0.3.14 → 0.3.16

package/README.md

@@ -76,7 +76,7 @@ smithery mcp add dushyant30suthar/endiagram
 
 ## Tools
 
-Six questions about any system, plus a render tool. Every tool takes `source` (EN code or `.en`/`.txt` file path).
+Six questions about any system, plus a render tool. Every tool takes `source` (EN code or `.en`/`.txt` file path). Tool names are shorthand, not specs — read each description before calling; `compose` and `equivalent` are mode-based, not general analyzers.
 
 | Tool | What it answers | Levers |
 |------|-----------------|--------|
@@ -86,7 +86,7 @@ Six questions about any system, plus a render tool. Every tool takes `source` (E
 | `reachable` | Can X reach Y? Path, distance, boundary crossings. `from`/`to` accept entity or action names. | `defense_nodes=a,b,c` checks whether guards cover every path. |
 | `equivalent` | Are two systems the same, or what changes if I change this one? | Compare mode (`source_a`+`source_b`): edit distance + spectral cospectrality. Evolve mode (`source`+`patch`): plain EN adds; `- name` removes; same-name replaces. |
 | `compose` | How do parts combine (merge) or how does a part stand alone (extract)? | Merge: `source_a`+`source_b`+`links` (`a.entity=b.entity` per line). Extract: `source`+`subsystem` (names come from `structure.subsystems`). |
-| `render` | SVG or PNG diagram. Only call when the user asks to visualize. | Themes: `Blueprint`, `Swiss`, `Bauhaus`, `Brutalist` (each ± `isDark`) or seeded `Nord`, `Catppuccin`. `structure_layers` bitmask (1=subsystems, 2=pipelines, 4=cycles, 8=forks, 16=joins, 32=hubs, 64=deadlock, 128=overflow). `color=#RRGGBB` for a custom palette. |
+| `render` | SVG or PNG diagram. Only call when the user asks to visualize. | Themes: `Editorial`, `Primer`, `Carbon` (each ± `isDark`) or seed-derived from `color=#RRGGBB`. `structure_layers` bitmask (1=subsystems, 2=pipelines, 4=cycles, 8=forks, 16=joins, 32=hubs, 64=deadlock, 128=overflow). |
 
 ## EN Syntax
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@endiagram/mcp",
-  "version": "0.3.14",
+  "version": "0.3.16",
   "description": "MCP server for EN Diagram — six questions about any system (structure, invariants, liveness, reachability, equivalence, composition) answered with graph theory. Plus a render tool. Pure math, no AI inside the computation.",
   "type": "module",
   "main": "dist/index.js",

package/tools.json

@@ -1,5 +1,5 @@
 {
-  "instructions": "EN Diagram — structural verification for concurrent systems. Pure math, no AI.\n\n## Syntax\nOne statement per line:\n  actor do: action needs: input1, input2 yields: output1, output2 at: context\n\n- All five parts required.\n- Names span words; whitespace preserved. Quote only if name contains `,`, `:`, or `#`.\n- Shared names = connections: one action's `yields:` matching another's `needs:` wires them automatically. String equality is the link. IMPORTANT: use natural-language names with spaces (`dln proof 1`), not camelCase, snake_case, or prefixes — transforming the name fragments what should be one entity and the whole analysis will be wasted.\n- Multi-actor: `a, b do: action needs: X yields: Y` = one joint action. Identical statements merge.\n- `#` starts a comment.\n\n## Modeling\nSame name = same thing. Put all required inputs in one `needs:` list (AND). Give two actions the same yield-name to offer alternatives (OR). Sequence = one action consuming another's yield. Re-yield stateful resources to keep them persistent; one-shot data stays consumed. Model at the real atomic granularity — split only when the pieces could be accessed independently.\n\n## Targeted modeling\nOne concern per en session. For broad input, pick one subsystem in the user's own terms (a named module, a specific flow, a file) — not a tool or en concept. Model it, report findings plainly, then offer next areas in the same domain terms. Compose narrow models to build larger systems.\n\n## How to use them\nEach call's output — node names, structural properties, verdicts — feeds the next call. Read the output; pick the next tool by what was surprising or unverified, not by running through the list. IMPORTANT: chain calls — keep going as long as something's worth following. Don't fire all six on the same `en` either.\n\nSpeak in the user's domain, not in graph theory. Only call render when the user explicitly asks to visualize.",
+  "instructions": "EN Diagram — structural verification for concurrent systems. Pure math, no AI.\n\n## Syntax\nOne statement per line:\n  actor do: action needs: input1, input2 yields: output1, output2 at: context\n\n- All five parts required.\n- Names span words; whitespace preserved. Quote only if name contains `,`, `:`, or `#`.\n- Shared names = connections: one action's `yields:` matching another's `needs:` wires them automatically. String equality is the link. IMPORTANT: use natural-language names with spaces (`dln proof 1`), not camelCase, snake_case, or prefixes — transforming the name fragments what should be one entity and the whole analysis will be wasted.\n- Multi-actor: `a, b do: action needs: X yields: Y` = one joint action. Identical statements merge.\n- `#` starts a comment.\n\n## Modeling\nSame name = same thing. Put all required inputs in one `needs:` list (AND). Give two actions the same yield-name to offer alternatives (OR). Sequence = one action consuming another's yield. Re-yield stateful resources to keep them persistent; one-shot data stays consumed. Model at the real atomic granularity — split only when the pieces could be accessed independently.\n\n## Targeted modeling\nOne concern per en session. For broad input, pick one subsystem in the user's own terms (a named module, a specific flow, a file) — not a tool or en concept. Model it, report findings plainly, then offer next areas in the same domain terms. Compose narrow models to build larger systems.\n\n## How to use them\nEach call's output — node names, structural properties, verdicts — feeds the next call. Read the output; pick the next tool by what was surprising or unverified, not by running through the list. Tool names are shorthand, not specs — read each description before calling; `compose` and `equivalent` are mode-based, not general analyzers. IMPORTANT: chain calls — keep going as long as something's worth following. Don't fire all six on the same `en` either.\n\nSpeak in the user's domain, not in graph theory. Only call render when the user explicitly asks to visualize.",
   "tools": [
     {
       "name": "structure",
@@ -61,7 +61,7 @@
       "description": "SVG or PNG diagram. Only call when user explicitly asks to visualize. The rendered image is delivered to the user, not injected into the model's context. See the server instructions for EN language syntax.",
       "parameters": [
         {"name": "source", "type": "string", "description": "EN source code, or path to .en/.txt file", "required": true},
-        {"name": "theme", "type": "string", "description": "Color theme. Named presets (curated, each with light + dark variants; pair with isDark): Blueprint (architectural drafting paper), Swiss (International Typographic — black/white with red accent), Bauhaus (primary-color geometric), Brutalist (high-contrast stark). Seed-derived (auto-generated palettes from themes.json): Nord, Catppuccin, etc. Or pass 'dark'/'light' for the default theme in that mode. Overridden by `color` if provided.", "required": false},
+        {"name": "theme", "type": "string", "description": "Color theme. Curated presets (each with light + dark variants; pair with `isDark`): `Editorial` (stone paper + rust focal, adapted from cathrynlavery/diagram-design), `Primer` (GitHub design system — blue accent, data-vis roles), `Carbon` (IBM Carbon — sharp 0px corners, corporate blue). Or seed-derived palettes generated on the fly from `color`. Pass 'dark'/'light' for the default variant. Overridden by `color` if provided.", "required": false},
         {"name": "isDark", "type": "string", "description": "true or false. Selects the dark or light variant of a named preset. If omitted, defaults to dark unless theme=light.", "required": false},
         {"name": "type", "type": "string", "description": "Output format: png (default) or svg. PNG is rasterized server-side via Batik.", "required": false},
         {"name": "quality", "type": "string", "description": "Output quality: small, mid, or max", "required": false},