Zovo State Diagram

Make state diagram

make_state_diagram

Idempotent

Use this when the user wants a UML state diagram or state machine drawn, for example "draw the states of an order" or "make a PDF of this state machine". Takes the diagram text in a line grammar: state Name / state "Long label" as Name / state Name <> / state Name { ... } (composite, nest up to 3); [] -> A (start), A -> [] (end); A -> B: event [guard] / action; A -> A: event (self); note A: text; # comments. When the user describes the machine in words, write it in this grammar first. Returns counts, states, transitions in input order, the machine check (unreachable states, states with no path to the end, non-deterministic transitions), a check on the drawing, the PDF page count, an interactive diagram, and PDF, SVG and CSV downloads. Refuses a line outside the grammar with its line number and token. Up to 80 states and 300 transitions. Does not read fork, join, history or concurrent regions. Download links of large diagrams expire after about 1 hour.

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": "make_state_diagram"
  }
}

Input Schema

Name	Required	Description
`title`	No	Title printed on the diagram and used in file names, up to 80 characters, e.g. "Order lifecycle".
`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".
`page_size`	No	PDF paper, portrait: letter (default) or a4. Example: a4.

Output Schema

Name	Required	Description	Default
`pdf`	Yes
`shown`	No
`title`	Yes
`counts`	Yes
`states`	Yes
`analysis`	Yes
`warnings`	Yes
`downloads`	Yes
`transitions`	Yes
`layout_check`	Yes

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.1/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing what is produced (interactive diagram, PDF/SVG/CSV), error behavior ('Refuses a line outside the grammar with its line number and token'), hard limits (80 states, 300 transitions), unsupported constructs (fork, join, history, concurrent regions), and a real operational caveat that large-diagram download links expire after about an hour.

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 use case and examples, then the grammar, then returns and limits — a sensible order for an agent scanning top-down. It is dense and duplicates the grammar block already present in the diagram parameter's schema description, which is wasted space in an otherwise efficient definition.

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?

An output schema exists, yet the description still caps off the picture with limits, rejection behavior, and link expiry, so an agent knows what a call will yield and where it will fail. Nothing material is missing for a grammar-driven generator with three well-documented parameters.

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 coverage is 100%, so title, diagram, and page_size are already fully documented, including the grammar and the enum values. The description largely restates the grammar rather than adding parameter meaning beyond it; the only genuine additions are the 80-state/300-transition caps, which the schema does not express.

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

Purpose4/5

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

States a specific verb and resource ('a UML state diagram or state machine drawn') and anchors it with two natural-language example requests, so an agent can match user intent immediately. It does not mention the sibling check_state_diagram even though the description advertises a machine check, so differentiation is left implicit.

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

Usage Guidelines4/5

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

Gives a clear trigger condition ('Use this when the user wants...') plus a procedural instruction: when the user describes the machine in words, write it in the grammar first. No exclusions or alternative routing (e.g., use check_state_diagram to validate an existing diagram) are stated.

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?