echart-mcp-view

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![echart-mcp-view MCP server](https://glama.ai/mcp/servers/SpenserCai/echart-mcp-view/badges/card.svg)](https://glama.ai/mcp/servers/SpenserCai/echart-mcp-view)

Score Badge

Copy to your README.md:

[![echart-mcp-view MCP server](https://glama.ai/mcp/servers/SpenserCai/echart-mcp-view/badges/score.svg)](https://glama.ai/mcp/servers/SpenserCai/echart-mcp-view)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpenserCai/echart-mcp-view'

If you have feedback or need assistance with the MCP directory API, please join our Discord server