Skip to main content
Glama
Sign In

ChartAnt

by net.chartant
OverviewDiscussionsAdmin

Create a chart that stays updated

create_living_chart

Save a chart, map, dashboard or report with a fixed link that always shows its latest data. Use when the user wants a chart they will update later, embed in a page, or send to Slack/email when it changes. 'chart' is the same JSON as the generate_* tools: { type, title, data, ... } (e.g. { type: 'line', data: [{ time: 'Mon', value: 3 }] }). For a report with several charts and text, send { type: 'report', title, subtitle?, blocks: [...] } with the same blocks as create_report: its fixed link is a page, with PDF and PowerPoint download links using the same report ID, and a PNG of the whole report. Returns the id and its fixed link. Needs the user's API key in the connector URL.

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": {
      "name": "<name>",
      "chart": "<chart>"
    },
    "name": "create_living_chart"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesA short name, e.g. 'Weekly sign-ups'.
chartYesChart definition: type, title, data and options, as for the generate_* tools.
stampNoDraw the last-updated timestamp in the title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (which only declare a non-destructive write), the description explains the persistent-link behavior, what the report link resolves to (a page with PDF/PowerPoint download links and a PNG), the return value (id and fixed link), and the auth requirement (user's API key in the connector URL). That is substantive behavioral context an agent could not derive from the annotations.

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?

The critical facts (fixed link, when to use, payload shape, return value, auth) are front-loaded in that order with no filler sentences. It is dense with inline examples, which is justified for an untyped nested object but makes the middle sentence heavy.

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

Completeness4/5

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

For a write tool with no output schema, the description covers the return value, persistence semantics, auth, and the payload contract. The one gap is the report `blocks` structure, which is delegated by reference to create_report rather than described here, leaving some indirection for the more complex payload path.

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 a baseline of 3 would be defensible, but the `chart` parameter is a free-form object with no structural schema, and the description compensates by giving the exact expected shape plus a concrete line-chart example and the report variant with `blocks`. The `name` and `stamp` parameters are left to the schema, which keeps it short of a 5.

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?

"Save a chart, map, dashboard or report with a fixed link that always shows its latest data" gives a specific verb (save), a concrete resource (chart/report), and the defining property (persistent fixed link). This directly separates it from the generate_* siblings, which produce one-off output.

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?

Explicit when-to-use triggers are supplied: the user will update it later, embed it in a page, or send it to Slack/email when it changes. It also notes the relationship to generate_* tools by saying the payload is the same JSON. It stops short of naming update_living_chart or stating when-not to use this tool, but the intent-based routing is clear.

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

All ChartAnt toolsInspect
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