tradingview-mcp

Server Quality Checklist

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

Latest release: v0.7.1
Disambiguation2/5
Several tools have overlapping purposes, such as the volume scanners (volume_breakout_scanner, volume_confirmation_analysis, smart_volume_scanner), the EGX sector tools (egx_sector_scan, egx_sector_scanner), and the multiple backtesting tools. While descriptions attempt to differentiate, an agent could easily miscategorize or select the wrong tool.
Naming Consistency4/5
The naming convention is predominantly snake_case, which is consistent. However, minor inconsistencies exist, such as 'egx_sector_scan' vs 'egx_sector_scanner' and varying suffixes like 'analysis', 'scanner', 'scan', which slightly reduces clarity.
Tool Count2/5
With 44 tools, the server is overpopulated. Many tools could be consolidated (e.g., volume scanners into one parameterized tool, backtests into a unified interface). The high count suggests a lack of modularization, making the surface area difficult to navigate.
Completeness4/5
The server covers a broad spectrum: EGX-specific tools, general scanners, individual analysis, multi-timeframe, sentiment, news, combined analysis, backtesting, paper trading, market regime, crypto, stocks, futures, and options. Minor gaps (e.g., fundamental data, advanced order types) exist, but overall the domain is well-covered.
Average 4.2/5 across 44 of 44 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 344 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 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

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 agent knows it's a safe read operation. The description adds 'Detailed volume confirmation analysis' but no further behavioral traits like data sources or processing details. Given annotations, the description is adequate but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus a list) and front-loaded, but it lacks structure and depth. The parameter list is barebones; it could be more informative without increasing length significantly.
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 3 parameters, no output schema, and numerous sibling tools, the description is incomplete. It does not explain what the analysis returns, how to interpret results, or when to use it over similar tools like coin_analysis or volume_breakout_scanner.
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%, so the description must compensate. It minimally clarifies parameters ('Coin symbol', 'Exchange name', 'Time frame for analysis') but provides no formats, constraints, or accepted values beyond basic labels. It does not utilize the default values for exchange and timeframe.
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 states 'Detailed volume confirmation analysis for a specific coin,' which clearly indicates the tool's function and differentiates it from sibling tools like volume_breakout_scanner. However, it does not explicitly contrast with siblings, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. It only describes the tool itself without usage 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=true and destructiveHint=false, so the safe read nature is clear. The description adds that it uses multi-timeframe data, which is some additional context, but does not disclose other behavioral traits like rate limits, data freshness, or whether it's historical or real-time.
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 structured as a clear purpose sentence followed by a compact parameter list. Each line adds specific value. It is concise without being vague, and the first sentence effectively front-loads the 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 no output schema, the description does not explain return values, which is a gap. It also lacks context on what makes the analysis 'advanced' or how it compares to simpler pattern scanners. The annotations and schema provide basic structure, but the description could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description carries the full burden and provides meaningful explanations for each parameter: exchange name, base timeframe examples (5m, 15m, 1h, 4h), pattern length range (2-4), minimum size increase (percentage), and limit. This compensates well for missing schema descriptions, though it could be more precise (e.g., valid exchange enum values).
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 'Advanced candle pattern analysis using multi-timeframe data', specifying the verb (analysis) and resource (candle patterns). However, it does not differentiate from sibling tools like consecutive_candles_scan or volume_breakout_scanner, which also analyze patterns, reducing distinctiveness.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description only lists parameters, leaving the agent to infer usage context from the name and siblings.
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 destructiveHint=false, signaling a safe read operation. The description adds no additional behavioral context beyond parameter documentation, such as rate limits or output format.
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 concise with a clear header and bullet-like parameter list. It front-loads the purpose and quickly documents arguments, though it could be more structured with explicit parameter tables.
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?
With three parameters, no output schema, and annotations covering safety, the description adequately documents inputs but fails to describe output (e.g., Fibonacci levels) or the analysis algorithm. Among many technical sibling tools, this feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides examples for symbol ('COMI', 'TMGH', 'FWRY') and enumerates allowed values for lookback and timeframe. This compensates for the missing 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 states 'Fibonacci retracement analysis for EGX stocks,' which clearly defines the tool's purpose with a specific verb and resource. However, it does not explicitly distinguish from sibling tools like egx_market_overview or other technical analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like bollinger_scan or volume_breakout_scanner. The description only lists parameters without explaining the context for choosing this 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 indicate readOnlyHint=true and destructiveHint=false, so the description's mention of 'Get' aligns. The description adds parameter details but does not disclose additional behavioral traits such as rate limits or whether the response is paginated. Given the annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, followed by two lines for parameters. Every sentence adds value with no filler. It is front-loaded with the primary action.
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?
With no output schema, the description should outline what the response contains (e.g., indices, sectors, top stocks). It only says 'comprehensive overview', which is vague. For a simple tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning the schema only provides titles and defaults. The description adds valuable information: it lists allowed timeframe values and states a maximum of 20 for limit. This significantly improves parameter understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a comprehensive overview of the EGX market using the verb 'Get'. However, it does not explicitly differentiate this tool from siblings like egx_sector_scan or egx_index_analysis, though the name implies a broad market view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over siblings. There is no mention of prerequisites, when not to use it, or alternative tools for more specific queries.
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 destructiveHint=false, so the safety profile is clear. The description adds the licensed data source (Marketaux) as behavioral context, but does not discuss rate limits, pagination, or response structure. This adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one-line purpose followed by a clean Args list. Every sentence is informative and there is no redundant text. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and moderate complexity (3 parameters). The description explains parameters well but does not mention what the tool returns (e.g., a sentiment score, article list, or aggregated metric). This omission reduces completeness for agent planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, so the description must compensate. It does so by providing examples for symbol, enumerating category values ('crypto', 'stocks', 'all'), and explaining limit as 'Max articles to analyse'. This covers all parameters meaningfully, though it could be more precise (e.g., symbol format).
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 states 'News sentiment for stocks and crypto', which clearly identifies the tool's function as retrieving sentiment analysis of news for given assets. However, it does not explicitly differentiate from the sibling tool 'financial_news' (which may fetch raw news) nor describe the output format, so clarity is slightly reduced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many siblings (e.g., financial_news, market_snapshot). The description lacks any 'when to use' or 'when not to use' information, leaving the agent to infer context from the name alone.
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?
The description adds beyond annotations by specifying the return format (list[dict] on success, structured error envelope on failure). Annotations already indicate read-only and non-destructive nature, so the additional transparency about error handling is valuable but not exhaustive.
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 reasonably concise with two paragraphs separating high-level purpose and return type details. However, it could be more structured (e.g., bullet points) for quick scanning. Minimal 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 tool has 3 parameters with 0% schema coverage and no enum hints, the description should compensate but fails to explain parameter semantics. The presence of an output schema helps for return values but incomplete overall.
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%, yet the description does not explain the parameters. It mentions 'exchange and timeframe' but does not describe limit, exchange values, or timeframe formats. Description provides minimal compensation for the missing parameter documentation.
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 returns top losers for an exchange and timeframe, and lists supported asset types (crypto and stocks) and specific exchanges. This distinguishes it from siblings like top_gainers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching top losers but does not provide explicit guidance on when to use this tool versus alternatives like top_gainers or other screeners. No when-not-to-use or prerequisites are mentioned.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. However, it adds no additional behavioral context such as rate limits, data freshness, or what happens when no patterns are found. The description contributes minimal extra transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a one-line summary followed by a clear parameter list. Every sentence provides necessary information, and the structure is front-loaded. No redundant or tangential content.
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 no output schema, the description adequately explains the tool's purpose and parameters but omits details about the output format (e.g., list of coins with scores) and error conditions. For a scanning tool, these would enhance completeness. The description is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter, including pattern_type as 'bullish (growing candles) or bearish (shrinking candles)', candle_count as 'Number of consecutive candles to check (2-5)', and min_growth as 'Minimum growth percentage for each candle'. All six parameters are covered, adding clear 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 it scans for coins with consecutive growing/shrinking candles pattern, using specific verb 'scan for' and resource 'coins with consecutive...pattern'. It distinguishes from siblings like bollinger_scan or volume_breakout_scanner by specifying the unique pattern type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use when scanning for a specific candle pattern but offers no explicit guidance on when to use this tool vs alternatives (e.g., advanced_candle_pattern, volume_breakout_scanner). No prerequisites or exclusions are mentioned.
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 description adds no extra behavioral context. It does not contradict annotations but also does not disclose whether the plan is based on live data or historical patterns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences followed by a clean args list. Every sentence adds value, with no redundant or unnecessary text.
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 no output schema and only two parameters, the description is adequate but lacks detail on what a 'full trade plan' includes (e.g., entries, exits, risk management). It could be more complete for agents needing return format expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides example values for symbol ('COMI', 'TMGH', 'FWRY') and lists timeframe options (5m, 15m, 1h, 4h, 1D, 1W, 1M) with default 1D, adding significant 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?
The description clearly states the tool generates a full trade plan for a specific EGX stock, using a specific verb 'Generate' and resource 'full trade plan'. It distinguishes from siblings like multi_timeframe_analysis which provide analysis but not a complete plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as multi_agent_analysis or multi_timeframe_analysis. The description does not specify prerequisites or exclusions, leaving the agent to infer usage 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 declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds parameter details but does not disclose output format or behavior beyond 'identifies hot/cold sectors and top picks.' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one introductory sentence followed by a clear parameter list. No unnecessary words, and the key purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good parameter details but lacks information about the output format (e.g., what fields are returned). For a tool with no output schema, this is a gap given the complexity of a sector rotation scanner.
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%, but the description fully specifies acceptable values for all four parameters: timeframe options (5m, 15m, 1h, 4h, 1D, 1W, 1M), ranges for top_n_sectors (1-18), top_n_stocks (1-10), and min_stock_score (0-100). This adds significant 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 the tool's purpose: 'Sector rotation scanner for EGX — identifies hot/cold sectors and top picks.' It uses a specific verb (scanner) and resource (EGX sectors), distinguishing it from siblings like top_gainers or egx_sector_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like bollinger_scan or volume_breakout_scanner. Usage is implied through the purpose but lacks when-to-use/when-not-to-use 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 declare readOnlyHint=true and destructiveHint=false, so the description adds the debate structure and final trading decision output. No contradictions, but no additional disclosure of costs, rate limits, or other behaviors 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 main description is a single clear sentence, and the Args block is well-structured with examples. Every sentence adds value, though the Args block could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-agent debate, three parameters, no output schema), the description covers inputs with examples and explains the return value (structured debate with final decision). No missing critical details.
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%, but the description's Args block provides extensive examples for symbol (crypto and stock formats), exchange (full list of supported exchanges), and timeframe (concrete intervals). This adds significant meaning beyond the schema's bare types and 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 verb 'Run' and the resource 'multi-agent debate (Technical, Sentiment, Risk)' for a specific symbol. It distinguishes itself from sibling tools like market_sentiment or combined_analysis by explicitly naming the three-agent debate structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as market_sentiment, combined_analysis, or multi_timeframe_analysis. The description only says 'for a specific symbol' but does not specify contexts or prerequisites.
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 the tool as read-only and non-destructive. The description adds that it shows constituent performance with full indicators, providing context beyond the 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?
The description is concise, front-loaded with the tool's purpose, and uses a clear arg listing. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fails to explain the return format or what 'full indicators' means. For a complex analysis tool, this leaves significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing acceptable values for 'index' and 'timeframe' and noting 'limit' max. This adds significant meaning beyond the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes an EGX index with constituent performance and full indicators, listing specific index options. This distinguishes it from siblings like top_gainers or egx_sector_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for index analysis via parameter examples, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true. Description adds that data comes from Yahoo Finance, indicating external dependency, and lists the asset classes covered. No contradictory information.
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 and front-loaded. Two sentences clearly convey scope and data source with no redundant 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 zero-parameter tool with no output schema, the description adequately sets expectations by enumerating the categories of data returned. Could be more specific but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so schema coverage is 100%. Baseline score of 4 applies as description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies exact content: 'major indices, top crypto, FX rates, and key ETFs', clearly distinguishing it from sibling tools that focus on specific sectors or analysis. Verb is implied but clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies a broad overview, but does not mention alternatives or exclusions, leaving agents to infer usage from 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 declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'Real-time price quote' is consistent but adds no new behavioral information beyond the real-time nature. No disclosure of rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the purpose, second provides parameter details with examples. No wasted words, front-loaded with the core function.
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 tool with one parameter and no output schema, the description is adequately complete. It explains what the tool does and how to use the parameter. It could optionally mention the return value (e.g., price number), but it's not necessary given the title 'Real-Time Price Quote' and the simple interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'symbol' string parameter without description. The description compensates by listing concrete examples (e.g., AAPL, BTC-USD, ^GSPC) and explaining the format for different asset types, which significantly adds meaning beyond the schema. Given 0% schema coverage, this is valuable.
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 provides a 'Real-time price quote from Yahoo Finance' and lists supported asset types (stocks, crypto, ETF, index), distinguishing it from sibling tools like stock_prices or market_snapshot. The examples of symbols add specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a single price quote is needed, but does not explicitly state when to use this tool versus alternatives like stock_prices (which may provide historical data) or market_snapshot. No guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'production' and 'actionable setups', but doesn't disclose additional behavioral traits like data freshness, rate limits, or what the score means. Bare minimum 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?
Two sentences plus a clear, bullet-like Args list. Front-loaded with purpose. Every part earns its place; no 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?
Covers purpose and parameters well, but lacks description of return format (what does the ranking return?) and no output schema. For a read-only screening tool, this is nearly sufficient, but missing output details slightly reduces completeness.
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 the description compensates fully: it lists each parameter with allowed values (timeframe: 5m,15m,1h,4h,1D,1W,1M; min_score: 0-100; index_filter: EGX30, EGX70, etc.; limit: max 50) and defaults, adding significant meaning beyond the schema's types.
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's a 'stock ranking engine for EGX' that 'finds strong stocks with actionable setups,' which is specific and distinguishes it from siblings like 'stock_screener' (generic) and 'egx_market_overview' (overview).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter hints but no explicit guidance on when to use this tool vs alternatives (e.g., 'use for screening stocks by score, timeframe, or index; for market overview use egx_market_overview'). No exclusions or prerequisites.
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=true and destructiveHint=false. The description adds value by explaining strategy-specific prerequisites (e.g., warmup period for rsi_pullback and triple_ema), but does not discuss rate limits, failure modes, or data frequency constraints. The added context is sufficient for a read-only 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an 'Args' section, front-loads the purpose, and each sentence is informative. No unnecessary words; coverage is comprehensive in a compact format.
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?
No output schema exists, and the description does not specify the return format (e.g., metrics dictionary, data types). While it mentions 'institutional-grade metrics', it fails to describe what the tool actually returns, which is needed for agent invocation.
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 all 9 parameters with examples (symbol), lists valid strategies and periods, states defaults for initial_capital, commission_pct, slippage_pct, interval, include_trade_log, and include_equity_curve. It adds 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 uses the verb 'Backtest' and specifies the resource as 'a trading strategy on historical data with institutional-grade metrics'. It distinguishes this tool from siblings like 'compare_strategies' and 'walk_forward_backtest_strategy' by its focus on single-strategy backtesting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context, such as the warmup requirement for certain strategies, but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks direct exclusions or guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and destructiveHint, and the description adds value by enumerating the report contents (capital, PnL, drawdown, etc.), which is beyond the annotations. No contradictions or missing behavioral context for this simple read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists key elements efficiently. 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 tool with no parameters and no output schema, the description provides a thorough list of returned information. It could specify format details (e.g., percentages vs absolute numbers), but the current description is sufficient for an AI agent to understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and description need not add param info. The description compensates by detailing what the report contains, which is effectively the parameter impact.
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 returns a paper-trading account report with specific elements like capital, PnL, drawdown, etc. It distinguishes itself from siblings by focusing on status rather than actions like reset or step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking current account status but does not explicitly state when to use it over alternatives or provide exclusions. Siblings like paper_reset and paper_step hint at when to use this tool, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds value by specifying the return format (list of dicts or error envelope) and a constraint (max limit 50). However, it does not disclose response size or rate limits. Overall, it provides moderate additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with clear Args and Returns sections. It is informative but slightly verbose (e.g., 'Returns list[dict]' is redundant given output schema exists). Still, every sentence contributes value, and it is front-loaded with the main purpose.
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 that the tool has 4 optional parameters with defaults and an output schema, the description covers parameters and error behavior adequately. It does not explain the concept of Bollinger Band rating beyond the number mapping, but this is acceptable for domain-specific tools. Overall, it is complete enough for effective use.
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 must fully explain parameters. It does: exchange with examples, timeframe with full list, rating with numeric range and label mapping, limit with max value. This adds significant meaning beyond the bare schema properties.
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 'Filter coins by Bollinger Band rating.' It uses a specific verb ('filter') and resource ('coins'), and the criterion is explicitly named. Sibling tools like 'bollinger_scan' and 'coin_analysis' serve different purposes, so this tool is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only describes parameters and basic functionality. Usage context is implied from the tool name and parameters, but no when/when-not advice or alternative tool references are 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details: returns list[dict] on success, and on failure returns a structured error envelope with code and retryable flag. It also specifies max limit of 30. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the purpose in one sentence, followed by a clear args list and return type. Every sentence is informative, though the args could be more structured (e.g., bullet points).
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 presence of an output schema, the description provides sufficient context: parameters are fully documented, return type and error envelope are described. It lacks explanation of error codes or retryable semantics, but overall is adequate.
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 explains all 5 parameters, including defaults, ranges (e.g., rsi_range values with numeric bounds), and purpose. This compensates entirely for the lack of schema-level 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 'Smart volume + technical analysis combination scanner,' using a specific verb (scanner) and resources (volume and technical analysis). This distinguishes it from sibling tools like volume_breakout_scanner (purely volume) and bollinger_scan (purely technical).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combining volume and technical analysis but does not explicitly state when to use this tool versus alternatives or provide exclusions. It lacks guidance on context or prerequisites.
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 read-only and non-destructive behavior. The description adds context beyond annotations by detailing the return format (list[dict] or structured error envelope) and the use of Bollinger Bands, though it omits rate limits or auth specifics.
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 front-loaded with purpose and structured into Args and Returns sections. It is concise with no redundant sentences, though slightly more brevity could be possible.
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 has an output schema and context signals show few parameters, the description covers purpose, parameters, return format, and error handling completely. Annotations provide safety context, making it fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter: exchange (lists valid values), timeframe (lists valid values), limit (max 50). This adds significant 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?
The description clearly states 'Return top gainers for an exchange and timeframe using Bollinger Band analysis', specifying a verb, resource, and method. It distinguishes from siblings like 'top_losers' and 'bollinger_scan' by targeting gainers specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for screening top gainers but does not explicitly state when to use this tool versus alternatives or provide exclusions. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: it lists sectors when sector parameter is empty and provides example sector values. 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 brief, front-loaded with purpose, and uses bullet points for parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's behavior and all parameters, but lacks details about output format or pagination. No output schema exists, so this is a minor gap.
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 by explaining each parameter's meaning, default, allowed values for timeframe, and the max limit constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scan' and the resource 'EGX stocks by sector'. It also notes a special behavior: showing available sectors if none specified, which helps differentiate from sibling tools like egx_sector_scanner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to scan by sector or list sectors) but provides no explicit guidance on when not to use or alternatives among siblings like egx_market_overview.
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 readOnlyHint=true and destructiveHint=false. Description adds that it's from Marketaux (licensed) and provides real-time data, adding useful context beyond annotations 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?
Description is concise: one line for purpose, then bullet-like list of parameters. No wasted words, front-loaded with key information.
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?
Input parameters are well explained, but output is not described. However, given it's a news feed and annotations are present, the description is mostly complete for usage.
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 explains each parameter: symbol (optional filter and examples), category (possible values), limit (max items). This adds essential 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?
Description clearly states 'Real-time financial news via Marketaux', specifying verb (fetch) and resource (financial news). It distinguishes from siblings like market_overview or gainers by focusing on news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lists parameters but does not provide explicit when-to-use vs alternatives. The purpose is implied, but no guidance on when not to use this tool or comparison with siblings.
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=true and destructiveHint=false, so the agent knows it's safe. The description adds return format details (OHLCV + % change) and sorting behavior, but does not disclose any further behavioral traits or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-sentence purpose statement, followed by a concise list of parameters with defaults, and a brief note on the return type. No extraneous information.
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 no output schema, the description adequately specifies the return structure (Dict with total_available and list of contracts with OHLCV + % change). However, it could mention pagination or ordering details for completeness.
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 provides no parameter descriptions (0% coverage), so the description fully compensates by explaining each parameter's meaning, valid values (e.g., category enum, exchanges us/global), and defaults. This is exemplary for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sorted by trading volume' and the resource 'Top futures contracts', making the purpose unambiguous. It distinguishes from siblings like futures_top_movers which likely have different sorting criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as futures_top_movers or futures_category_snapshot. Usage context is implied by the parameter documentation, but no when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint) already indicate a safe read operation. The description adds behavioral context: returns OHLCV quotes, mentions standard watchlist, and provides example symbols.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and structured with Args and Returns sections. Every sentence adds value without unnecessary verbosity.
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?
Despite no output schema, the description explains return values (OHLCV quotes) and gives concrete examples. Parameter is fully documented. Complete for a simple snapshot 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% for the only parameter 'category'. The description compensates fully by listing all allowed values (equity_index, energy, metals, agriculture, etc.) and providing examples of symbols per category.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Quote' and the resource 'all major front-month contracts in a specific futures category'. It distinguishes from siblings like futures_market_overview or futures_watchlist by focusing on front-month contracts per category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description (when you need quotes for a specific category of front-month futures), but there is no explicit guidance on when not to use or alternatives among sibling tools.
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 include destructiveHint: true, indicating destructive behavior. The description adds context by specifying that the tool defaults to two specific strategies and that it refuses overwrite without confirm=true. 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-structured: a clear summary sentence, followed by a note on default strategies and the confirm condition, then a detailed bullet list of parameters. It is slightly lengthy but efficiently organized with no wasted 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?
The description covers the tool's purpose, default behavior, all inputs, and a key condition. No output schema is provided, and the description does not specify return values or success/failure indicators. However, for a creation/reset tool, the behavior is well-explained.
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 8 parameters with defaults but zero descriptions. The description explicitly explains each parameter's meaning and purpose (e.g., 'confirm: Required true to wipe an existing account', 'initial_capital: Starting fake capital in USD'). This fully compensates 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 the tool's purpose: 'Create or wipe the paper-trading account'. It specifies the resource (paper-trading account) and the actions (create or wipe). Sibling tools include paper_step and paper_status, which are distinct, so differentiation is clear.
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 a key usage condition: 'Refuses to overwrite an existing account unless confirm=true.' This tells the agent when to use the confirm parameter. However, it does not explicitly compare with sibling tools like paper_step or paper_status, so guidance on when to reset vs advance vs check status is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds parameter constraints (no exchange prefix, allowed values) but does not disclose additional behavioral traits like return format, rate limits, or error handling. Adequate but not rich 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?
The description is well-structured with a bold headline, usage guidance, example, and a clear Args list. Every sentence is informative and no wasted 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?
The description effectively covers purpose, usage, and parameters. However, it lacks information about the output format or structure, which could be helpful given no output schema. Nearly complete but with a minor gap.
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?
Input schema has 0% description coverage, so the description must fully explain parameters. It does: symbol is 'Bare ticker, no exchange prefix' with examples, exchange lists allowed values, timeframe lists allowed values. Each parameter is clearly explained.
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 combines TradingView technical analysis, news sentiment, and financial news. It distinguishes from siblings like coin_analysis and multi_timeframe_analysis, and provides an explicit example.
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 this tool ('when you want TA AND sentiment AND news for one symbol in a single call') and when to use alternatives ('For indicators only, coin_analysis is faster; for cross-timeframe trend alignment use multi_timeframe_analysis').
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 and no destruction. The description adds that it runs all 9 strategies and that some may contribute zero trades if period too short, which is valuable behavioral context 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?
Description is concise, front-loaded with main purpose, then lists parameters in a clean format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage is strong: lists all strategies, documents parameters, and warns about period limitations. Could mention the output format (leaderboard columns) but not critical given tool's clarity.
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?
All 4 parameters are documented with meaning, defaults, and usage notes (e.g., period recommendation). Schema coverage is 0%, so description fully compensates with clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs all 9 listed strategies and returns a ranked leaderboard, which distinguishes it from siblings like backtest_strategy that likely run a single strategy.
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: recommends period >= '1y' for SMA200 warmup, explains that shorter periods cause zero trades for certain strategies, and gives symbol examples. No explicit when-not to use, but context is 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?
Annotations already indicate readOnlyHint and destructiveHint, so the description adds value by specifying the scope (front-month, full categorized list) and listing the categories. No contradiction with annotations; it supplements them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the core purpose. Every sentence adds value, with no unnecessary words.
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 no parameters, no output schema, and clear annotations, the description fully explains what the tool returns and how to use the output. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description does not need to add parameter semantics, and 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'full categorized list of well-known front-month futures symbols', which is a specific verb+resource. It lists categories, distinguishing it from sibling tools like futures_category_snapshot that provide deeper analysis on individual symbols.
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 suggests using the retrieved symbols with futures_category_snapshot or coin_analysis for deeper analysis, providing actionable guidance. It does not mention when not to use the tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds transparency by detailing the output (trade directions allowed, regime transitions, 30-bar trend histogram) and the underlying classification logic. No contradictions with annotations; all behavioral traits are disclosed adequately.
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, front-loading the purpose and then providing algorithmic details, output summary, and parameter explanations. Every sentence adds value, and the length is appropriate given the absence of schema descriptions. No redundant or empty content.
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 is complete for a read-only tool with three simple parameters. It explains the output (trend, volatility, direction gates, transitions, histogram) without requiring an output schema. However, the exact structure of the returned data (e.g., JSON keys) could be more explicit, but it's sufficient for agent invocation.
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 fully compensates. It explains each parameter: symbol (Binance pair, default BTCUSDT), interval (timeframe, default 4h), and days (history window 1-730, default 180, with warmup constraint). These details add meaning beyond the schema's type and default values.
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 purpose: determining the current market regime (trend up/down/chop) and volatility for a given symbol, using EMA50/EMA200 ratio and ATR% metrics. It distinguishes itself from sibling tools like market_sentiment or scanners by focusing on a specific classification method used in bracket backtests, providing unique value.
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 the tool: to get a top-down regime snapshot for a symbol, especially as a prelude to scanning or backtesting. It does not explicitly state when NOT to use it or list alternatives, but the clear purpose and context imply appropriate usage. The inclusion of default parameters and warmup considerations provides practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context: error handling for invalid expiry, default return of nearest expiry, and listing of available_expiries. This goes beyond annotations, though rate limits or authentication are not mentioned.
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, well-structured description with a brief intro, usage examples, and clear Args/Returns sections. At about 10 lines, every sentence adds value and is front-loaded with purpose and usage.
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 simple 2-parameter tool with no output schema, the description covers purpose, usage, parameters, and return structure (listing fields like underlying_price, call_count, etc.). It does not mention edge cases like empty chains or missing data, but the information provided is sufficient for an AI agent to invoke the tool 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 has 0% description coverage, so the description fully compensates. It explains symbol as a US stock symbol with examples, and expiry as an optional ISO date that must match available_expiries, including the error behavior. The default behavior when omitted is also described.
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 returns the full options chain for a US stock symbol and one expiry, with specific examples like 'show me AAPL puts expiring next Friday'. It differentiates from siblings such as stock_options_unusual_activity by focusing on the standard chain rather than unusual activity.
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?
Explicit usage examples are given, such as when a user asks for an options chain or wants to inspect bid/ask/IV/volume. The description also explains behavior when no expiry is provided (returns nearest expiry). It does not explicitly mention when not to use or list alternative tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. Description adds significant behavioral context: one upstream request even for full 2000 tickers, exchange-scoped lookup, and return structure including a not_found list. No rate limits mentioned, 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?
Description is well-structured with Args and Returns sections, providing necessary information in a compact form. No redundant sentences; every part adds value. Efficient for an AI agent to parse.
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?
Despite no output schema, the description details the return envelope including fields like ticker, symbol, price, change_percent, and not_found list. Covers input format, limits, and behavior. Could mention rate limits or auth requirements, but overall complete for a read-only data fetch 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?
With 0% schema description coverage, the description fully defines the single parameter 'tickers': comma-separated EXCHANGE:SYMBOL list, max 2000, with required exchange prefix. Provides examples and clarifies behavior. Exceeds the schema's minimal definition.
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 'Current price + daily % change for specific stock symbols' and specifies the required ticker format with exchange prefix. It distinguishes itself from sibling tools like top_gainers and yahoo_price by focusing on fetching raw price data for user-specified symbols with a specific input format.
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?
Description implies when to use: to get prices for specific stocks by symbol. It explains the format 'EXCHANGE:SYMBOL' and max 2000 tickers. However, it does not explicitly compare with alternatives like yahoo_price or market_snapshot, but the emphasis on exchange-scoped lookup provides enough context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. The description adds valuable behavioral context: pricing is in local currency, sort is server-side over the whole market, exclude_otc default behavior, compact mode reduces payload. 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 Args and Returns sections, but is somewhat lengthy. It could be trimmed slightly without losing clarity, but overall it is efficient and front-loaded.
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?
Despite no output schema, the description fully describes the return envelope and fields. It covers complex behaviors like server-side sorting and currency handling. For a 6-parameter tool with no required params, this is highly complete.
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 carries full burden. It explains all 6 parameters in detail: country with examples, stock_type values, limit max, exclude_otc meaning, compact mode, sort_by options and their sorting behavior. This exceeds minimal compensation.
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 screens stocks by share type (common/preferred) and by country, explicitly calling itself the 'API twin of TradingView's symbol-search filter'. It distinguishes from siblings by focusing on this specific filtering capability.
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 detailed guidance on each parameter including defaults, valid values, and behavior (e.g., limit max 2000, sort_by options). While it doesn't explicitly compare to alternatives, the context of being a stock screener by share type is clear enough to differentiate from other scanners.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavior: that an empty list means 'no matches today' and explicit error envelope handling, enriching transparency 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?
The description is concise and well-structured, starting with the core purpose, followed by a clear parameter list, and ending with return behavior. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and return envelope behavior. However, it does not specify the fields inside the returned dicts (keys like 'symbol', 'volume', etc.), which would be useful for complete 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 coverage, the description explains all 5 parameters with examples and context (e.g., 'exchange: Exchange name like KUCOIN, BINANCE...'), fully compensating 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 'Detect coins with volume breakout + price breakout,' using specific verb and resource. It distinguishes from sibling tools like 'top_gainers' and 'bollinger_scan' by focusing on volume and price breakout detection.
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 implicitly guides use for detecting volume and price breakouts. However, it lacks explicit when-not-to-use guidance or comparison to alternatives among the many sibling scanners.
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 provide readOnlyHint=true, destructiveHint=false, openWorldHint=true. Description adds value by disclosing return format (list of dicts) and structured error envelope on failure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary, example, and parameter list. Every sentence adds value. No wasted words.
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?
Covers purpose, usage, parameters, return format, and error handling. For a complex tool with 4 optional parameters and no required params, description provides all needed context.
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%, but description fully compensates with detailed arg explanations, enum values for exchange and timeframe, default values, and typical threshold examples. Adds significant 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?
Clearly states it scans for assets with low Bollinger Band Width (squeeze detection) across an exchange. Distinguishes itself from the sibling coin_analysis tool which is for single-symbol Bollinger reads.
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: use for whole exchange scanning, not for single symbol. Gives example and parameter details. Lacks explicit when-not-to-use statements but context is clear.
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 annotations: runs on same Binance data, computes once, checks neighbor profitability, and defines verdicts. 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-structured with a summary followed by an Args list, but is somewhat lengthy; could be slightly more concise.
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?
Covers algorithm, verdicts, and parameters well, but lacks details on return format or output 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 fully compensates by listing all parameters with defaults, constraints, and roles, adding 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?
The description clearly states the tool performs a grid-search over bracket parameters (rr × atr_mult) with a stability verdict, distinguishing it from related tools like bracket_backtest or walk_forward_backtest_strategy.
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 the tool is for parameter optimization and stability checking, but does not explicitly mention when not to use it or provide direct comparisons to 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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context: returns a list ranked by % change with OHLCV data, and the volume_min filter defaults to 10 to exclude illiquid contracts. 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 structured with 'Args' and 'Returns' sections, concise yet thorough. Every sentence provides essential information without redundancy or fluff. Ideal length for an agent to quickly parse.
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 no output schema, the description explains return format (list ranked by % change with OHLCV data). Parameters are fully documented. Annotations cover safety. The tool's role is clear among many siblings. No gaps are evident.
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 carries the burden of explaining parameters. It clearly defines direction (gainers/losers), exchanges (us/global), limit (max results), and volume_min (minimum volume filter). This provides complete semantic meaning beyond the schema's 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 returns 'Futures contracts with the biggest percentage moves today,' specifying verb and resource. The parameters further clarify scope (direction, exchanges, filters). This distinguishes it from sibling tools like top_gainers/top_losers (likely equities) and futures_market_overview (broader overview).
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 parameter guidance (direction, exchanges, volume_min) implying when to use gainers vs losers. It does not explicitly differentiate from the many sibling tools, but the name and description make the use case clear. Few explicit 'when not to use' or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the output structure (bitcoin, dominance, total_market, assessment with label and reasoning) and implying no side effects, fully consistent 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary of what the tool does, followed by usage guidance and a bulleted list of return fields. Every sentence adds value without unnecessary fluff.
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 there is no output schema, the description thoroughly explains the return structure. It covers all needed context for using this tool effectively in crypto analysis, including the assessment categories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description doesn't need to add parameter info; it correctly focuses on output and usage.
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 provides a single-call BTC macro context including price, dominance, total market cap, and risk assessment. It distinguishes itself from sibling tools by being a consolidated macro view, not a per-coin price lookup.
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 'Use this WHENEVER analyzing any cryptocurrency' and explains why it's better than chaining separate calls. It gives clear context for when to invoke 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes simulation details beyond annotations: ATR-bracket exits, intra-bar high/low checks, conservative stop-first fills, per-side fee+slippage. Annotations (readOnlyHint, destructiveHint) are consistent; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: one-line summary, comparison, execution detail, then detailed Args. Slightly verbose but appropriate given complexity. 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?
Covers all parameters and behavioral details. Explains regime filtering, trade log, and execution model. No output schema but description sufficiently informs about return. Complete for a complex backtesting 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 has 0% description coverage; the description fully documents all 15 parameters with explanations, defaults, and usage suggestions (e.g., days window tips). Adds critical meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it backtests scalp/day/swing strategies on Binance 1m-1d klines (long and short). Explicitly distinguishes from sibling backtest_strategy (Yahoo, 1h/1d, long-only).
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 alternative (backtest_strategy) for different use cases. Gives parameter suggestions (e.g., interval-day combos). Lacks explicit 'when not to use' but offers sufficient context for decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, covering safety and openness. Description adds that it's a 'technical readout' returning 'Detailed analysis with all indicators and metrics,' providing context beyond annotations 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?
Description is well-structured with a concise summary, usage guidance, an example, and clearly labeled Args and Returns sections. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters, no output schema. Description covers usage, parameters, and sibling differentiation comprehensively. The Returns section is vague ('detailed analysis with all indicators and metrics'), but the tool is a technical analysis endpoint; completeness is high given the context.
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?
Despite input schema having no parameter descriptions (0% coverage), the description's Args section thoroughly explains each parameter: symbol with examples, exchange with a list and error handling hint, timeframe with interval list. This fully compensates for the schema gap.
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 detailed analysis for a single asset on a specific exchange and timeframe. It explicitly differentiates from siblings like multi_timeframe_analysis and combined_analysis, avoiding confusion.
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?
Description gives explicit instructions on when to use this tool versus alternatives: 'Use multi_timeframe_analysis instead when you need trend alignment... and combined_analysis when you also want news sentiment.' It also affirms this is the canonical tool, no other similar tool exists.
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=true, destructiveHint=false. The description adds that it operates on one symbol and the timeframes involved, which is useful context beyond 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?
Concise at ~120 words, well-structured with paragraphs, bullet points, and a clear example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and alternatives. Lacks description of return format or output behavior, but for a read-only analytical tool with no output schema, the description is largely complete.
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%, but the description provides extensive parameter semantics: explains symbol as 'Bare ticker, no exchange prefix' with numerous examples per exchange type, and lists supported exchanges. This adds significant value.
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 purpose as 'Multi-timeframe alignment analysis (Weekly → Daily → 4H → 1H → 15m)' and explicitly distinguishes it from sibling tools like coin_analysis and combined_analysis by specifying use cases.
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?
Provides explicit guidance: 'Use this for cross-timeframe trend alignment on ONE symbol; for a single-timeframe deep dive use coin_analysis; for TA + sentiment + news use combined_analysis.' Also includes a concrete example and canonical 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?
Discloses that it processes only closed candles, ignores in-progress ones, catches up after downtime, and manages positions with stop-first bracket semantics. Also explains when new entries are taken (signal, regime gate, halt, kill switch). Annotations indicate non-readonly and non-destructive, consistent with description.
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 at 5 sentences, front-loaded with the primary action. Each sentence adds meaningful detail without redundancy.
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 (advancing a paper trader with multiple conditions and state), the description covers behavior, scheduling, safety, and return value sufficiently. No output schema exists but description mentions events and snapshot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline score of 4 applies. The description fully explains behavior without needing to document parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it advances the paper trader one tick against live Binance data, processes closed candles, and manages positions. Distinguishes itself from sibling paper tools like paper_reset and paper_status by its step-specific action.
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 says 'Call this hourly' or run the daemon, and mentions it's safe to call any time. Lacks explicit alternatives but the context and recommendation provide clear usage guidance.
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 declare readOnlyHint=true and destructiveHint=false. The description adds rich behavioral context: it scans soonest expirations, filters illiquid strikes with min_volume, returns top-N sorted by V/OI descending, and includes aggregate call/put volume. It also explains the V/OI ratio >1 as a flag for institutional positioning. 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 a one-line summary, usage guidance, technical details, parameter docs, and return fields. It is front-loaded and informative. Though slightly lengthy, every sentence adds value. Minor improvement could be tightening the parameter explanation.
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?
With 4 parameters and no output schema, the description provides a detailed list of return fields including underlying_price, expiries_scanned, aggregate volumes, and each unusual contract's attributes (strike, side, volume, OI, ratio, IV, etc.). The filtering logic and purpose are fully explained, leaving no gaps in 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?
Schema description coverage is 0%, but the description fully compensates by documenting each parameter: symbol (example symbols), top_n (default 10), min_volume (purpose to prevent noise), expiries (default 4, typical coverage). It adds meaning beyond the schema's type/default fields.
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 returns top strikes by volume/open-interest ratio as an institutional positioning signal. It uses specific verbs like 'scans', 'filters', 'returns' and distinguishes itself from siblings like 'stock_options_chain' which likely provides full chain data. The one-line summary is precise and immediately conveys 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'when the user asks "any unusual options activity on X?" or wants a V/OI screener for a ticker'. It explains the V/OI ratio meaning and when the signal is strong. While it does not explicitly state when not to use it, the context and sibling tools make alternatives 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?
Annotations already indicate readOnlyHint=true and non-destructive. The description adds valuable context: the walk-forward nature validates on unseen data, and some strategies fail due to SMA warmup exceeding typical fold size. However, it does not disclose potential output format or error handling details beyond parameter constraints.
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 and structured: one-line purpose, then formatted Args block. Every sentence adds value without redundancy or fluff. Perfect front-loading of the core function.
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 purpose, parameters, and usage guidelines thoroughly. However, though there is no output schema, the description does not mention return values or what the agent can expect from the response. A brief note on output would make it fully complete for a tool of this complexity.
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 provides detailed args: lists supported strategies, gives examples for symbol, recommends period, explains defaults for capital, commission, slippage, n_splits, train_ratio, and interval. This goes far beyond the schema's minimal property titles.
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 does a 'Walk-forward backtest to detect overfitting — validates strategy on unseen data.' This specific verb+resource combination distinguishes it from siblings like 'backtest_strategy' and 'bracket_backtest' that lack the walk-forward overfitting detection aspect.
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 this tool vs alternatives: notes that 'rsi_pullback and triple_ema not supported here' and recommends 'use run_backtest with period='2y'' for those strategies. Also recommends '2y' period for best results.
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 behavioral context beyond annotations: force-closing positions at segment boundaries, aggregated out-of-sample result, verdict categories, and parameter stability. It does not contradict annotations (readOnlyHint: true, destructiveHint: false).
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 bold summary, followed by process explanation, then parameter list. Every sentence is informative and front-loaded. It is appropriately sized for the complexity.
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 16 parameters and no output schema, the description covers the algorithm, verdicts, parameter stability, and all parameter details. It provides sufficient context for correct invocation, though output format could be more explicit.
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 provides detailed explanations for all 16 parameters, including ranges, defaults, and types (e.g., 'squeeze_breakout | ema_momentum' for strategy, '1m | 3m | ...' for interval). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'True walk-forward optimization' and explains it's a gate before paper trading. It details the process and outcomes, distinguishing it from siblings like bracket_backtest and walk_forward_backtest_strategy.
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 indicates when to use this tool ('gate a strategy must pass before paper trading') but does not explicitly state when not to use or directly reference alternative tools. However, the context implies it is for rigorous validation.
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?
Adds substantial behavioral details beyond annotations: explains session-specific behavior (null post_market during regular session), computed % changes, and data freshness. Annotations already declare readOnlyHint=true and destructiveHint=false, but description enriches with operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then usage guidelines, behavior, and arguments/returns. Every sentence adds value without repetition. Efficiently communicates complex information in a compact form.
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?
Compensates fully for the lack of output schema by detailing the return structure (pre_market, regular, post_market objects with fields) and edge cases (nulls, weekends). Complete enough for an agent to understand and use the tool effectively.
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?
Despite 0% schema description coverage, the description provides clear examples (AAPL, NVDA, TSLA, SPY, ^GSPC) and clarifies that indices are supported. This adds significant meaning beyond the schema's basic type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides real-time pre-market and after-hours prices for US stock symbols, using specific verbs like 'returns' and specifying the resource. It distinguishes itself from sibling tools like stock_prices and yahoo_price by focusing on extended hours.
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 clear scenarios for when to use the tool (earnings reactions, overnight news, after-hours queries) and explains behavior during regular hours and weekends/holidays. However, it does not explicitly state when not to use it or direct users to alternatives like stock_prices for regular hours.
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:

[![tradingview-mcp MCP server](https://glama.ai/mcp/servers/GlynnCarson/tradingview-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GlynnCarson/tradingview-mcp)

Score Badge

Copy to your README.md:

[![tradingview-mcp MCP server](https://glama.ai/mcp/servers/GlynnCarson/tradingview-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GlynnCarson/tradingview-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/GlynnCarson/tradingview-mcp'

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