Zovo Swimlane

Make swimlane diagram

make_swimlane

Read-onlyIdempotent

Use this when the user wants a swimlane diagram, cross-functional flowchart or process map with roles, teams or systems as lanes, for example "draw our order process as a swimlane" or "make a swimlane PDF of who does what". Takes lanes in order, steps (id, lane, text, kind: step, decision, start or end) and links (from, to, label; branches that leave a decision need labels), plus orientation (horizontal: lanes as rows, flow left to right; vertical: lanes as columns, flow top down), page size and title. Returns counts, each step's lane and flow position, unreachable steps, steps with no path to an end, loops, a geometry check (steps outside their lane, overlapping steps and labels, lines crossing a step), an interactive diagram, and PDF, SVG and CSV downloads. Refuses, with the reason: unknown lanes or step ids, duplicate lanes, ids or links, a link from a step to itself, a missing start or end step, an end step with outgoing links, decisions with fewer than 2 outgoing links or with unlabeled or repeated branch labels. When one step with its branch labels is wider than the page at 6 pt, it returns the SVG and CSV without a PDF and says why. Up to 12 lanes, 150 steps, 300 links. Does not draw plain flowcharts without lanes, BPMN message flows, org charts or sequence diagrams. 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": {
      "lanes": "<lanes>",
      "steps": "<steps>"
    },
    "name": "make_swimlane"
  }
}

Input Schema

Name	Required	Description
`lanes`	Yes	Lane names in display order, 2 to 12, each up to 40 characters, e.g. ["Customer", "Sales", "Warehouse"]. A lane is usually a role, team or system.
`links`	No	Arrows between step ids, up to 300, e.g. [{"from":"s1","to":"s2"},{"from":"s2","to":"s3","label":"yes"}].
`steps`	Yes	Steps, 1 to 150, e.g. [{"id":"s1","lane":"Customer","text":"Place order","kind":"start"},{"id":"s2","lane":"Sales","text":"Credit OK?","kind":"decision"}].
`title`	No	Title on the diagram and in file names, up to 80 characters, e.g. "Order to cash".
`page_size`	No	PDF page: letter (default), a4 or tabloid (11 x 17 in). Landscape unless portrait needs fewer pages.
`orientation`	No	horizontal (default): lanes are rows and the flow runs left to right. vertical: lanes are columns and the flow runs top down.

Output Schema

Name	Required	Description	Default
`pdf`	Yes
`lanes`	Yes
`loops`	Yes
`shown`	No
`steps`	Yes
`title`	Yes
`counts`	Yes
`issues`	Yes
`warnings`	Yes
`downloads`	Yes
`orientation`	Yes
`unreachable`	Yes
`layout_check`	Yes
`flow_positions`	Yes
`no_path_to_end`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses concrete operational behavior: exact artifacts returned, a full enumerated refusal list with reasons, capacity ceilings (12 lanes / 150 steps / 300 links), a graceful degradation path (SVG+CSV without PDF when a step plus branch labels exceeds page width at 6 pt), and expiry of download links after roughly 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?

Usage framing and example utterances are correctly front-loaded, and nearly every clause carries decision-relevant information (inputs, outputs, refusals, limits, degradation). The middle is a single very long sentence packing inputs, return values and refusal conditions together, which slows scanning and would be easier to absorb split into short structured lines.

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 6-parameter generative tool with an output schema, this is thorough: the agent learns the input contract, what comes back, what causes a hard refusal, what causes partial output, and the size ceilings that will reject oversized requests. Even the operational caveat about expiring download links is covered, leaving no material gap before invocation.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description nonetheless adds meaning by tying lanes to display order, spelling out step kinds and the decision-link labeling rule, and clarifying that horizontal means lanes-as-rows with left-to-right flow while vertical means lanes-as-columns flowing top-down. The remaining value is duplication of the schema, so it does not reach the top of the scale.

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?

The description opens with a concrete verb and artifact ('Use this when the user wants a swimlane diagram') and enumerates synonyms (cross-functional flowchart, process map with roles/teams/systems as lanes) plus two sample user utterances. It also sketches scope by exclusion (no plain flowcharts, BPMN message flows, org charts, sequence diagrams). It never names the sibling check_swimlane, so the agent must infer the draw-vs-validate split itself.

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?

When-to-use is stated explicitly and idiomatically ('"draw our order process as a swimlane"'), and the closing sentence lists diagram types this tool will not produce, which functions as a when-not rule. What is missing is routing guidance toward the alternative check_swimlane, leaving the agent to guess whether to validate or generate when both could apply.

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

All Zovo Swimlane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?