@romaco/mcp
OfficialServer Quality Checklist
Latest release: v0.0.2
- Disambiguation5/5
Each tool has a clearly distinct purpose: data loading, analysis, pattern detection, drawing, annotations, indicator management, alerts, paper trading, etc. There is no ambiguity between tools.
Naming Consistency5/5All tools follow the 'romaco_' prefix with a verb_noun pattern (e.g., add_alert, load_candles, detect_patterns), making the naming highly predictable and consistent.
Tool Count4/527 tools is slightly above the typical well-scoped range (3-15) but justified by the complexity of trading analysis and charting. Each tool earns its place, though the count is heavy.
Completeness5/5The tool surface covers the full lifecycle of chart analysis: data loading, market analysis, pattern detection, indicator management, drawing, alerts, paper trading, and thesis generation. No obvious gaps for the stated purpose.
Average 4.3/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.jsonto 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?
No annotations are provided, so the description must fully disclose behavior. It mentions alerts are shown visually when triggered, but omits details like whether the alert is persistent, if it can be removed, or what happens on creation (e.g., success confirmation). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences, front-loaded with the primary action, and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description lacks important context such as return value, error conditions, or whether the chart must be initialized. It is insufficient for an agent to fully understand the tool's behavior and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description does not add any additional meaning beyond the schema, such as explaining the direction enum values or providing examples. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a price alert on the chart and mentions triggered alerts are shown visually. It also references romaco_get_chart_context for viewing existing alerts, which distinguishes it from sibling tools like romaco_remove_alert and romaco_clear_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using romaco_get_chart_context to see existing alerts, providing some context for use, but it lacks explicit guidance on when to use this tool versus alternatives or any prerequisites (e.g., requires an active chart).
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?
No annotations provided, so description carries full burden. It discloses simulated nature and visual markers, but lacks details on execution behavior (e.g., immediate fill, market price vs limit) 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns (e.g., confirmation or order ID). It covers core purpose but leaves out expected return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra semantic meaning beyond what the schema already provides for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open', the resource 'simulated (paper) trading position', and distinguishes it from real trading. It also mentions visual feedback on the chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives among siblings. While the purpose is clear, there is no guidance on when not to use it or mention of alternative 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?
No annotations provided, so description carries burden. Offers parameter format guidance and default behavior, but does not disclose if adding an indicator is destructive, has limits, or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers indicator types, parameter formats, and defaults. Lacks error conditions or limits, but sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by providing examples per indicator type and noting default behavior ('Omit to use defaults'), going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Add' and resource 'technical indicator' with target 'chart'. Examples distinguish it from sibling tools like add_alert or add_drawing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like romaco_get_indicator_values or romaco_remove_indicator. Lacks exclusionary 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?
No annotations are provided, so the description bears full responsibility. It conveys a destructive action (removing all alerts) with no mention of reversibility, confirmations, or side effects. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is extremely concise and front-loaded. Every word is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description provides sufficient context: what it does and where. It could clarify if 'chart' refers to the current chart, but that is reasonably implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description naturally covers all needed information. Baseline for zero parameters is 4, and the description adds value by specifying the action and scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove', the resource 'all price alerts', and the location 'from the chart'. It distinguishes well from sibling tools like romaco_add_alert and romaco_remove_alert by specifying the scope (all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to clear all alerts), but does not explicitly mention alternatives such as romaco_remove_alert for individual removal. No guidance on 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?
With no annotations, the description carries full burden. It discloses the action (removal of drawings) and warns that it cannot be undone. However, it does not specify that other chart elements (indicators, alerts) are unaffected, which could be inferred but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains the action, second adds a critical warning. No wasted words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description is adequate. It states the action and irreversibility. Could be slightly more complete by clarifying scope (only drawings, not indicators or alerts), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (vacuously). Baseline for 0 params is 4, and the description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove all drawings from the chart' and lists specific types (trendlines, Fibonacci retracements, etc.), making the purpose obvious. It distinguishes from siblings like 'romaco_remove_alert' and 'romaco_clear_alerts' by specifying drawings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for clearing all drawings at once but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The irreversibility warning is helpful but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool resets to auto-fit all data, implying it overrides manual zoom/pan, but it does not disclose potential side effects such as whether it affects other chart states (e.g., indicators, drawings, multiple panes) or if it is destructive. More detail would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and contains no redundant or superfluous words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, single action), the description is largely complete for its intended use. However, it could be improved by noting whether the reset applies to all panes or just the current pane, and whether it preserves any user-applied settings (e.g., indicators).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema description coverage is 100% and the baseline is 4. The description adds no additional parameter info, which is acceptable since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset the chart view') and the specific behavior ('auto-fit all available data'). It distinguishes from sibling tools like romaco_set_zoom (manual zoom) and romaco_go_to_timestamp (navigation), making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('Use after zooming or panning to return to the default overview'). It provides clear context for usage but does not mention when not to use it or explicitly contrast with alternatives, though the sibling context implies differentiation.
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?
No annotations are provided, so the description must carry the full burden. It discloses that zoom is cumulative per call and mentions the default factor and reset alternative. However, it does not describe potential side effects, permissions needed, or behavior at extremes (e.g., max/min zoom level). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences, no fluff. The first sentence states the main purpose, and subsequent sentences add essential usage details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with full schema coverage and no output schema, the description is largely complete. It covers purpose, usage, and resetting. It could mention that zoom affects the current pane or visible range, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it restates the default factor and notes that calls are cumulative. The schema already describes factor, direction, and their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Zoom the chart in or out.' It specifies the action (zoom) and resource (chart), and distinguishes from siblings by mentioning 'Use romaco_reset_view to return to default fit.' No other sibling zoom tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: 'Each call zooms by the given factor (default 1.5x). Call multiple times for more zoom.' It also advises when to use an alternative: 'Use romaco_reset_view to return to default fit.' It does not explicitly state when not to use it, but the context is 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?
No annotations are provided, so the description fully handles transparency. It mentions the difference in behavior between normal mode and replay mode (viewport vs cursor). However, it does not disclose potential side effects (e.g., data loading) or error conditions (e.g., out-of-range timestamp).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence states the core action and mode differentiation, and the second provides clear use cases. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single parameter and no output schema, the description fully explains what the tool does, when to use it, and the parameter's unit. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, already stating the parameter 'timestamp' is in milliseconds. The description repeats this unit information, adding marginal value beyond the schema. No additional semantic details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: moving the chart viewport or replay cursor to a specific timestamp. It uses a specific verb ('move') and resource ('viewport/replay cursor'), and the context of 'revisit historical setups' distinguishes it from sibling tools like zooming or loading candles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('revisit historical setups or scrub through past patterns') but does not explicitly state when not to use it or mention alternative tools. It is adequate for guiding the agent.
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?
No annotations are provided, so the description carries the full burden. It states the tool removes an alert, which implies mutation, but does not disclose potential side effects, permissions, or reversibility. The description is adequate for a simple removal action but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loaded with the primary purpose and followed by a usage hint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description fully covers its usage. It tells what the tool does, how to find alerts to remove, and the parameter meanings are in the schema. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema already describes both parameters ('price' and 'direction') with clear descriptions. The tool description adds no extra parameter information beyond what the schema provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'specific price alert from the chart'. It distinguishes itself from siblings like 'romaco_add_alert' and 'romaco_clear_alerts' by specifying removal of a specific alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using 'romaco_get_chart_context' to view existing alerts before removal, providing a clear prerequisite step. However, it does not explicitly mention when not to use the tool or alternative approaches.
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?
No annotations provided, but description declares it's pure math with no side effects. Clearly states what it returns. Sufficient transparency for a non-destructive calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second details outputs and nature. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a pure math tool with no output schema. Lists all return values. Could mention synchronous nature, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with detailed descriptions. Tool description adds minimal extra beyond listing example inputs and outputs. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it calculates position size based on risk management rules. Lists inputs and outputs. Distinct from sibling tools that focus on chart actions, alerts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates when to use (before opening a trade) and that no data source is needed. Could explicitly state 'use this to compute position size' but provides clear 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?
No annotations are provided, so the description carries the full burden. It discloses that data persists across the session, and that the default source is free with no auth required. This goes beyond schema information. However, it does not mention whether reloading overwrites existing data or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a note, all front-loaded with the main function. Every sentence adds value, and there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the 5 parameters with full schema descriptions, no output schema, and sibling tools focused on analysis/charting, the description adequately explains the tool's role, persistence behavior, and source options. It could mention confirmation behavior on success, but it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The tool description does not add additional meaning beyond what the schema provides for parameters. The description's mention of source options is valuable but does not specifically enhance parameter semantics beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'load', the resource 'OHLCV candle data', and the effect 'persists in the MCP session'. It distinguishes this tool from siblings, which are analysis or chart manipulation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each source ('yfinance' vs 'raw'), notes that default source is free and requires no authentication, and indicates that data persists for subsequent analysis. It does not explicitly say when not to use the tool, but the context is clear enough.
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?
With no annotations, the description effectively discloses behavioral traits: server-side computation with fallback (if token is Pro), approximate output size (~500 tokens), and that it returns structured features instead of raw OHLCV. It does not mention state modifications, but analysis is likely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the main action. It efficiently lists contained analyses and adds prerequisite and return info. Very concise but packed with information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides sufficient context: what it does, prerequisite, server-side behavior, and output nature. It does not detail exact output format, but for a tool with no parameters, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds no parameter info. Per guidelines, 0 parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs full technical analysis on candle data and returns a MarketSummary. It lists comprehensive components (trend, patterns, levels, etc.), distinguishing it from sibling tools like romaco_detect_patterns or romaco_find_levels by being a broader analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to call romaco_load_candles first, providing a clear prerequisite. However, it does not specify when to use this vs. other analysis tools or mention alternative tools for specific analyses.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently describes the algorithm (K-means clustering, Volume Profile), the output format, and the underlying data source (candle data). It does not mention any destructive or permission-related behavior, which is appropriate for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) yet packs all essential information: purpose, algorithm, output details, and a prerequisite. Every sentence adds value, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the absence of an output schema, the description provides complete context: it explains what the tool does, how it works, what it returns, and what prerequisite actions are needed. No additional information is necessary for proper selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. Since there are no parameters, the description does not need to add parameter details. According to guidelines, baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds key support and resistance levels using K-means clustering and Volume Profile, specifies the number of levels returned (up to 3 each), and details the output fields (touch count, strength, last test timestamp). This distinguishes it from sibling analysis tools like romaco_detect_patterns and romaco_analyze_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Call romaco_load_candles first'), which is helpful, but it does not provide guidance on when to use this tool versus alternatives like romaco_detect_patterns or romaco_analyze_market. No explicit when-not or comparative context is given.
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?
Discloses that removal is by type, case-insensitive, and removes the first matching indicator if multiple exist. No annotations are provided, so the description carries the burden; it adequately covers key behavioral traits, though could mention side effects or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Essential information is front-loaded: the action and a usage hint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one param, no output schema), the description is fairly complete. It explains what the tool does and how to check active indicators. Could mention behavior when no indicator of the given type exists, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for indicatorType. The description adds meaning: 'Case-insensitive. Removes the first matching indicator if multiple exist,' which goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Remove a technical indicator from the chart by type.' The verb 'remove' and resource 'technical indicator' are specific, and 'by type' distinguishes it from siblings like 'romaco_add_indicator' or 'romaco_remove_alert'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by referencing 'romaco_get_chart_context' to see active indicators before removal. Does not explicitly mention when not to use or alternatives, but the guidance is helpful for correct usage.
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?
No annotations provided, so the description carries the full burden. It discloses key behaviors: headless operation (returns MarketSummary without browser), preset application, and loading of OHLCV data. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, front-loading the core purpose. Every sentence provides necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 1 required, and no output schema, the description covers the overall behavior, headless mode, returned MarketSummary, and presets. It is sufficiently complete for an agent to use correctly, though it could mention pagination or data limits (already in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by noting the default preset ('omit for institutional') and listing available presets, which aids understanding beyond the schema enum. It also explains the source parameter options succinctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'One-command chart setup: loads OHLCV data, runs full market analysis, and applies a professional indicator preset'. It uses specific verbs and identifies the resource (chart setup), and distinguishes itself as the recommended first tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this as the first tool to call for any analysis session and mentions headless vs browser-connected behavior, providing clear usage context. However, it does not explicitly state when not to use it or list 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?
No annotations are provided, so the description carries the burden. It transparently describes the return structure (id, indicators, alias) and does not mention any side effects. Since it is a read-only list operation, this level of detail is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete: it explains the return fields and provides a key usage example. It fully addresses the agent's needs for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage (by virtue of no properties), the description correctly omits parameter details. The baseline for zero parameters is 4, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing chart panes (main candlestick pane and indicator subpanels). It specifies what each pane returns (id, indicators, alias), distinguishing it from sibling tools like romaco_add_drawing or romaco_add_indicator by focusing on enumeration rather than modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage: using the returned `id` as `paneId` on romaco_add_drawing. While it doesn't explicitly state when not to use this tool, the context and sibling list imply that it's for obtaining pane references, which is sufficient for a simple listing tool.
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?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits like server-side vs local synthesis, result size (<2 KB), the instruction to offer drawing and ask first, and the required disclaimer. It lacks details on potential side effects but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. Every sentence adds value: prerequisite, token info, behavioral instruction, and disclaimer. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description fully explains the tool's input (none needed beyond loaded candles), output (thesis components), and special behaviors (stand aside, token usage, drawing offer). It is complete for a 0-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds no parameter info but explains the tool's output and behavior, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to produce an actionable trade thesis with bull/bear debate, verdict, confidence, setup, and invalidation. It uses specific verbs and distinguishes from siblings like romaco_analyze_market and romaco_detect_patterns by focusing on thesis generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (load candles and setup chart) and indicates when the tool will stand aside. While it doesn't directly compare to siblings, the context is clear. It also warns not to call romaco_annotate automatically.
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?
No annotations provided, so description carries full burden. It discloses visual hierarchy, replacement behavior (group 'romaco-thesis'), leaves user drawings untouched, and the 'stand_aside' guard that prevents false entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is slightly long but well-structured with front-loaded main action and subsequent details. Each sentence adds value, though minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, description fully covers prerequisites, behavior, side effects, and guard condition. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters; description correctly adds no param info. Baseline 4 is appropriate since no parameters need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool annotates a trade thesis on the chart with visual hierarchy, distinguishing it from siblings like 'romaco_draw_pattern' or 'romaco_thesis_batch'. It specifies the context (support/resistance faint, entry/stop/target bold) and the 'stand_aside' guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites: requires user acceptance, <McpBridge /> mounted, candles loaded. Mentions re-running replaces previous annotation. Lacks a clear 'when not to use' or alternatives among siblings.
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?
With no annotations provided, the description fully carries the burden. It transparently discloses that data comes from yfinance (free), analysis is deterministic (no LLM, no hallucination), and that the top symbol is automatically loaded into session. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 7 sentences, which is reasonably concise given the complexity. It is front-loaded with the main purpose, then details the method, then post-processing steps. Slightly verbose but each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is complete. It explains the return format (ranked table by R/R × confidence), the data source, the analysis method, and the recommended follow-up actions. The disclaimer is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described in schema). The description adds default values for lookback (300) and timeframe ('1d'), which are not in the schema. It also provides practical examples for the symbols parameter. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes multiple tickers, compares setups, and returns a ranked table sorted by R/R × confidence. It distinguishes itself from the sibling tool romaco_thesis (single ticker) by emphasizing 'multiple tickers in one call'. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for multiple tickers) versus alternatives (romaco_thesis for a single ticker). It provides explicit instructions on what to do after returning results (offer to draw a chart, call other tools). However, it does not explicitly state when not to use it or mention alternatives by name.
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?
With no annotations, the description fully discloses behaviors: returns base64 image, costs 300-800 KB (PNG) or 100-300 KB (JPEG), gated, requires acknowledgeHighTokenCost=true, otherwise returns error. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in clear, informative sentences. It could be slightly more concise by combining cost and gated statements, but every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers purpose, costs, gating, and usage guidelines. It omits potential limitations like image content exactness or timeouts, but is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 significant context beyond schema, such as token costs per format, gated behavior, and error handling. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture the current chart as a base64 image for vision-enabled models,' which is a specific verb+resource. It distinguishes from sibling tools like romaco_get_chart_context or romaco_get_visible_candles by focusing on image capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Only opt in when the USER explicitly asked for a visual snapshot — e.g. to share, to confirm placement, or to feed a vision LLM.' This provides clear when-to-use guidance and implies when not to use (e.g., if the user hasn't asked).
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?
With no annotations, the description fully details behavioral traits: returns fields (kind, confidence, etc.), zombie pattern discarding logic, and cost implications of acknowledgeHighTokenCost. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but front-loaded with patterns. Some redundancy could be trimmed, but it earns its length with necessary technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return fields, zombie pattern behavior, prerequisites, and cost tradeoffs. It is fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema coverage and the description adds context about token cost and when to set it, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans candle data for classical chart patterns, listing specific pattern types. It uses a specific verb 'detect' and resource 'candle data', distinguishing it from siblings like romaco_find_levels or romaco_get_indicator_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear prerequisites ('Call romaco_load_candles first') and a follow-up action ('To draw a detected pattern, offer romaco_draw_pattern'). It does not explicitly state when not to use it, but the context is strong.
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 fully discloses the token cost difference (1 KB compressed vs 80 KB raw), the condition for opting into the raw payload, and what the raw payload includes (visible candles, drawings with points, indicator params, capability registries). With no annotations, the description carries the full burden and excels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, and every sentence adds value. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and no output schema, the description covers default contents, optional raw contents, and usage advice. It is fully self-contained and leaves no ambiguity about behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter acknowledgeHighTokenCost is documented in both schema and description. The description adds significant behavioral context beyond the schema's warning: it specifies what exactly the raw payload contains and reiterates the condition for use. Schema coverage is 100%, so baseline is 3, but the added value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a compressed snapshot of the chart state, listing specific contents (last price, pane list, indicator/drawing/alert counts, visible range, zoom, render backend). This distinguishes it from sibling tools like romaco_get_visible_candles or romaco_get_indicator_values by offering a broader summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises when to use the raw payload (only when the user explicitly asks and accepts token cost), implying the compressed version is the default. It does not explicitly compare with siblings, but the purpose is clear enough for appropriate 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?
No annotations provided, so description carries full burden. It discloses token cost, compression behavior, and the difference between summary and raw array. Lacks details on rate limits or idempotency, but sufficient for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded first sentence states core purpose. Subsequent sentences cover cost and usage caveats without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers functionality, cost, and when to choose raw vs. summary. References sibling tool for analysis, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single boolean parameter has schema description with cost warning. The description adds context on when to use raw mode and approximate size (70 KB), reinforcing and clarifying the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes OHLCV candles visible in the chart viewport, listing specific statistics (count, first/last, OHLC range, etc.). It distinguishes from siblings by explicitly recommending romaco_analyze_market for analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the compressed summary vs. raw array ('only opt in when user explicitly asked for raw candles'). Also suggests alternative tool for analysis, making usage boundaries clear.
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?
No annotations provided, so description carries full burden. It discloses the return information (category, point count) and implies read-only behavior by saying 'list'. Could explicitly state it is non-destructive, but overall clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no wasted words. The first sentence states the action and output, the second provides usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a list tool with no parameters and no output schema, the description fully covers what the tool does, what it returns, and how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined in input schema. According to scoring guidelines, 0 parameters results in a baseline of 4. The description adds no parameter info because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists drawing templates with category and required point count, distinguishing it from sibling tools like romaco_add_drawing by explicitly positioning it as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this BEFORE romaco_add_drawing to choose a valid drawingType and know how many anchor points it expects.' This provides clear when-to-use and how to use 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?
No annotations provided, so description carries full burden. Discloses optional fields (style, paneId, groupId), how style is mapped server-side, and group inclusion/exclusion behavior. Lacks mention of rate limits or idempotency, but mutation intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient: front-loaded with core action, then key details (templates, point requirements, optional fields, helper tools, subpanel usage). Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Handles complexity well: 6 parameters, nested objects, 33 templates. Covers prerequisites (helper tools), optional fields, and subpanel use case. No output schema, but mutation tool doesn't need return value explanation. Fully prepares agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant meaning: enumerates 33 template types, explains point counts for different templates, clarifies paneId with example (RSI=70), and describes style mapping. Far exceeds schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States 'Draw a technical-analysis shape on the chart' with a specific verb and resource. Lists 33 templates explicitly, distinguishing it from siblings like romaco_clear_drawings or romaco_draw_pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use romaco_list_templates to discover point counts, romaco_get_visible_candles for anchor timestamps/prices, and romaco_list_panes for indicator sub-panels. Includes when-not-to-use info via sibling references.
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?
Despite no annotations, the description discloses key behaviors: patterns are re-detected deterministically, only recent patterns qualify, drawing groups are atomic and user drawings untouched, prerequisites (mounted MCP bridge and loaded candles), and honest answer if no match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but slightly lengthy. However, every sentence adds value and it is clearly structured with front-loaded main action, details, and usage conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the complexity of the tool, the description covers prerequisites, behavior under no match, drawing group management, and specific pattern elements drawn. It leaves no major gaps for an AI agent to understand invocation and outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds meaning: explains that omitting 'kind' draws highest-confidence recent pattern, clarifies 'rank' as 0-based confidence index, and introduces the concept of 'recent patterns'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action (draw geometry of detected chart pattern), enumerates pattern families and what is drawn for each, and distinguishes from sibling tools like romaco_add_drawing by stating it is for detected patterns after user acceptance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after romaco_detect_patterns or romaco_thesis finds something, and only after the user accepts. Indicates when not to use (if no pattern detected, nothing is drawn) and implies alternatives exist for manual drawing.
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?
With no annotations, the description fully discloses behavioral traits: it is a read operation, returns a compressed summary by default, warns about high token cost for raw series, and details state classifications per indicator type (RSI, MACD, BOLL, default). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and front-loaded with purpose and output. Every sentence serves a purpose: purpose, output, state classification, cost modes, and usage condition. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 params, no output schema), the description fully explains the output format (compressed and raw) and state classification, covering all necessary context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds substantial value: clarifies indicatorId as preferred and indicatorName as fallback, explains the default behavior of acknowledgeHighTokenCost=false, and warns of cost implications. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the current state of an indicator on the chart' with specific output details (last value, previous value, delta, state classification). It distinguishes itself from sibling tools like romaco_get_chart_context by focusing solely on indicator values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the compressed default vs. the raw series via acknowledgeHighTokenCost, stating 'Only opt in to raw series when the user explicitly asked for bar-by-bar values' and explaining token cost trade-offs.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/romaco-labs/romaco-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server