typesearch

Create a chart

create_chart

Turn a question into a chart card, without thinking about chart types: the standings of the latest race, poll or election results by candidate, wins in a season, coverage over time, share of voice between names, tone, the outlets that cover a topic most, what an outlet published, a timeline of a story, the figures the articles publish (a price, a rate), or data from a custom index. It works out what the user expects (understood, with other readings to pass as interpretation), verifies every value against its source, picks the chart, the key figures and a title that states the finding, and returns an image URL (show it to the user) and an embed URL. If the exact data is not published it shows the closest thing and says so (rung, warnings). It costs its search (the mode it needs, per query) plus US$0.50 per 1,000 charts; the same request within 10 minutes is free.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	No	Only the last N days, 1 to 365. By default it depends on the chart: 30 for coverage, 7 for figures.
`type`	No	auto (default) picks the chart that tells the data best. Or force one: line, area, bar, bar_horizontal, stacked_bar, pie, donut, scatter, funnel, timeline, kpi, table.	auto
`index`	No	Optional: chart your own custom index (idx_…) instead of the news: prices, ratings, availability, brands.
`query`	Yes	What to chart, in plain words and any language: "blue dollar this week", "Milei vs Bullrich coverage", "tone of the IMF coverage", "which outlets cover lithium", or "prices" with index.
`theme`	No	light (default), dark, editorial (warm paper) or electric (deep blue).	light
`compare`	No	What to compare, 2 to 5, if the query does not say it with "vs": ["Milei", "Bullrich"].
`countries`	No	Only sources from these countries: ISO 3166-1 alpha-2 codes, such as ["AR"] or ["US", "GB"].
`languages`	No	Only sources that publish in these languages: ISO 639-1 codes, such as ["es"] or ["en", "pt"].
`interpretation`	No	Optional: one of the `alternatives` of a previous call, to chart that reading of the query instead.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`data`	No	The values drawn (up to 40 per series).
`rung`	No	exact (the data asked for), partial (a verified part), related, coverage or stories (the closest thing found).
`type`	Yes
`table`	No	The rows of a table chart (up to 10), keyed by column label.
`title`	Yes	It states the finding.
`cached`	No
`events`	No
`sources`	No
`cost_usd`	Yes
`subtitle`	No
`warnings`	No
`embed_url`	No	An iframe for a web page or app.
`image_url`	No	PNG: show it to the user.
`improving`	No	Still looking for the exact data: the image and embed update themselves if it arrives.
`request_id`	Yes
`understood`	No	What we understood the user expects to see.
`key_figures`	No
`alternatives`	No	Other readings of the query: pass one as `interpretation` to chart it instead.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 26, 2026

addedInput schema / properties / interpretation

Added value: +{
+  "description": "Optional: one of the `alternatives` of a previous call, to chart that reading of the query instead.",
+  "maxLength": 160,
+  "type": "string"
+}

addedOutput schema / properties / alternatives

Added value: +{
+  "description": "Other readings of the query: pass one as `interpretation` to chart it instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / improving

Added value: +{
+  "const": true,
+  "description": "Still looking for the exact data: the image and embed update themselves if it arrives.",
+  "type": "boolean"
+}

addedOutput schema / properties / rung

Added value: +{
+  "description": "exact (the data asked for), partial (a verified part), related, coverage or stories (the closest thing found).",
+  "type": "string"
+}

addedOutput schema / properties / table

Added value: +{
+  "description": "The rows of a table chart (up to 10), keyed by column label.",
+  "items": {
+    "additionalProperties": {
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / understood

Added value: +{
+  "description": "What we understood the user expects to see.",
+  "type": "string"
+}

AddedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description discloses non-obvious behavior well beyond the annotations: it interprets the user's expectation, verifies values against sources, falls back to the closest data with warnings, returns image and embed URLs, and explains the cost model including a 10-minute free cache. This is substantial added context.

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?

The description is long but information-dense. It is front-loaded with the core purpose, then explains the internal process, fallback behavior, and cost model. Every sentence contributes useful operational context without filler.

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

Completeness5/5

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

For a 9-parameter tool with full schema coverage and an output schema, the description covers the non-obvious aspects: interpretation flow, verification, fallback behavior, output URLs, and pricing. Nothing critical for correct invocation 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the interpretation parameter ('other readings to pass as interpretation'), the index parameter ('data from a custom index'), and the auto behavior of the type parameter. It does not need to repeat schema details.

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 opens with a specific verb and resource: 'Turn a question into a chart card.' It clearly differentiates from siblings like search_news or get_contents by focusing on chart creation rather than retrieval or content access.

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?

The description gives clear context for when to use the tool: whenever a user wants a chart from a question. It does not explicitly name sibling tools or state when not to use it, so it falls short of a 5, but the intended use is unambiguous.

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

All typesearch tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?