Zovo State Diagram

Check state diagram text

check_state_diagram

Read-onlyIdempotent

Use this when the user wants state machine text checked without a drawing, for example "which states are unreachable?" or "check my state diagram for dead ends". Takes the same diagram text as make_state_diagram. Returns ready true or false; when a line breaks the grammar, the line number, the token and the reason; otherwise the states with incoming and outgoing transition counts, states not reachable from the start, states with no path to the end (both by breadth-first search; a composite state is entered through its own start), and transitions that leave the same state on the same event and guard. Does not draw the diagram or make files, and does not read fork, join, history or concurrent regions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "diagram": "<diagram>"
    },
    "name": "check_state_diagram"
  }
}

Input Schema

Name	Required	Description	Default
`diagram`	Yes	The state machine in this line grammar, one statement per line, up to 40,000 characters: state Name \| state "Long label" as Name \| state Name <<choice>> \| state Name { ... } (composite, nest up to 3); [] -> A (start), A -> [] (end); A -> B: event [guard] / action (after ':' the event is required, then an optional [guard] and / action in that order; only a transition out of a <<choice>> state may have a [guard] without an event); note A: text; # comments. Declare each state before or after use. Example: "state Idle\nstate Running\n[] -> Idle\nIdle -> Running: start [ready] / log\nRunning -> Idle: stop\nRunning -> []: shutdown".

Output Schema

Name	Required	Description	Default
`error`	Yes
`notes`	Yes
`ready`	Yes
`shown`	No
`counts`	No
`limits`	Yes
`states`	Yes
`grammar`	Yes
`analysis`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / diagram / description

Previous value: -"The state machine in this line grammar, one statement per line, up to 40,000 characters: state Name | state \"Long label\" as Name | state Name <<choice>> | state Name { ... } (composite, nest up to 3); [*] -> A (start), A -> [*] (end); A -> B: event [guard] / action (after ':' an event, a [guard], a / action, or several in that order; a guard alone suits a transition out of a choice); note A: text; # comments. Declare each state before or after use. Example: \"state Idle\\nstate Running\\n[*] -> Idle\\nIdle -> Running: start [ready] / log\\nRunning -> Idle: stop\\nRunning -> [*]: shutdown\"."New value: +"The state machine in this line grammar, one statement per line, up to 40,000 characters: state Name | state \"Long label\" as Name | state Name <<choice>> | state Name { ... } (composite, nest up to 3); [*] -> A (start), A -> [*] (end); A -> B: event [guard] / action (after ':' the event is required, then an optional [guard] and / action in that order; only a transition out of a <<choice>> state may have a [guard] without an event); note A: text; # comments. Declare each state before or after use. Example: \"state Idle\\nstate Running\\n[*] -> Idle\\nIdle -> Running: start [ready] / log\\nRunning -> Idle: stop\\nRunning -> [*]: shutdown\"."

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the ready true/false shape, the parse-error payload (line number, token, reason), the analysis results (in/out transition counts, unreachable states, dead ends, nondeterminism detection) and the BFS method including composite-state entry. It also discloses scope limits – no drawing or file creation, and no handling of fork, join, history or concurrent regions – which the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger and an example before the return-value detail, and no sentence is filler. The return-value enumeration is a long run-on list that could be broken up, but it is dense information rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter validator with an output schema, the description still anticipates what the agent needs – error shape, analysis semantics, and explicit unsupported constructs – so nothing an agent would need before calling is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter's grammar is fully documented in the schema, so the description only adds a cross-reference ('takes the same diagram text as make_state_diagram'). That is a minor aid, not new semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('state machine text checked without a drawing') and explicitly contrasts itself with the sibling by noting it takes 'the same diagram text as make_state_diagram' but produces no drawing. An agent can distinguish it from the make tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Use this when the user wants state machine text checked without a drawing') plus two concrete user phrasings and a named alternative for the drawing case. Both when-to-use and when-not are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zovo State Diagram tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?