Zovo Use Case Diagram

Make use case diagram

make_use_case_diagram

Read-onlyIdempotent

Use this when the user wants a UML use case diagram drawn, for example "draw the use cases of an online shop" or "make a PDF use case diagram of this system". Takes the diagram text in a line grammar: actor Name / actor "Long name" as A; usecase Name / usecase "Text" as UC1; system "Name" { ... } (use cases inside belong to it; not nested); A -- UC1 (association); UC1 ..> UC2 : include; UC3 ..> UC1 : extend; Admin --|> User (actor generalization); note UC1: text; # comments. When the user describes the diagram in words, write it in this grammar first. Returns counts, elements, relations in input order, the diagram check (actors with no use case, use cases no actor reaches, include/extend cycles), a check on the drawing, the PDF page count, an interactive diagram, and PDF, SVG and CSV downloads. Refuses a line outside the grammar, unknown names, relations between the wrong kinds of element and generalization cycles, with the line number and token. Up to 30 actors, 80 use cases, 6 systems and 300 relations. Does not read use case generalization, packages or nested systems. 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_use_case_diagram"
  }
}

Input Schema

Name	Required	Description
`title`	No	Title printed on the diagram and used in file names, up to 80 characters, e.g. "Online shop".
`diagram`	Yes	The use case diagram in this line grammar, one statement per line, up to 40,000 characters: actor Name \| actor "Long name" as A \| usecase Name \| usecase "Text" as UC1 \| system "Name" { ... } (use case lines inside belong to that system; not nested) \| A -- UC1 (association) \| UC1 ..> UC2 : include \| UC3 ..> UC1 : extend \| Admin --\|> User (actor generalization) \| note UC1: text \| # comment. Declare each actor and use case before or after use. Example: "actor Customer\nsystem \"Shop\" {\nusecase \"Place order\" as Order\nusecase Pay\n}\nCustomer -- Order\nOrder ..> Pay : include".
`page_size`	No	PDF paper: letter (default) or a4. The PDF is portrait, or landscape when the diagram is too wide for portrait. Example: a4.

Output Schema

Name	Required	Description	Default
`pdf`	Yes
`shown`	No
`title`	Yes
`counts`	Yes
`analysis`	Yes
`elements`	Yes
`warnings`	Yes
`downloads`	Yes
`relations`	Yes
`layout_check`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safe-read, idempotent, closed-world profile, so the bar is lower; the description still adds substantial context: the limits (30 actors, 80 use cases, 6 systems, 300 relations), the rejection behavior with line number and token, the returned artifacts, and the ~1 hour expiry of download links for large diagrams. The main unaddressed behavior is how validation failures are surfaced in the response structure, which the output schema presumably covers.

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

Conciseness3/5

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

Front-loaded with the trigger and examples, which is good, but the grammar block is dense and duplicated almost verbatim from the diagram parameter's schema description, making the description longer than needed. Every sentence is informative, yet the redundancy costs conciseness.

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 generative tool with an output schema, the description covers trigger, input format, limits, failure modes, and artifacts, which is everything an agent needs to call it correctly. Nothing important is left to inference.

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%, so the schema already documents title, diagram and page_size including the grammar and an example. The description repeats the grammar and mentions the line syntax, adding orientation but little beyond the schema; baseline 3 applies.

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 (draw a UML use case diagram) with concrete example requests, and the grammar of the input is spelled out. An agent can immediately tell this generates diagrams rather than validating them, distinguishing it from check_use_case_diagram.

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?

Explicitly says when to use it ("Use this when the user wants a UML use case diagram drawn") and adds the key workflow instruction: when the user describes the diagram in words, write it in this grammar first. It also lists what is out of scope (no use case generalization, packages, nested systems).

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

All Zovo Use Case 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?