Zovo Sankey

Make Sankey diagram

make_sankey

Read-onlyIdempotent

Use this when the user wants a Sankey diagram, flow diagram or alluvial-style chart of amounts moving between stages, for example a budget (income to spending), an energy balance, a sales funnel or website traffic paths. Takes flows as from, to and amount (pasted text or a list), up to 200 flows and 100 nodes, plus a title, unit, node order, link colour and PDF page size. Returns node totals, a balance table, totals per column, a proportion check of link widths and node heights, label overlap results, an interactive diagram, and SVG, PDF and CSV downloads. Refuses loops, flows from a node to itself, zero or negative amounts and ambiguous amounts such as 1,234 without a decimal_mark. Does not read files, fetch data from other apps or save diagrams.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "make_sankey"
  }
}

Input Schema

Name	Required	Description
`unit`	No	Unit or currency shown with amounts, e.g. "$", "€", "kWh" or "users". A single currency symbol goes before the number, other units after it.
`flows`	No	Alternative to flows_text: [{"from":"Salary","to":"Budget","amount":"4000"}]. The amount may be text ("1,250.50") or a number. Up to 200 flows and 100 different nodes.
`title`	No	Diagram title, e.g. "Monthly budget". Default "Sankey diagram".
`color_by`	No	Link colour, e.g. source (default: each link takes the colour of the node it leaves) or target (the node it enters).
`page_size`	No	PDF page: auto (default, the page fits the diagram at full size up to the 200 in PDF page limit; a larger diagram is scaled down and the result says so), letter or a4 (scaled to one page).
`flows_text`	No	Flows pasted as text, one per line: from, to, amount, e.g. "Salary,Budget,4000\nBudget,Rent,1500\nBudget,Savings,800". Comma, tab or semicolon between values; an optional header row is skipped; names with commas go in double quotes. Up to 200 lines. Give this or flows.
`node_order`	No	auto (default): nodes in each column are arranged to reduce crossings; given: nodes keep the order they first appear in the flows.
`decimal_mark`	No	Decimal mark of the amounts, "." (1,234.50) or "," (1.234,50). Needed only when an amount such as 1,234 or 1.234 could be read both ways; otherwise it is read from the amounts.

Output Schema

Name	Required	Description	Default
`pdf`	Yes
`unit`	Yes
`nodes`	Yes
`title`	Yes
`labels`	Yes
`balance`	Yes
`size_px`	Yes
`color_by`	Yes
`warnings`	Yes
`downloads`	Yes
`page_size`	Yes
`flow_count`	Yes
`link_count`	Yes
`node_count`	Yes
`node_order`	Yes
`sinks_total`	Yes
`column_count`	Yes
`decimal_mark`	Yes
`layout_check`	Yes
`column_totals`	Yes
`preview_count`	No
`sources_total`	Yes
`duplicates_merged`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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 already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds substantial behavior: hard limits (200 flows, 100 nodes), explicit refusal cases (loops, self-flows, zero or negative amounts, ambiguous '1,234' without decimal_mark), auto-scaling behavior for oversized PDF pages, and a clear statement that it does not save outputs. That is well beyond what the annotations 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 triggering condition, then the input contract, outputs, and refusals in descending priority — no filler sentences and every clause carries information. It is on the long side and itemizes return values even though an output schema exists, which is mild redundancy against the stated rubric.

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 an 8-parameter generation tool with an output schema, the description covers input contract, limits, failure modes, and scope boundaries without needing to re-document return fields. An agent has everything required to decide to call it and to construct valid arguments.

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 coverage is 100%, so the baseline is 3; the description earns more by tying parameters to behavior rather than restating them — e.g. it explains the from/to/amount contract, the 200-flow/100-node ceiling, and the specific ambiguity that forces the decimal_mark parameter. It does not add format detail for page_size or color_by 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+resource ('Sankey diagram, flow diagram or alluvial-style chart') plus concrete example domains (budget, energy balance, sales funnel, traffic paths) and the exact data shape it consumes (from/to/amount). An agent can distinguish this from the validation-focused sibling check_flows purely from the description.

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?

Opens with an explicit triggering condition ('Use this when the user wants...') and closes with exclusions ('Does not read files, fetch data from other apps or save diagrams'), which is strong when-to-use/when-not coverage. It never names the sibling check_flows as the alternative for a validate-only request, so the routing is not fully closed.

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

All Zovo Sankey 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?