Skip to main content
Glama
Sign In
ChartQuery MCP Server

ChartQuery MCP Server

by chartquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Chart AI

chart_ai
Read-only

Generate a rendered chart image from a plain-English prompt, with controls for title, dimensions, format, legend, and raw data so you can visualize data without manual chart setup.

Instructions

Chart AI. Describe a chart in plain English via GET and get a rendered image back. Powered by AI. Credit cost: 10 credits per call.

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": {
      "prompt": "<prompt>"
    },
    "name": "chart_ai"
  }
}

Input Schema

NameRequiredDescriptionDefault
shareNoSet share=true to persist the config and receive JSON instead of an image: { id, render_url, view_url, embed_url, expires_in }. Free plan: 3-day expiry with watermark. Paid plan: 6-month expiry, no branding. Default: false.
titleNoOverride the chart title generated by AI.
widthNoImage width in pixels (50–4000). Default: 1200.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.
formatNoOutput format. Default: "png". Allowed values: png, svg. Default: "png".
heightNoImage height in pixels (50–4000). Default: 600.
legendNoLegend position or visibility. Use "false" to hide. Allowed values: top, bottom, left, right, chartArea, false. Default: "top".
promptYesDescribe your chart in plain English (max 1000 chars). Be specific: mention chart type, data topic, colors, style.
raw_dataNoRaw data for the chart. URL-encoded string, CSV, or JSON. AI will parse and structure it.
subtitleNoOverride the chart subtitle.
backgroundNoBackground color as a hex value. Default: #ffffff.
device_pixel_ratioNoDevice pixel ratio for the rendered image. Default: 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the one genuinely new behavioral fact an agent needs for planning, the 10-credit cost per call, plus that output is a rendered image. It stops short of disclosing non-determinism limits, latency, or that share=true switches the response to JSON (that detail lives only in the schema).

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?

Four short sentences, front-loaded with the action and the return value, with the cost note at the end where a reader expects it. 'Chart AI' at the start and 'Powered by AI' are mildly redundant given the tool name, but nothing else is wasted.

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 12-parameter tool with full schema coverage and no output schema, the description covers the core contract: input is English prose, output is a rendered image, cost is 10 credits. It omits only secondary behavior, such as what share=true returns and the non-deterministic nature of AI rendering, which the schema mostly backstops.

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

Parameters3/5

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

Schema description coverage is 100% and all 12 parameters carry detailed inline descriptions (ranges, defaults, allowed values), so the schema does the heavy lifting. The description only gestures at the required 'prompt' parameter by restating 'describe a chart in plain English' and adds no meaning about width/height limits, format, or raw_data beyond the schema. Baseline 3 applies.

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 gives a specific verb and resource: render a chart image from a plain-English description, and notes the output is an image returned via GET. It is clear what the tool produces, but it never distinguishes itself from the closely-named siblings 'chart', 'chart_render', or 'diagram_ai', which an agent could easily confuse with it.

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?

Usage is only implied: 'Describe a chart in plain English' suggests this is the right choice when the agent has a natural-language spec rather than structured data or a fixed template. There is no explicit when-to-use statement, no exclusion against 'chart'/'chart_render', and no note on when 'raw_data' makes this appropriate.

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

Deploy Server

Other Tools