Platemark

Make a chart image

render_chart

Turn numbers into a clean chart PNG: bar, horizontal_bar, stacked_bar, line, area, pie or donut. Returns the image, a link that works for a year (for emails, docs, Slack or markdown) and one-sentence alt text describing the data. Axes, number formatting, colors and labels are handled; pass the data and a title. Costs 1 credit.

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": {
      "type": "<type>"
    },
    "name": "render_chart"
  }
}

Input Schema

Name	Required	Description
`size`	No	landscape 1200x675 (default), og 1200x630, square 1080x1080, portrait 1080x1350, story 1080x1920.
`type`	Yes	bar for comparing categories, line or area for change over time, stacked_bar for parts of a total over categories, pie or donut for shares of one total (6 slices max; the rest fold into Other), horizontal_bar for long category names.
`theme`	No
`title`	No	What the chart shows, like 'Monthly revenue'.
`format`	No	percent expects percentages: 12.5 means 12.5%.
`labels`	No	One label per value: months, categories or slice names.
`locale`	No	Like en-US or de-DE.
`series`	No	Several series share the labels. null leaves a gap in a line.
`source`	No	Footnote, like 'Source: Stripe'.
`values`	No	For a single series. Use series instead for several.
`currency`	No	ISO code like USD or EUR, with format currency.
`decimals`	No
`subtitle`	No	Units, period or context, like 'USD, 2026'.
`highlight`	No	A label to emphasize; the other bars or slices go gray.
`show_values`	No	Force value labels on or off. By default they appear where they fit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare the generic profile (not read-only, not idempotent, not destructive); the description adds real behavior the annotations cannot convey: the call returns an image plus a link valid for one year and one sentence of alt text, and it consumes 1 credit. It stops short of saying that repeated calls generate new distinct links/assets, which would fully explain the non-idempotent hint.

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

Conciseness5/5

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

Three sentences, front-loaded with the outcome (a chart PNG), then the return payload, then the effort/cost contract. No redundant restatement of the title or name, and every clause carries information the agent cannot get from structured fields.

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 15-parameter generator with no output schema, the description supplies the missing return contract (image, year-long link, alt text) and the cost model, so an agent knows what comes back and what it spends. Minor gaps remain around failure behavior and whether expired links can be re-fetched, but the essentials for correct invocation are present.

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?

With 87% schema coverage the baseline is 3, and the description earns an increment by telling the agent that axes, number formatting, colors and labels are handled automatically and that only data plus a title are needed — meaningful relief for a 15-parameter tool. It still adds nothing about size, theme, highlight or locale semantics, which remain schema-only.

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?

The description names a specific verb and resource ('Turn numbers into a clean chart PNG') and enumerates the exact chart types produced, so it is immediately distinguishable from render_image, render_document and render_invoice without inspecting any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a minimal usage cue ('pass the data and a title') and a cost signal ('Costs 1 credit'), which implicitly frames it as a spend operation. But it never states when to choose this over render_image or another sibling, nor any prerequisites or exclusions; chart-type selection guidance lives entirely in the schema.

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

All Platemark 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?