@endiagram/mcp 0.2.17 → 0.2.18
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/package.json +1 -1
- package/tools.json +1 -1
package/package.json
CHANGED
package/tools.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"instructions": "EN Diagram is a deterministic structural analysis engine. No AI inside.\n\nTo describe a system, write one statement per line:\n actor do: action needs: input1, input2 yields: output1, output2\n\nShared names between yields and needs create connections automatically. Multi-word names work fine. Use commas to separate multiple inputs or outputs.\n\nThe engine computes structural truth from the description — the tool outputs are raw mathematical findings. Translate them into the language of the system being analyzed. If analyzing a payment flow, say 'the payment gateway is structurally isolated' not 'node X has high centrality'. Speak in the user's domain, not in graph theory.\n\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. One tool surfaces a fact. The next tool explains it. The next stress-tests it. Keep narrowing until you reach the root cause. One thread followed to completion beats ten shallow observations.\n\nDo not stop at one tool call. Do not summarize after one result. 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.",
|
|
2
|
+
"instructions": "EN Diagram is a deterministic structural analysis engine. No AI inside.\n\nTo describe a system, write one statement per line:\n actor do: action needs: input1, input2 yields: output1, output2 at: context\n\nShared names between yields and needs create connections automatically. Multi-word names work fine. Use commas to separate multiple inputs or outputs. at: scopes the action to a context (service, team, region, domain, layer — whatever boundary fits the system).\n\nThe engine computes structural truth from the description — the tool outputs are raw mathematical findings. Translate them into the language of the system being analyzed. If analyzing a payment flow, say 'the payment gateway is structurally isolated' not 'node X has high centrality'. Speak in the user's domain, not in graph theory.\n\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. One tool surfaces a fact. The next tool explains it. The next stress-tests it. Keep narrowing until you reach the root cause. One thread followed to completion beats ten shallow observations.\n\nDo not stop at one tool call. Do not summarize after one result. 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.",
|
|
3
3
|
"tools": [
|
|
4
4
|
{
|
|
5
5
|
"name": "analyze",
|