@endiagram/mcp 0.3.13 → 0.3.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@endiagram/mcp",
-  "version": "0.3.13",
+  "version": "0.3.14",
   "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\nEvery tool output contains node names, values, and structural properties that can be fed directly into other tools. Read the output. Find the surprising node, the unexpected value, the structural anomaly. Then pick the tool that investigates THAT specific finding.\n\nDo not stop at one tool call. The first call reveals the structure — the real insight comes from the second, third, fourth call that digs into what the first one found.\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. 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",