Chart Library

Server Quality Checklist

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

Latest release: v5.3.0
Disambiguation2/5
Many tools have overlapping purposes (analyze vs cohort, decision_brief vs cohort+context) and deprecated tools (11 of 22) with similar names (cohort_analyze vs cohort) cause confusion. Descriptions help but an agent could easily misselect between analyze and cohort for metrics.
Naming Consistency3/5
Active tools use a mix of single-word verbs (analyze, discover) and nouns (cohort, context), but the deprecated tools (e.g., clusters, decompose) break the pattern. The naming is not completely chaotic but lacks a strict verb_noun convention.
Tool Count2/5
22 tools is too many for a focused API, especially with 11 deprecated ones that are essentially dead weight. The active set (~11 tools) would be appropriate, but the server includes all deprecated tools, making it noisy and heavy.
Completeness4/5
The non-deprecated tools cover the key operations: pattern search, cohort analysis, metrics, narratives, portfolio analysis, and feedback. Minor gaps (e.g., direct bar fetching) but the core domain of chart-based decision support is well covered.
Average 3.8/5 across 22 of 22 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on May 26, 2026
- 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 declare readOnlyHint=true and other safety hints, but the description adds zero behavioral context beyond deprecation. It does not mention what happens on invocation or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but this under-specification is not effective conciseness. It fails to earn its place by providing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and an output schema, the description is completely inadequate. It does not explain the return format, behavior, or any usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the two parameters (min_pulse, limit). The agent cannot infer their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only indicates deprecation and suggests an alternative tool. It does not state what the tool does, lacking a verb or resource. The name 'narrative_alerts' hints at functionality but the description is missing purpose.
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 informs users to use narrative(mode='alerts') instead, but provides no guidance on when to use this deprecated tool or any conditions. It implies avoidance but lacks explicit context.
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, destructiveHint, idempotentHint, openWorldHint. The description adds deprecation context, which is helpful but basic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it under-specifies the tool's functionality and parameters. It could provide more context in a similarly concise manner.
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 tool is deprecated and has an output schema, a minimal description might suffice, but the lack of parameter explanations and behavioral details leaves gaps for any user still needing to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters (top, timeframe), leaving their meaning and usage completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does, only that it is deprecated and suggests using discover. Without any verb or resource, the purpose is unclear.
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 explicitly tells users to use discover(mode='daily_setups') instead, providing a clear alternative for when to use this deprecated tool.
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 destructiveHint=false, so the safety profile is clear. The description adds a deprecation warning, which is useful but does not provide additional behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of omitting essential information. While it is front-loaded with the deprecation notice, it does not earn its brevity because it leaves the agent without functional guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, 0% schema coverage, and an output schema, the description is completely inadequate. It only provides a deprecation directive and does not explain the tool's behavior, return values, or how to use the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides no parameter information whatsoever. It only mentions the deprecation and alternative, failing to add meaning to any of the 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a deprecation notice directing to 'cohort(depth="compare")'. The purpose is implied by the tool name 'Cohort Compare', but the description fails to explicitly state the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use 'cohort(depth="compare", compare_with=...)' instead, which is a clear alternative. This provides excellent when-not-to-use guidance and a direct replacement.
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, idempotentHint, and openWorldHint, so the description does not need to repeat safety info. It adds the deprecation status, which is behavioral context, but does not disclose any other behaviors beyond what annotations provide.
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 very short and front-loaded with the deprecation notice, which is critical information. However, it lacks additional content that would be expected for a complete tool description, though it is appropriately sized for a deprecated tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and simple parameters, the description fails to explain the tool's purpose, parameter meanings, or return value. It only provides deprecation info, making it inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain what 'symbol' or 'date' represent or how they affect the output. This leaves the agent with no semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title mentions 'Anchor Metadata' and the description states it is deprecated, implying the tool fetches anchor metadata. However, it does not explain what anchor metadata is or how it differs from sibling tools, making it vague and indistinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'DEPRECATED in v5 — use context(target={...})' and provides the alternative tool and its parameters. This gives clear guidance not to use this tool and directs to the correct replacement.
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, destructiveHint, etc. The description adds no behavioral context beyond the deprecation. With annotations present, this is adequate but not enhanced.
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 extremely concise, conveying the essential deprecation and redirection in a single line. It is well-structured for its limited purpose.
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 deprecated tool with an output schema, the description is minimally sufficient to redirect users. However, it lacks details about behavior or parameters for any agent that might still invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the description provides no explanation of the three parameters (limit, lookback_days, horizon), leaving the agent without guidance on their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a deprecation notice and redirects to another tool. Without any explanation of functionality, the purpose is vague.
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 explicitly tells users to use 'discover(mode="picks", ...)' as an alternative, which is clear guidance. However, it does not elaborate on when to use this deprecated tool itself.
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 idempotentHint=true. Description adds that it forwards to cohort, which is a useful behavioral trait, but does not explain other behavioral aspects such as what happens with parameters.
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 very short (two sentences) and front-loads the deprecation warning. It is concise, but lacks detail about the tool's functionality, which is acceptable for a deprecated tool.
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 is deprecated and forwarded, the description provides enough context to avoid using it. However, it does not explain the tool's original purpose or how to invoke it if needed, which is incomplete for a non-deprecated context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the 10 parameters, leaving their meaning entirely to the schema which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is deprecated and forwards to cohort, but does not explain what 'Layer 3 cohort intelligence' means. The verb 'analyze' is present but no concrete action or resource is described, making it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says deprecated and directs to use cohort(depth='full') instead. Clear when-not-to-use and alternative tool, providing excellent guidance.
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 readOnly, not destructive, idempotent. The description adds deprecation context but no additional behavioral details. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line, perfectly efficient for its purpose of deprecation notification.
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 deprecated tool with a clear alternative, the description is adequate. However, it lacks explanation of what the tool originally did, which could be helpful for understanding the replacement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the four parameters. The agent gets only names and types from 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 deprecation and directs to 'analyze(metric="decompose")', implying the purpose of decomposing a cohort. It's explicit enough for an agent to understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'DEPRECATED' and provides the exact alternative call, giving clear when-not-to-use and alternative tool information.
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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description does not contradict them and the deprecation notice is behavioral context, but no additional behavioral details are added.
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 extremely concise (one line), which is acceptable for a deprecated tool, but it could still include parameter explanations without becoming overly long.
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 deprecated tool, the description is minimally complete by providing the replacement. However, it fails to explain parameters or behavior, and the presence of an output schema does not compensate for the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter details. The only parameter mention is in the replacement hint but lacks semantics or constraints beyond the schema.
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 title and description explicitly label the tool as deprecated and provide the exact replacement syntax, making the purpose and lifecycle status immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly states that this tool is deprecated and instructs the user to use portfolio(mode='symbol_intel', symbol=...), offering a clear alternative and when-not-to-use guidance.
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 provide behavioral hints (readOnlyHint=true, etc.), and the description adds only deprecation context. It does not contradict annotations. The description adds minimal additional behavior information beyond the structured 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 a single, front-loaded sentence that effectively communicates the deprecation and alternative. No wasted words; it is appropriately concise for this purpose.
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 is deprecated and has an output schema, the description minimally conveys the tool's purpose. However, it lacks guidance on parameter usage and expected behavior beyond the alternative. Acceptable for a deprecated tool but incomplete for full usage.
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?
Schema description coverage is 0%, and the description does not explain any parameters (bars, scale, top_k, cross_timeframe). Only 'bars' is mentioned in the alternative call. The description fails to compensate for the lack of schema descriptions.
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 the tool is for 'Live Bar Search' and explicitly provides the alternative 'use search(mode="live_bars")'. This distinguishes it from sibling tools like 'search' and indicates its function despite deprecation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is deprecated and directs users to use 'search(mode="live_bars")' instead, providing clear guidance on when not to use this tool and what alternative to use.
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 cover read-only, idempotent, and non-destructive behavior. The description adds the deprecation context, which is a behavioral trait. No contradictions with annotations, but no additional behavioral details beyond the deprecation notice.
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 very short and front-loads the deprecation warning. It is concise, though it lacks structured formatting.
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 deprecation and available annotations and output schema, the description sufficiently guides an agent to not use the tool and to migrate to the alternative. Original functionality details are omitted, which is acceptable for a deprecated tool.
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?
Schema description coverage is 0%, and the description does not explain the 'symbol' parameter. It only hints that the replacement uses the same parameter, but does not add meaning for the original tool's parameter.
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 the tool is deprecated and directs to its replacement, narrative(mode='pulse'). While it doesn't describe the original functionality, the deprecation message makes the purpose clear: this tool should not be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is deprecated and provides the exact replacement call with parameters, leaving no ambiguity about when to avoid this tool and which alternative to use.
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 cover safety (readOnlyHint, idempotentHint). The description adds deprecation status, which is beyond annotations and provides behavioral context without contradiction.
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?
Extremely concise, single-sentence description that front-loads deprecation and replacement, with 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 presence of 4 parameters and an output schema, the description lacks detail on how the tool actually works, focusing only on deprecation. It is complete for its notification role but incomplete for usage.
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 does not describe any parameters, and schema coverage is 0%. It only mentions symbolic usage in the alternative, leaving parameter semantics entirely to 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 the tool is deprecated and points to an alternative (search(mode='similar')), making the purpose unambiguous despite not detailing the original functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs not to use this tool and provides the correct replacement, satisfying the 'when-not' and 'alternatives' criteria perfectly.
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 indicate readOnly, idempotent, nondestructive. The description adds deprecation status and redirection, which are critical behavioral traits not covered by annotations. 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?
Single, focused sentence that front-loads deprecation and provides the alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated tool, the description adequately redirects. Output schema exists for return values. However, it assumes knowledge of analyze and doesn't explain the deprecation reasoning or migration steps.
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?
Schema coverage is 0%, so description must compensate. It only hints at cohort_id via the alternative call, but ignores horizon and k entirely. Minimal value added.
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 title 'Cluster Cohort' suggests clustering, and the description clearly states deprecation and redirects to analyze(metric='clusters'). It communicates the purpose effectively for a deprecated tool, though it doesn't explain what clustering does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states not to use this tool and provides the exact alternative: 'use analyze(metric="clusters", cohort_id=...)'. This is excellent guidance for an agent.
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, idempotentHint, and no destructive behavior. The description adds meaningful behavioral detail: states returned data categories per shape, notes 'Lightweight; no kNN' for the object form, and clarifies data freshness constraints implicitly. No contradictions with annotations.
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?
Structure is clear with a heading and bullet-like list, but the description is verbose, especially for the 'object' shape. Some redundancy exists in listing 'sector' and 'cap' across shapes. Could be tighter without losing meaning.
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 has one parameter with no schema description and an output schema (not shown), the description covers input usage exhaustively. It defines all four target variants and their implications. Missing a brief note on output format, but output schema handles that. Adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero description coverage for the single 'target' parameter, leaving it completely opaque. The description fully compensates by explaining the four accepted shapes, their structure, and example values, making the parameter semantics crystal clear.
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?
Clearly states it provides 'Situational data about a target' and enumerates four distinct shapes (market, SYMBOL, object, system) each returning specific domain data. Differentiates from sibling tools like symbol_intelligence by focusing on market regime and anchor metadata rather than just ticker fundamentals.
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?
Explicitly describes when to use each target shape and what each returns (e.g., 'market' for sector rotation, 'SYMBOL' for ticker metadata). Provides context for selection but does not explicitly exclude alternatives or contrast with siblings like 'symbol_intelligence' or 'anchor_fetch'.
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 indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral details like mode-specific defaults, the fields parameter behavior (allowlist, always returned fields), and mode response content. 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?
The description is well-structured with mode headings and parameter lists. Every sentence adds value, defaults are clearly stated, and the fields parameter is explained with valid keys. No repetition 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?
The description covers all modes, parameters, and the special fields behavior. It mentions always-returned fields. Output schema exists to supplement return value details. Could clarify output for other modes, but overall complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates by explaining each parameter's applicable mode, default values, and special behavior (e.g., fields parameter only for daily_setups, enumerated valid values for mode). Adds meaning far beyond the bare schema.
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 provides market interesting items across three modes with explicit names and defaults. It distinguishes from sibling tools like discover_picks and get_daily_setups by integrating their functionalities into a single tool with mode selection.
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 explains when to use each mode (e.g., daily_setups for pre-enriched setups). It does not explicitly state when not to use the tool or mention alternatives, but the mode descriptions provide clear context for selection.
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 indicate read-only, non-destructive, and idempotent behavior. The description adds context about speed/cost (~50ms for text mode) and return structure (status, data, meta), disclosing that the cohort_id can be chained into other tools. 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?
The description is well-structured with clear headings (Three modes, Returns, Args). It front-loads the core purpose and then details modes, return, and parameters. While comprehensive, it could be slightly streamlined (e.g., the examples could be more terse). Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 3 modes, chaining to other tools), the description covers all aspects: mode selection, parameter constraints (e.g., bars only for live_bars), return structure, and chaining behavior. The existence of an output schema (though not shown) is supplemented by the described return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the tool description fully compensates by explaining each parameter: query, symbol, date, timeframe, top_k, mode, bars, cross_timeframe. It provides examples and clarifies that query is an alternative to symbol+date+timeframe, and that bars are only for live_bars mode.
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's function: 'find similar historical patterns and return a cohort_id.' It distinguishes three modes (text, live_bars, similar) with specific use cases and examples, setting it apart from sibling tools like 'similar_cohorts' or 'explain'.
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 explicit guidance on when to use each mode, with examples and performance characteristics (~50ms for text mode). It suggests chaining to 'cohort', 'analyze', or 'explain' for richer responses, though it does not explicitly state when not to use this tool vs. alternatives.
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 readOnly, non-destructive, idempotent, and open-world hints. The description adds valuable behavioral context, such as the preferred use of cohort_id and the per-metric parameter needs. It does not mention output format (handled by output schema) or edge cases, but overall sufficiently complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening sentence, a bullet-list of metrics with needs, and a clean argument list. Every sentence adds value, and critical information is front-loaded. For a tool with 9 parameters and many metrics, this is an appropriate length with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, various metrics, optional extra_args) and the presence of an output schema, the description is complete. It covers all metrics' prerequisites, parameter meanings, and the anchor vs cohort distinction. The output schema handles return format, so no further explanation needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries full burden. It explains every parameter in detail, especially the metric values (which are effectively enums but not in schema), the role of cohort_id versus symbol/date, extra_args per metric, and special parameters for decompose and clusters. This adds substantial meaning beyond the raw schema.
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 provides analytic metrics on a cohort or anchor, and enumerates all specific metrics with their requirements. This differentiates it from sibling tools that are more specialized, though the description doesn't explicitly compare. The verb+resource combination is specific and unambiguous.
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 explains when to use cohort_id vs symbol+date, and which metrics need which parameters. It provides clear context but does not explicitly contrast with sibling tools like 'clusters' or 'decompose' that cover the same metrics. The guidance is thorough for the tool itself but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, nondestructive, idempotent, openWorld. The description adds rich behavioral details: explains each style's purpose, how filter_ranking works (ranking by distribution shift), prose style (plain-English summary), etc., going far 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear one-line summary, followed by a structured list of styles with concise explanations, then parameter details. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an explain tool with 3 parameters and an output schema (present but not shown), the description covers all necessary input semantics and behavioral context. It references sibling tool for one style, aiding contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates: explains `cohort_id` as a handle from search/cohort, `style` with a list of options and their meanings, `horizon` as forward trading days, and defaults.
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 'Narrative + rankings derived from a stored cohort' and lists specific styles, establishing a specific verb+resource. It references sibling tool `cohort` for one style, but does not comprehensively distinguish from all siblings like analyze or cohort_analyze.
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?
Provides explicit guidance for each style, e.g., 'Use to discover conditional structure before calling `cohort` with the winning filter.' However, it lacks when-not-to-use guidance and clear differentiation from similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the annotations (readOnlyHint, idempotentHint, etc.). It explicitly states the tool does NOT predict a single point return, but surfaces historical analogs. It details each mode's output, including the summary block and how to use it. No contradiction with 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 well-organized with headings for depth modes, filters, and args, and it front-loads the core purpose. While it is lengthy, every section provides necessary context for a complex tool. Minor redundancy could be trimmed, but overall it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, 3 depth modes, optional features), the description is remarkably complete. It covers all modes, filters, optional toggles, and even explains how to use the summary block. The output schema exists, so it appropriately avoids explaining return values in depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It explains each parameter's purpose, defaults, dependencies, and constraints (e.g., query as alternative to symbol+date, compare_with structure, fields allowlist). The args section is structured and comprehensive, adding immense value beyond the raw schema.
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 performs 'conditional-distribution analysis' and is the 'Chart Library core primitive'. It explains three depth modes with specific outputs. The verb-resource combination is precise, and while it doesn't explicitly distinguish from sibling tools like cohort_analyze or cohort_compare, the detailed mode explanations effectively define its unique role.
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 explicit guidance on when to use each depth mode, including constraints for 'full' mode (requires symbol+date+timeframe) and 'compare' mode (requires compare_with). It also explains when cohort_id is appropriate. However, it does not directly compare with sibling tools, leaving some ambiguity about when to choose this tool over alternatives.
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 mark it as readOnly, idempotent, and non-destructive. The description adds value by disclosing the internal composition (cohort_analyze, memory, narrative) and the structured output format. It also explains the trade-off between detail and primitives, which aids understanding beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections (HOW TO TURN THIS INTO A GOOD ANSWER, RESPONSE STRUCTURE, When to use, Args). Every major section earns its place by providing necessary guidance. Minor redundancy could be trimmed, but overall it is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, composite behavior, rich output), the description is remarkably complete. It covers what the tool does, how to use it, what the output fields mean (including field-by-field interpretation), when to choose alternatives, and parameter details. An output schema exists (not shown), but the description already explains the return value thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description fully carries the burden. All 7 parameters are explained in the 'Args:' block, including defaults, behaviors (e.g., timeframe default '1h' meaning current, '1d' lagging ~3 days), and the role of each boolean (include_memory, include_narrative). This compensates fully for the schema's lack of 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 it is a 'One-call decision-grade orchestrator' and the 'DEFAULT first call for any (symbol, date) anchor question.' It explicitly lists the components it composes and distinguishes from sibling tools by providing specific guidance on when to use decision_brief vs cohort vs analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance: it names this as the default first call, includes a dedicated 'When to use this vs the primitives' section detailing alternatives, and gives step-by-step instructions on how to interpret the output (e.g., read summary first, paraphrase frames, cite numbers). This fully supports correct tool selection and invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which indicate safe, non-destructive, repeatable behavior. The description adds significant behavioral details: basic mode runs per-holding cohorts in parallel, weight-averages distributions, and ranks tail contributors; symbol_intel returns prior observations, feature reliability, and accuracy history. It also notes that include_path_stats makes it slower. No contradictions with 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 well-structured with clear sections for modes, bullet points for arguments, and front-loaded purpose. However, it is somewhat verbose, especially the argument list which could be streamlined. Still, every sentence adds value and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with 0% schema coverage, the description provides complete coverage of all inputs. Output schema exists (not shown), but the description clearly states what each mode returns. The tool has moderate complexity, and the description is fully adequate for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter: holdings (list of dicts for basic mode), symbol (for symbol_intel), mode (basic/symbol_intel), horizons (forward horizons for basic), top_k_per_holding (cohort size), include_path_stats (enables MAE/MFE, slower), and lookback_days (history window). It specifies which parameters apply to which mode, adding meaning beyond the schema.
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 two distinct modes with specific purposes: 'Portfolio-level analysis' for basic mode and 'per-symbol track-record + Layer 5 memory' for symbol_intel. It uses a specific verb-resource combination, and the two modes are easily differentiated, helping the agent select the correct mode. It also distinguishes itself from sibling tools like 'cohort' or 'symbol_intelligence' by combining both concepts.
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 explicit usage context for each mode: basic is a 'PM-agent primitive' for multi-holding distributions, and symbol_intel is for per-symbol memory. However, it does not explicitly state when not to use the tool or compare it to alternatives like 'cohort' or 'symbol_intelligence'. It gives clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description discloses that the tool surfaces catalysts price hasn't reflected, involves frequency anomaly, tone shift, sentiment-price misalignment, and FinBERT. This enriches agent understanding of what the tool outputs.
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?
Description is structured with clear mode headings and bullet-like parameter assignments. Each sentence serves a purpose, no redundancy, and front-loads the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description focuses on inputs and behavior, which is sufficient. It covers all parameters and explains the output signals without needing to detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains all four parameters: mode with two values, symbol for pulse, min_pulse and limit for alerts, including defaults. This adds meaning beyond the bare schema.
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?
Description clearly states it provides narrative-change signals layered on price, with two distinct modes: 'pulse' for single-symbol and 'alerts' for market-wide anomalies. This distinguishes it from sibling tools like narrative_pulse and narrative_alerts by offering both functionalities in one tool.
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?
Explicitly describes when to use each mode: 'pulse' requires a symbol, 'alerts' uses min_pulse and limit with defaults. It does not mention when not to use this tool versus the specialized siblings, but the context is clear for correct invocation.
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 indicate idempotent and non-destructive behavior. Description adds context: reports land in Graham's inbox and feed roadmap. Could mention if a confirmation response is returned, but overall transparent.
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?
Concise: purpose first, then usage guidelines, then parameter list. No wasted words. Efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple 4-param tool with annotations covering safety and output schema, description provides complete context: what it does, when to use, where feedback goes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). Description includes a docstring with Args section explaining each parameter, adding meaning beyond type/defaults.
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 files feedback (error or improvement) to Chart Library. It distinguishes from sibling tools which are analytical or data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when something looks wrong or missing capability. Implies alternatives are other tools. Mentions feedback destination and roadmap impact.
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:

[![chart-library-mcp MCP server](https://glama.ai/mcp/servers/grahammccain/chart-library-mcp/badges/card.svg)](https://glama.ai/mcp/servers/grahammccain/chart-library-mcp)

Score Badge

Copy to your README.md:

[![chart-library-mcp MCP server](https://glama.ai/mcp/servers/grahammccain/chart-library-mcp/badges/score.svg)](https://glama.ai/mcp/servers/grahammccain/chart-library-mcp)

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/grahammccain/chart-library-mcp'

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