Skip to main content
Glama
Sign In
ChartQuery MCP Server

ChartQuery MCP Server

by chartquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Chart

chart
Read-only

Render Chart.js images via GET with URL-encoded JSON or POST with a JSON body; optionally pin the version or return share URLs.

Instructions

Chart. Render a Chart.js image via GET. Pass the full chart object as URL-encoded JSON in query. Prefer format png for ChatGPT. POST sends the same object as a JSON body, not query. Credit cost: 5 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": {
      "query": "<query>"
    },
    "name": "chart"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesFull chart config as URL-encoded JSON. Pass ?version= or ?v= separately to pin the chart version.
shareNoIf true, persist the result and return share URLs instead of an image. Leave false to get the image.
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.
versionNoChart.js version to use. Alias: ?v=. Only v4.x is supported. Defaults to the installed version (4.5.1). Example: "4", "4.5", "4.5.1". The installed version is always returned in the X-ChartJS-Version response header. Default: "4.5.1".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the 5-credits-per-call cost, that 'share' persists results and returns share URLs instead of an image, and that GET versus POST differ in how the payload is carried. The mention of POST sits slightly awkwardly against a read-only rendering hint, but it describes an alternate invocation path for the same non-destructive render rather than contradicting 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.

Conciseness5/5

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

Four tight sentences, front-loaded with the core action and the GET/POST distinction, then the practical format tip and credit cost. Every sentence carries information not already in structured fields, with no filler.

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 does well to name the image format, the share-URL return mode, and the X-ChartJS-Version response header. The main residual gap is sibling disambiguation among the many chart_* tools and the slightly ambiguous GET/POST framing.

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%, so all four parameters are already documented, and the description's baseline is a 3. It adds only marginal meaning: that 'query' holds the entire chart config and that 'version'/'v' must be supplied separately, plus a hint that 'share' changes the returned artifact type.

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 opens with a specific verb and resource ('Render a Chart.js image via GET') and clarifies that the chart object travels as URL-encoded JSON in the query, with POST sending the same object in a JSON body. It does not distinguish this tool from nearby siblings like chart_render, chart_view, or chart_ai, so an agent still has to guess which chart entry point to pick.

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 concrete usage advice ('Prefer format png for ChatGPT') and notes that version should be passed separately via ?version= or ?v= rather than embedded in the chart object. However, it never states when to use this over chart_render, chart_ai, or chart_view, and gives no exclusions or prerequisites, so the routing guidance is only implied.

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