Skip to main content
Glama
Sign In

ChartAnt

by net.chartant
OverviewDiscussionsAdmin

Report from several charts

create_report
Read-only

Put several charts, maps or KPI cards and some text into one report. Returns a link to a report page (shareable, PDF download) and a PowerPoint deck with a slide per chart. Each chart block takes the same fields as the matching generate_* tool, plus its 'type' (e.g. column, line, pie, country-map, world-map, county-map, kpi). Each call makes a new report; to update the same report link later use create_living_chart with type 'report'. Returns the report, PDF, PowerPoint and chart image links.

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": {
      "title": "<title>",
      "blocks": "<blocks>"
    },
    "name": "create_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesReport title.
blocksYesIn order: headings, paragraphs and charts (at most 12 charts).
subtitleNoLine under the title, e.g. the period covered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, non-idempotent, non-destructive, closed-world behavior; the description adds genuinely new context by explaining that every call yields a distinct new report, and it enumerates the artifacts produced (report page, PDF, PowerPoint, chart images). That resolves the otherwise confusing readOnlyHint=true on a creation tool, since it clarifies no existing data is mutated and nothing is idempotent.

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?

Dense but front-loaded, with the output artifacts and the create_living_chart routing rule early. The final sentence largely repeats the earlier return-value listing, adding only 'chart image links', so there is a small amount of redundancy.

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?

With no output schema, the description carries the return-value burden and does so across two sentences, and it explains how to build the loosely-typed blocks array. The per-type chart field mapping to generate_* tools is the main thing an agent needs and it is present; only sibling differentiation against generate_dashboard is missing.

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 baseline is 3, but the description goes further by explaining that each chart block uses the same fields as the matching generate_* tool plus a 'type' (column, line, pie, country-map, world-map, county-map, kpi). That is real added meaning, since the chart object is free-form with no per-field schema.

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 opening sentence gives a concrete verb and resource: assemble charts, maps or KPI cards plus text into one report, and it names the sibling it is not (create_living_chart with type 'report'). It is slightly less clear against generate_dashboard, another composite-output sibling that the description never mentions.

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?

It states the key routing rule explicitly: 'Each call makes a new report; to update the same report link later use create_living_chart.' That is clear when-to-use guidance with a named alternative, though there are no exclusion criteria for when not to build a report at all.

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