This MCP server lets you create and render 16 types of interactive ECharts visualizations as sandboxed MCP App HTML resources within compliant MCP hosts.
Supported Chart Types (opener tools):
Table – structured row/column display
Line – trends and time series with smoothing, area fill, stacking, and data zoom
Bar – grouped, stacked, or horizontal category comparisons
Pie – standard pie, donut, or Nightingale rose variants
Scatter – correlations and bubble charts
Radar – multi-dimensional profile comparisons
Heatmap – matrix intensity and 2D density
Funnel – conversion stages and value drop-off
Gauge – single KPI, progress, or threshold indicator
Tree – parent-child hierarchical relationships
Treemap – hierarchical size comparisons with nested rectangles
Graph – node-link relationship networks
Sankey – weighted source-to-target flows
Candlestick – OHLC market/range data
Boxplot – distributions and outliers
Mixed – combined bar+line series with dual y-axis support
App-Only Helper Tools:
echart_mcp_view_app_build_option – validate input and generate ECharts options from the current app payload
echart_mcp_view_app_examples – retrieve sample inputs for one or all chart types
Cross-Cutting Capabilities:
Provide structured high-level inputs (tabular rows, trees, or node/link graphs) instead of raw ECharts config
Adapt automatically to host theme, locale, and display mode (inline/fullscreen)
Enable interactive features: tooltips, legends, data zoom, toolboxes, and visual maps
Safely customize style/layout via advanced.optionPatch (restricted keys — no series, dataset, axes, formatters, or HTML overrides)
Choose between canvas and SVG renderers
Debug mode to inspect input JSON and generated chart options
Runs over Streamable HTTP or stdio, with configurable origins and optional bearer-token authentication
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@echart-mcp-view show pie chart of market share by product category"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent-ready ECharts visualization for MCP Apps.
echart-mcp-view is an MCP server that turns structured tool arguments into polished, interactive chart views. It exposes one model-visible opener tool per chart type, serves each chart UI as an independent MCP App HTML resource, and lets the embedded app rebuild ECharts options from validated data without asking the model to hand-write chart configuration.
16 focused chart apps for tables, Cartesian charts, relationships, hierarchy, flow, KPI, finance, and distribution views.
MCP Apps first: every opener tool maps to a ui:// HTML resource rendered by a compliant host.
Structured chart input: callers provide data, encodings, axes, presentation, and interaction controls instead of raw ECharts options.
Host-aware UI: app chrome follows Host theme, locale, and inline / fullscreen display mode when available.
Single-file app bundles: every chart surface is built into a self-contained HTML resource under dist/client/.
Safe customization: advanced.optionPatch accepts controlled style/layout keys while blocking series, datasets, axes, formatter functions, HTML rendering, timelines, and render modes.
Debuggable by design: optional debug mode reveals input JSON and generated chart options for local inspection.
Related MCP server: mcp-plots
The model calls a chart opener tool such as echart_mcp_view_open_line.
The tool validates the input and returns structured content plus MCP App metadata.
The Host fetches the matching ui://echart-mcp-view/*.html resource and renders it in a sandboxed iframe.
The embedded React app receives tool input/result notifications, builds an ECharts option through the app-only helper tool, and renders the chart.
This keeps the model-facing tool surface compact while keeping chart rendering, theme handling, and interactive UI behavior inside the app.
Model-visible opener tools:
Chart | Tool | Best for |
Table |
| Row and column inspection |
Line |
| Trends, time series, multi-metric comparison |
Bar |
| Category comparison, grouped bars, stacked bars |
Pie |
| Share-of-total, donut, rose charts |
Scatter |
| Correlation, bubble size, visual maps |
Radar |
| Multi-dimensional profile comparison |
Heatmap |
| Matrix intensity and two-dimensional density |
Funnel |
| Conversion stages and ordered drop-off |
Gauge |
| Single KPI, progress, threshold state |
Tree |
| Parent-child hierarchy |
Treemap |
| Hierarchical size comparison |
Graph |
| Node-link relationship networks |
Sankey |
| Weighted source-target flows |
Candlestick |
| OHLC market or range data |
Boxplot |
| Distribution summaries and outliers |
Mixed |
| Combined bar and line series |
App-only helper tools:
Tool | Purpose |
| Validate chart input and return a table view model or ECharts option for the current app payload |
| Return reusable sample inputs for one chart type or all chart types |
Requirements:
Node.js 20+
npm
Run the published package over Streamable HTTP:
npx -y echart-mcp-view@latest --http --host 127.0.0.1 --port 3338Default HTTP endpoints:
http://127.0.0.1:3338/mcp
http://127.0.0.1:3338/healthzRun over stdio when an MCP host launches this server as a local command:
npx -y echart-mcp-view@latest --stdioFor a source checkout, install and build first:
npm install
npm run build
npm run startRecommended stdio configuration with npx:
{
"mcpServers": {
"echart-mcp-view": {
"command": "npx",
"args": ["-y", "echart-mcp-view@latest", "--stdio"]
}
}
}Pin the version for reproducible host setups:
{
"mcpServers": {
"echart-mcp-view": {
"command": "npx",
"args": ["-y", "echart-mcp-view@0.1.1", "--stdio"]
}
}
}Source checkout stdio configuration:
{
"mcpServers": {
"echart-mcp-view": {
"command": "node",
"args": ["/absolute/path/to/echart-mcp-view/dist/index.js", "--stdio"]
}
}
}Streamable HTTP with npx:
npx -y echart-mcp-view@latest --http --host 127.0.0.1 --port 3338Use the /mcp endpoint in hosts that support Streamable HTTP MCP connections.
The package exposes a single executable:
echart-mcp-view --stdio
echart-mcp-view --http --host 127.0.0.1 --port 3338Local global install is optional:
npm install -g echart-mcp-view
echart-mcp-view --stdioUse npx for one-off runs or Host-managed launches:
npx -y echart-mcp-view@latest --stdio
npx -y echart-mcp-view@latest --http --host 127.0.0.1 --port 3338--stdio: stdio transport for local MCP host process management.
--http: Streamable HTTP transport, served at /mcp.
--host and --port: override HTTP bind host and port.
ECHART_MCP_VIEW_HTTP_HOST=127.0.0.1
ECHART_MCP_VIEW_HTTP_PORT=3338
ECHART_MCP_VIEW_ALLOWED_ORIGINS=http://localhost:3000
ECHART_MCP_VIEW_ALLOWED_HOSTS=localhost,127.0.0.1
ECHART_MCP_VIEW_HTTP_AUTH_TOKEN=optional-bearer-token
ECHART_MCP_VIEW_DEBUG=0Remote HTTP mode requires explicit allowed hosts, allowed origins, and an auth token.
The JSON input and generated-option panel is hidden by default. Enable it when inspecting payloads or chart output:
ECHART_MCP_VIEW_DEBUG=1 node dist/index.js --http --host 127.0.0.1 --port 3338
ECHART_MCP_VIEW_DEBUG=1 node dist/index.js --stdioFor direct local app-page inspection, append ?debug=1 or ?debug=true to the built app URL.
Theme: explicit presentation.theme wins; otherwise the app follows hostContext.theme; without Host context it falls back to prefers-color-scheme.
Display mode: app capabilities advertise inline and fullscreen; the app requests mode changes through the MCP Apps bridge and trusts the Host result.
Locale: app chrome uses hostContext.locale when present, then navigator.language, then en-US.
Host styles: supported Host CSS variables and fonts are applied through the MCP Apps SDK helpers.
App-only tools: helper tools are marked app-visible so the embedded UI can rebuild options without expanding the model-visible tool set.
Chart opener tools accept chart-specific subsets of the common input model:
Field | Purpose |
| Top-level chart title |
| Top-level chart subtitle |
| Tabular rows as object records or a matrix |
| Optional ordered field names |
| Table column metadata |
| Hierarchical tree or treemap nodes |
| Graph or Sankey relation data |
| Mapping from data fields to visual channels |
| Optional per-series overrides |
| Theme, palette, labels, legend, stacking, smoothing, orientation |
| Cartesian or mixed chart axis settings |
| Tooltip, legend, zoom, toolbox, visual map |
| Renderer and restricted ECharts option patch |
Use data.source for tabular charts, data.tree for hierarchy charts, and data.nodes / data.links for graph or Sankey charts. Prefer top-level title and subtitle; presentation fallback titles are accepted by app-side option building.
Radar charts accept both wide rows (encoding.name plus metric fields in encoding.y) and long rows (encoding.category for indicators, with either value columns in encoding.y or grouped encoding.series plus encoding.value).
{
"title": "Revenue by Month",
"subtitle": "Actuals and profit trend",
"data": {
"source": [
{ "month": "Jan", "revenue": 82, "profit": 21 },
{ "month": "Feb", "revenue": 91, "profit": 24 },
{ "month": "Mar", "revenue": 104, "profit": 31 }
]
},
"encoding": {
"x": "month",
"y": ["revenue", "profit"]
},
"presentation": {
"smooth": true,
"showLegend": true
},
"interaction": {
"tooltip": true,
"dataZoom": "both"
}
}{
"title": "Budget Flow",
"data": {
"nodes": [
{ "name": "Budget" },
{ "name": "Product" },
{ "name": "Marketing" }
],
"links": [
{ "source": "Budget", "target": "Product", "value": 62 },
{ "source": "Budget", "target": "Marketing", "value": 38 }
]
},
"interaction": {
"tooltip": true
}
}Layer | Files | Responsibility |
MCP server |
| Register chart opener tools, app-only helpers, and resources |
Resource registry |
| Serve |
Chart service |
| Validate opener payloads and produce structured tool results |
Option builder |
| Convert normalized chart input into table view models or ECharts options |
App runtime |
| Connect to the Host, apply theme/locale/display context, render chart UI |
App bundles |
| One entry point per chart HTML resource |
Test harness |
| Exercise stdio and HTTP MCP server behavior |
Build output:
Path | Contents |
| Compiled MCP server entry |
| Single-file MCP App HTML resources |
| Type declarations for compiled modules |
App HTML resources use the MCP Apps resource MIME type and a restrictive empty CSP domain list by default.
Remote HTTP mode requires host allow-list, origin allow-list, and bearer-token authentication.
External links are handled by the Host; chart apps do not need broad network access for normal rendering.
advanced.optionPatch is limited to safe visual/layout keys: aria, backgroundColor, color, dataZoom, grid, legend, textStyle, title, toolbox, tooltip, and visualMap.
optionPatch rejects nested overrides for generated data structures and executable/rendering fields such as series, dataset, axes, formatter, html, rich, timeline, media, and render mode.
Common scripts:
Script | Description |
| Compile the server and build all app HTML bundles |
| Build only the single-file MCP App HTML resources |
| Start HTTP transport from |
| Start stdio transport from |
| Run TypeScript checks for source and tests |
| Run unit tests |
| Build app HTML and verify UI layout snapshots/checks |
| Run stdio and HTTP MCP harness tests |
| Run typecheck, unit tests, UI layout tests, and MCP harness tests |
Run fast local checks:
npm run typecheck
npm testRun full verification:
npm run checkApp-only helper that validates chart input and returns a table view model or ECharts option for the current MCP App payload.
| Name | Required | Description | Default |
|---|---|---|---|
| axes | No | Cartesian axis settings. | |
| data | No | Data payload: source, tree, or nodes/links. | |
| title | No | Chart title. | |
| series | No | Optional per-series definitions. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Data-field to visual-channel mapping. | |
| subtitle | No | Chart subtitle. | |
| chartType | Yes | Chart type. | |
| interaction | No | Interaction controls. | |
| presentation | No | Visual preferences. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description adds that it 'validates chart input and returns a table view model or ECharts option', which is helpful beyond annotations. No side effects or auth needs are disclosed, but the annotations already indicate safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 21 words, extremely concise. It front-loads the purpose ('App-only helper...') and wastes no words. Every part is meaningful given the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 10 parameters, nested objects, and no output schema, the description is very brief. It does not provide a high-level overview of how the parameters interact or what typical use cases are. For a tool with such complexity, the description is incomplete, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description only says 'validates chart input' without adding specific parameter context. It does not explain the roles of complex parameters like encoding or advanced, so it adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates chart input and returns a table view model or ECharts option for the current MCP App payload. The verb 'validates' and 'returns' specify the action, and 'App-only helper' provides context. However, it does not explicitly differentiate from sibling tools like echart_mcp_view_open_bar, which likely directly render specific charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the many sibling open_* tools. The phrase 'App-only helper' hints at internal use but does not explain conditions or alternatives. There is no mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
App-only helper that returns reusable example inputs for one chart type or every supported chart type.
| Name | Required | Description | Default |
|---|---|---|---|
| chartType | No | Chart type; omit for all examples. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds no further behavioral context (e.g., that it only returns static examples, no side effects, or rate limits). It does not contradict annotations but adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 14 words that conveys the core purpose without fluff. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description is adequate but lacks details on return format or usage of examples. Given low complexity and 0 required params, it meets minimum viability but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with one parameter 'chartType' fully described by enum and description. The tool's description repeats the same idea ('omit for all examples') but adds no new semantic info beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns reusable example inputs for chart types, using specific verb 'returns' and resource 'example inputs'. It distinguishes itself from sibling 'open' tools by being an 'app-only helper', though it does not explicitly differentiate from the 'build_option' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'echart_mcp_view_app_build_option' or the various 'open' tools. The description simply states functionality without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused bar chart MCP App for category comparisons, grouped bars, and stacked bars. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| axes | No | Axis types. | |
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| series | No | Bar series list. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Cartesian field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Cartesian interactions. | |
| presentation | No | Bar presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds that it 'opens' an app, reinforcing non-destructive behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently covers purpose and key input aspects. No filler, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects), the description is minimal and does not explain many optional configuration fields (axes, series, interaction, presentation). Schema fills gaps but description lacks orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% parameter descriptions. The description adds high-level context (title/subtitle, data structure, encoding) but is slightly misleading by claiming data supports tree or nodes/links, which the schema does not reflect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a bar chart app for category comparisons, grouped bars, and stacked bars. The verb 'open' plus resource 'bar chart app' with specific use cases distinguishes it from sibling chart-type tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by indicating what to put in title/subtitle, data, and encoding. While it doesn't explicitly contrast with other chart types, the name and context make the bar chart purpose obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused boxplot MCP App for distribution summaries and outlier context. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Boxplot field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Basic interactions. | |
| presentation | No | Boxplot presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral insight beyond that. It mentions data formats (rows, tree, nodes/links) but does not disclose details like whether opening an app generates a new instance or modifies state. With annotations, the bar is lower but additional context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the purpose and providing brief usage hints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema), the description is insufficient. It does not explain return values, parameter relationships (e.g., which encoding fields are required), or how the chart is populated. A more comprehensive description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the description adds little new parameter meaning. The description states 'data holds rows, tree, or nodes/links; encoding maps fields' but this mostly restates schema information. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as for opening a boxplot chart focused on distribution summaries and outlier context, and the title and name are consistent. However, the phrase 'focused boxplot MCP App' is somewhat jargon-y and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., other chart types like open_bar or open_line). It only implicitly suggests use for distribution/outlier context, but lacks when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused candlestick MCP App for OHLC market and range data. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | OHLC field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Candlestick interactions. | |
| presentation | No | Candlestick presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, so the description minimally adds behavioral context beyond 'opens a focused MCP App'. It does not contradict annotations but offers little extra insight into side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the tool's purpose. The second sentence is a bit telegraphic but not excessively verbose. Minor improvements could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects), the description covers only core aspects (title, data, encoding). It omits interaction, presentation, and advanced options, which are documented in the schema but not summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description claims data can be 'rows, tree, or nodes/links', but the schema only supports arrays of objects or arrays of arrays (tabular format). This is misleading and adds confusion beyond the 100% schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and description clearly indicate this tool opens a candlestick chart app for OHLC market data. The description specifies the data structure (title, subtitle, rows, encoding) and distinguishes it from sibling chart tools like open_bar or open_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is for 'OHLC market and range data' and mentions the overall structure, implying when to use it. However, it does not explicitly compare to other chart types or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused funnel chart MCP App for conversion stages and ordered value drop-off. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Item name/value mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Item interactions. | |
| presentation | No | Funnel presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with 'Open' action. The description adds behavioral info about data formats (rows, tree, nodes/links) beyond annotations, but does not detail return behavior or side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, nested objects, and no output schema, the description adequately covers the core purpose and data structure. It does not explain all parameters but those are documented in schema. Could be slightly more complete with example usage, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3. The description adds value by mentioning tree and nodes/links data formats not in schema, and clarifies encoding maps fields. This extra context raises the score slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a funnel chart for conversion stages and value drop-off, using specific verb 'open' and resource 'funnel chart MCP App'. It distinguishes from many sibling chart tools by naming the chart type and its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for funnel/conversion data with 'conversion stages and ordered value drop-off', but does not explicitly state when not to use or compare to sibling chart types. However, tool name and context signals make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused gauge MCP App for a single KPI, progress indicator, or threshold state. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Item name/value mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Basic interactions. | |
| presentation | No | Gauge presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description does not contradict this. The description adds minimal behavioral context beyond stating it opens a 'focused' app, which is not further explained. The score is adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and wastes no words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and nested objects, the description does not explain key gauge concepts like value range, min/max, or pointer behavior. The schema covers structure but the description lacks sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so the description's summary ('Use top-level title/subtitle; data holds rows...') adds limited extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a gauge chart for 'a single KPI, progress indicator, or threshold state', clearly distinguishing it from sibling chart tools like bar, line, or pie.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single KPIs or progress indicators, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused graph MCP App for node-link relationship networks. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Nodes/links or relation rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Relation row mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Item interactions. | |
| presentation | No | Graph presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, aligning with the non-destructive 'Open' action. Description adds context about data structures and encoding but does not disclose potential constraints, rendering behavior, or limits beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and parameter guidance with no unnecessary information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description is minimal. It does not explain data format variations (rows vs. nodes/links vs. tree) or how to construct the data object, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 7 properties. The description briefly mentions key parameters (title, subtitle, data, encoding) but adds no new semantic insight beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Open a focused graph MCP App for node-link relationship networks,' clearly identifying the tool's purpose. It distinguishes from non-graph siblings (bar, pie, etc.) but could more explicitly differentiate from similar node-link tools like open_sankey or open_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for node-link networks but provides no guidance on when to use this tool versus alternatives (e.g., open_sankey for flow, open_tree for hierarchy). No explicit exclusions or context-dependent recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused heatmap MCP App for matrix intensity and two-dimensional density data. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Heatmap field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Heatmap interactions. | |
| presentation | No | Heatmap presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds context that data can hold rows, tree, or nodes/links, which goes beyond the annotation. There is no mention of destructive actions or other behavioral traits, but the description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description is somewhat brief but the schema is rich and covers all parameters. The tool opens an app, so return values may be minimal. Missing a bit of context on how data maps to the heatmap, but schema compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; every parameter and nested property has a description in the schema. The tool description adds a brief summary ('Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields') but does not provide additional meaning beyond what the schema already offers. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a heatmap MCP app for matrix intensity and two-dimensional density data. The verb 'open' and resource 'heatmap MCP App' are specific, and the description distinguishes this from sibling tools which are for other chart types (bar, line, scatter, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for heatmap data but does not explicitly state when to use this tool over alternatives like scatter for density. No when-not-to-use or exclusions are provided. Sibling tool names help differentiate, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused line chart MCP App for trends, time series, and multi-metric comparisons. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| axes | No | Axis types. | |
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| series | No | Line series list. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Cartesian field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Cartesian interactions. | |
| presentation | No | Line presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, indicating safe read operation. The description adds context on data formats (rows, tree, nodes/links) but does not elaborate on error handling or return behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose. The second sentence is somewhat cryptic but still informative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 optional parameters and no output schema, the description lacks details on return behavior or app behavior after opening. Minimal context for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description offers a high-level overview but does not add significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Open a focused line chart MCP App' with specific use cases 'trends, time series, and multi-metric comparisons,' clearly distinguishing it from sibling tools like bar, scatter, or pie charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for line charts but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused mixed chart MCP App for combined bar and line series on shared axes. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| axes | No | Mixed axis mapping. | |
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| series | No | Mixed series list. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Mixed field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Cartesian interactions. | |
| presentation | No | Mixed presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds context about data formats but does not disclose additional behavioral traits beyond what annotations provide, so it offers moderate added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then summarizing key inputs. Every sentence conveys useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, nested objects, and no output schema, the description only covers title/subtitle, data formats, and encoding, missing axes, series, interaction, presentation, and advanced options. However, thorough schema descriptions compensate partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by stating data can hold 'rows, tree, or nodes/links' and that encoding 'maps fields', which goes slightly beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open', the resource 'focused mixed chart MCP App', and specifies the unique capability 'combined bar and line series on shared axes', which distinguishes it from sibling chart tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for mixed bar-line charts but provides no explicit guidance on when to use this tool versus alternatives (e.g., open_bar, open_line) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused pie chart MCP App for share-of-total, donut, and rose charts. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Item name/value mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Item interactions. | |
| presentation | No | Pie presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the description does not need to restate this. The description adds minor behavioral context (opens an app) but no further details on side effects, permissions, or limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words. It is appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with nested objects and no output schema, the description is brief. It covers the main concept but lacks detail on parameter interactions. The schema fills in gaps, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The description summarizes key parameters (title, subtitle, data, encoding) but adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a pie chart MCP App for share-of-total, donut, and rose charts. It specifies the verb 'open' and the resource 'pie chart MCP App', and the types distinguish it from sibling tools for other chart types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pie-type charts (share-of-total, donut, rose) but does not explicitly state when not to use it or provide alternatives. The sibling tool names already differentiate chart types, so the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused radar chart MCP App for multi-dimensional profile comparisons. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Radar field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Item interactions. | |
| presentation | No | Radar presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description does not need to restate that. The description adds no further behavioral context beyond 'Open', which is consistent. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but the second sentence is inaccurate regarding data types and could be more precise. It conveys the core purpose but includes misleading information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects) and no output schema, the description is insufficient. It omits details about how data should be structured, what the app does, and return behavior. The incorrect mention of tree/nodes/links further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions. The description adds value by summarizing how to use top-level parameters (title, subtitle, data, encoding), providing a high-level guide that complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a radar chart app for multi-dimensional profile comparisons, which differentiates it from sibling tools for other chart types. However, it incorrectly mentions that data can be a tree or nodes/links, which contradicts the input schema that only supports rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or use cases. It simply states what the tool does without comparing to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused Sankey MCP App for source-target flows with weighted links. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Nodes/links or relation rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Relation row mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Basic interactions. | |
| presentation | No | Sankey presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, which the description does not contradict (opens an app, not modifying data). The description adds context about 'focused app' and 'safe option patch', but overall behavioral disclosure is adequate without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the main purpose and then provide quick usage hints. Every sentence adds value without unnecessary detail, making it efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with nested objects and no output schema, the description covers basic purpose and data formats but lacks details about expected behavior, return values, or limitations. It is minimally adequate but not fully comprehensive for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a high-level summary ('data holds rows, tree, or nodes/links; encoding maps fields') that provides some context beyond the schema, but it does not significantly enhance understanding of individual parameters like advanced or interaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a Sankey MCP App for source-target flows with weighted links, using specific verbs and resources. It distinguishes from sibling tools (other chart types) by explicitly naming the Sankey chart type and describing its data structures (rows, tree, nodes/links).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Sankey diagrams but does not explicitly state when to use this tool vs alternatives (e.g., graph, treemap). No 'when not to use' or comparison to siblings is provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused scatter chart MCP App for correlation, bubble size, and visual map analysis. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| axes | No | Axis types. | |
| data | No | Tabular rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Scatter field mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Scatter interactions. | |
| presentation | No | Scatter presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds context by describing the tool as 'focused' for specific analysis types, which complements the annotation. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every word adds value. No unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does but does not describe the output (e.g., what the app looks like, what is returned). Given the tool's complexity and lack of output schema, more context about the result would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description summarizes key data structures (rows, tree, nodes/links) and encoding fields, but adds little additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'open' and resource 'scatter chart MCP App', and states its purpose for correlation, bubble size, and visual map analysis. It distinguishes from sibling chart tools by focusing on scatter-specific features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scatter analysis but does not explicitly compare to alternatives like bar, line, or pie charts. No direct 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused table MCP App for row and column data inspection. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Table rows and columns. | |
| title | No | Chart title. | |
| subtitle | No | Chart subtitle. | |
| presentation | No | Table presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds 'data inspection' context, consistent with read-only behavior. However, it does not disclose any additional behavioral traits (e.g., pagination, limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler. Could be slightly more structured, but it's efficient and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and the description does not explain what the tool returns or how the table is rendered. For a tool with 4 parameters and nested objects, more context about behavior and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description burden is low. The description mentions title/subtitle and data formats (rows, tree, nodes/links), adding some context beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as opening a table MCP App for row/column inspection, distinguishing it from chart siblings. However, the phrase 'focused table MCP App' is slightly vague and could be more concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for tabular data inspection but provides no explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned, though siblings are clearly different chart types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused tree MCP App for hierarchical parent-child data. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tree nodes or parent-child rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Hierarchy row mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Basic interactions. | |
| presentation | No | Hierarchy presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, indicating a non-destructive, focused operation. The description adds minimal behavioral context beyond confirming the app is opened. It does not elaborate on permissions, side effects, or what 'open' entails, so the description adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key aspects. It is concise with no wasted words, though a slightly more structured breakdown could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, nested objects, no output schema, and many sibling tools, the description provides basic context for data and encoding but lacks explanation of the app's output, behavior differences from similar hierarchical tools (e.g., treemap), and any prerequisites. The schema fully documents parameters, but the description does not fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with every property described. The overall description adds a brief summary of data and encoding structure, which complements the schema without repeating details. Baseline 3 is appropriate since the schema already provides rich parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a focused tree MCP App for hierarchical parent-child data.' It uses specific verb (Open) and resource (tree MCP App), and the sibling tools include many other chart types, so this description successfully distinguishes the tool's purpose for hierarchical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hierarchical parent-child data but does not explicitly state when to use this tool versus alternatives (e.g., echart_mcp_view_open_treemap). No when-not or exclusion criteria are provided, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a focused treemap MCP App for hierarchical size comparison. Use top-level title/subtitle; data holds rows, tree, or nodes/links; encoding maps fields.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Tree nodes or parent-child rows. | |
| title | No | Chart title. | |
| advanced | No | Renderer and safe option patch. | |
| encoding | No | Hierarchy row mapping. | |
| subtitle | No | Chart subtitle. | |
| interaction | No | Basic interactions. | |
| presentation | No | Hierarchy presentation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description 'Open' aligns with read-only behavior but adds no extra behavioral context such as side effects, permissions, or response characteristics. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), immediately states the purpose, and front-loads key information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects) and complete schema descriptions, the description adequately summarizes the core purpose and data requirements. It does not explain return values, but there is no output schema, so that is acceptable. The read-only nature is covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a high-level summary of data structure (rows, tree, nodes/links) and encoding, but does not provide new meaning beyond what the schema offers. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a 'focused treemap MCP App' for 'hierarchical size comparison', with specific verb and resource. It distinguishes from sibling tools like open_tree or open_bar by targeting treemap specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hierarchical data visualization but does not explicitly state when to prefer this tool over alternatives like open_tree or when not to use it. No exclusion criteria or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0echart_mcp_view_app_build_optionechart_mcp_view_app_examplesechart_mcp_view_open_barechart_mcp_view_open_boxplotechart_mcp_view_open_candlestickechart_mcp_view_open_funnelechart_mcp_view_open_gaugeechart_mcp_view_open_graphechart_mcp_view_open_heatmapechart_mcp_view_open_lineechart_mcp_view_open_mixedechart_mcp_view_open_pieechart_mcp_view_open_radarechart_mcp_view_open_sankeyechart_mcp_view_open_scatterechart_mcp_view_open_tableechart_mcp_view_open_treeechart_mcp_view_open_treemapScored across 18 tools
Each tool targets a specific chart type or utility function, with no overlap. The 16 open tools each correspond to a distinct visualization, and the two app helpers serve unique roles.
All tools follow the pattern 'echart_mcp_view_', with most using 'open_<charttype>'. Two app-specific tools use 'app_' instead of 'open_', which is a minor deviation but still consistent within their category.
18 tools cover a broad range of chart types and two utility functions, which is well-scoped for a visualization server. No tool is superfluous, and the number matches the domain well.
The set includes major chart types (bar, line, pie, scatter, radar, etc.) and unique ones like boxplot and candlestick. Missing some less common types (e.g., area map, histogram), but coverage is strong for most use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bar-first MCP server for Tabula chart authoring, PNG rendering, and editor handoff.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for Riveter's enrichment, scraping, and monitoring API
Repository knowledge graph MCP server for codebase understanding and debugging.