Gate Info MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral context by clarifying the single-target nature and the role of chain in disambiguation. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two short sentences—yet conveys purpose, scope, and sibling differentiation. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and fully described parameters, the description provides sufficient context to understand tool usage and parameter interplay. The tool's purpose is fully captured.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter. The description adds high-level semantic value (e.g., 'Chain fixes address clashes') but does not significantly extend beyond the schema's detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this tool is for a 'single-target lookup' by ticker, name, or contract, and explicitly distinguishes it from siblings like search_coins (filtered lists) and get_coin_rankings (boards). The verb-resource pair is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when not to use it ('Filtered lists→search_coins. Boards→get_coin_rankings') and provides context for the chain parameter ('Chain fixes address clashes'). This gives clear guidance on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety concerns. The description adds behavioral nuance about when time_range is applicable (only for gainers/losers), which is not fully captured by the schema alone. However, it does not explain other behaviors like pagination or response structure, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three short sentences. It immediately lists the boards and then provides crucial usage notes. No redundant words; every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to explain return values. It covers the main use cases and parameter constraints. However, it could be slightly more explicit about the tool's purpose in relation to sibling tools beyond the two mentioned. Overall, it is adequate for a read-only ranking tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented. The description only reiterates that time_range is for gainers/losers, which is already in the schema's description for time_range. No additional semantic depth is added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it fetches coin rankings for various boards: popular, gainers/losers, twitter_hot, airdrop, new_listing, market_pulse_hot. It also distinguishes itself from siblings by directing single match queries to get_coin_info and filtered list queries to search_coins.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance: it mentions time_range is only for gainers/losers, and explicitly suggests alternative tools for single match ('Single match→get_coin_info') and filtered list ('Filtered list→search_coins'). This helps an agent choose the correct tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying behavior for unknown categories (empty list) and chain filter matching (canonical name/alias, contains match), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first clearly states purpose, and the second provides usage guidance with sibling differentiation. No wasted words, front-loads key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 8 parameters and output schema, the description covers the core purpose and behavior. It does not detail pagination or sort behavior beyond schema, but this is acceptable since the schema is rich. Adequate for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented. The description mentions category, chain, cap, and type filters but does not add significant new meaning beyond what the schema provides. Hence, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a multi-row asset list with filtering by category, chain, cap, and type. It also explicitly differentiates from siblings by indicating when to use get_coin_info (single match) and get_coin_rankings (boards).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear alternatives for specific use cases (single match or boards), helping the agent choose between siblings. However, it does not explicitly state when not to use this tool or provide general usage context beyond differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context that the tool screens for specific risks and that parameters are used in a mutually exclusive manner, which goes beyond annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two sentences and a short phrase. Every sentence adds essential information: purpose, sibling reference, and parameter constraints. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and the input schema is fully described, the description covers the critical aspects: purpose, alternative, and key parameter rule. It feels complete for the agent to understand what the tool does and how to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the XOR relationship between token and address parameters, and hints at the scope parameter's role, which is not evident from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool screens a token for honeypot, tax, and holder risk, which is a specific verb+resource. It distinguishes from the sibling info_onchain_get_token_onchain by pointing to it for on-chain activity stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions an alternative tool for on-chain activity stats, providing guidance on when to use this vs. that. It also states the XOR constraint for token/address, but does not further elaborate on when to use this tool over other compliance tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate safe read operation (readOnlyHint, idempotentHint, destructiveHint). Description adds context of filtered calendar but no additional behavioral details beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, and efficient use of space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given comprehensive schema descriptions and annotations, the description is sufficient for understanding the tool's role. Output schema exists, so return values are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with parameter descriptions. Description does not add any parameter-specific information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it's a filtered release calendar in a date window and distinguishes from siblings get_macro_summary (dashboard) and get_macro_indicator (indicator snapshot/series).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool vs alternatives: 'Zero-arg dashboard→get_macro_summary. Indicator snapshot or series→get_macro_indicator.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context about data scope (latest or series) and exclusions, but does not disclose behavioral details like response format or rate limits. With annotations covering safety, this is adequate but not enriched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines purpose with examples, second excludes events and points to sibling tools. Every word adds value. Front-loaded with verb and resource. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with 100% schema coverage and an output schema, the description is succinct yet covers key aspects: core function, examples, and sibling differentiation. Might be improved by briefly explaining the difference between 'latest' and 'timeseries' modes, but the schema handles that. Overall well-aligned with complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions (e.g., indicator matching rules, country vs country_code precedence). Description only adds high-level context ('latest or series by country/indicator') without enriching beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('get'), resource ('official macro stats'), and scope ('latest or series by country/indicator (CPI, rates, jobs)'). It distinguishes from sibling tools by explicitly mentioning what it is not ('No event feed') and redirecting to calendar and summary tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit alternatives for related but distinct features: 'Calendar→get_economic_calendar' and 'Dashboard→get_macro_summary'. Tells the agent when not to use this tool (no event feed). Lacks explicit prerequisites or conditions for choosing between 'latest' and 'timeseries' modes, but the schema covers mode parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral details beyond a vague 'dashboard'. It does not contradict annotations, but also does not add significant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with zero wasted words. Front-loaded with 'Zero-arg macro dashboard' for immediate clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema (present), the description provides a reasonable overview. It references key content ('key snapshots plus upcoming releases') and cross-references sibling tools. Could be more specific about what 'key snapshots' entails, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (zero-arg). Schema coverage is 100% (no params). The description mentions 'Zero-arg' upfront, satisfying the baseline expectation. No additional parameter explanation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it's a 'Zero-arg macro dashboard' providing 'key snapshots plus upcoming releases'. It distinguishes itself from sibling tools by explicitly directing to `get_economic_calendar` for filtered calendar lists and `get_macro_indicator` for indicator snapshots/series.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when not to use this tool and suggests alternatives: 'Filtered calendar list→get_economic_calendar. Indicator snapshot or series→get_macro_indicator.' This provides clear usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds minor context about fine intervals (1m, 5s), but does not disclose other behavioral traits like rate limits or pagination behavior. It is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose. It is concise and efficient, though it could be slightly more structured (e.g., start with 'Get kline data...'). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters (2 required) and an output schema, the description is minimal. While the schema descriptions are complete, the tool would benefit from a summary of common use cases or parameter interaction. However, the output schema exists, so return values are not needed. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant new meaning beyond what the schema provides; it mentions 'fine intervals' but the schema already lists examples. No improvement over schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets 'candles' (kline/OHLCV) for exchange pairs or contracts, and distinguishes from the sibling tool 'markettrend_get_kline' which is for trend-index or indicator bundle. Verb 'get' and resource 'kline' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions a prerequisite ('needs Gate base URL') and provides an alternative tool ('markettrend_get_kline') for when trend-index or indicator bundle is needed, making when-to-use vs when-not-to-use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds minimal behavioral context (needs base URL, data source from Gate), which does not contradict annotations but adds little beyond what is implied by the name and schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise—three short sentences, front-loaded with purpose and key qualifier. Every sentence adds value: purpose, configuration note, and sibling differentiation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a well-described schema (100% coverage) and an output schema, the description is complete enough. It provides core purpose, configuration hint, and cross-references to related tools. It could mention supported market types or the depth parameter behavior, but those are covered in the input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description does not add any parameter-specific information beyond what the schema already provides. For example, the description does not clarify depth limits or market_type options beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves order book depth (bids and asks ladder) from Gate exchange. It uses specific verbs and resources and differentiates from siblings by naming alternatives for related data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides two alternatives: for trade tape use get_recent_trades, for trend-index bars use markettrend_get_kline. This helps the agent choose the correct tool, though it could be clearer about when this tool is the best choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the 'needs base URL' constraint, which is helpful, but otherwise adds no further behavioral context (e.g., pagination, result chronology). It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded: two sentences plus two concise pointers to alternatives. It wastes no words but the 'Needs base URL.' sentence feels slightly abrupt. Overall efficient for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and parameters are well-documented, the description minimally completes the picture by naming the exchange and providing usage context. However, it lacks details about output structure, ordering, or time bounds, which would be helpful for a trades endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 5 parameters have descriptions in the schema (100% coverage), so the description carries no additional parameter meaning. Baseline score of 3 is appropriate since the schema already explains the parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves recent trade prints (tape) from Gate exchange. It explicitly distinguishes from siblings by pointing to get_orderbook for depth ladder and markettrend_get_kline for trend-index bars, leaving no ambiguity about the tool's specific purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit alternative tool names for related data (orderbook, kline) and mentions a prerequisite ('needs base URL'). However, it does not elaborate on when not to use this tool beyond the alternatives, nor does it cover rate limits or auth requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds key behavioral context: batch up to 20 symbols, partial misses accepted (missing symbols yield empty rows, batch still succeeds). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: main function with constraint, then two sentences for sibling differentiation. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 params, 1 required, output schema exists), the description covers purpose, usage alternatives, and partial-miss tolerance. It does not explain output format (covered by output schema) or default values (covered by schema). Overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already described. The tool description does not add additional parameter-level details beyond schema, but it provides context about batch behavior related to symbols. Baseline score for high coverage is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Batch quotes up to 20 symbols; partial misses OK' with a specific verb and resource. It further distinguishes from siblings by listing alternatives: one symbol, deep trend, breadth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool versus alternatives (single symbol→get_market_snapshot, deep trend→markettrend_get_kline, breadth→get_market_overview). While it doesn't provide explicit 'when not to use', the alternatives cover that implicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds specific behavioral traits: CME fields are often null due to data_status cme_source_not_procured, and non-selected channels lead to null fields. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences that front-load purpose, then parameter behavior, then a behavioral note. No wasted words, though could be more structured with bullet points for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, the description gives high-level return structure (assets[].latest and series[]). It mentions data source (OpenSearch) and common null scenarios. It lacks explanation of 'latest' vs 'series', but output schema likely covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context: clarifies that 'all' returns both groups for asset, and that channel nulls non-selected fields. Also notes that CME nulls are common. This adds meaning beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides BTC/ETH institutional ETF/CME/CFTC daily metrics from OpenSearch. It distinguishes from siblings like get_market_overview and get_market_snapshot by specifying 'institutional' focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for institutional metrics but doesn't mention when to prefer it over other market snapshot tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint true and idempotentHint true; description adds that it returns a dashboard of market metrics and that it does not include stablecoin ranking, providing useful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each meaningful: first defines the tool's output, second provides alternative usage paths. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, thorough annotations, and an output schema, the description is fully complete. It covers what the tool does, what it doesn't do, and how to choose alternatives.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline is 4. Description does not need to add parameter details, and it correctly omits them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states it provides a 'broad market dashboard' with 'cap, volume, dominance, and sentiment' and clarifies what it excludes ('no stablecoin ranking'), making the purpose highly specific and distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when not to use: by stating 'no stablecoin ranking' and providing direct alternatives for stablecoin-only, single asset, and many symbols scenarios, giving clear guidance on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'price, kline clip, project' but does not elaborate on response format or quirks beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, using shorthand and arrows to point to siblings. Every sentence is purposeful and front-loaded with the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With full schema coverage, annotations, and an output schema (indicated), and the tool's focused scope, the description is complete enough for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description does not add extra meaning to parameters; it only states tool purpose without parameter-level details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns price, kline clip, and project info for a single symbol, and explicitly distinguishes it from siblings like trend, gate, many, and breadth tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes explicit mappings to alternatives: Trend→markettrend_get_kline, Gate→marketdetail_get_kline, Many→batch_market_snapshot, Breadth→get_market_overview, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds a hint about returning historical indicator columns, which aligns with annotations. No contradiction, but no additional behavioral details beyond the schema and annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (one line) but is cryptic and under-specified. It sacrifices clarity for brevity, failing to properly articulate the tool's function. Genuine conciseness would retain meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain what the tool returns (e.g., time series data with indicator values per timestamp). For a tool with 6 parameters and a complex response, the description is too minimal to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all parameters adequately. The description does not add extra meaning or context beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description mentions 'Historical indicator columns (RSI, MACD, MAs)' but does not explicitly state the tool retrieves historical values of indicators. It contrasts with get_kline and get_technical_analysis, but the main purpose is vague; the verb is implied ('get' from name) but not clarified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear alternatives: 'OHLCV→get_kline. Synthesis→get_technical_analysis.' This tells the agent when not to use this tool, providing helpful differentiation from siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds 'trend-index' context but no additional behavioral details (e.g., rate limits, data freshness). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three efficient sentences, front-loaded with main purpose, no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema and comprehensive annotations, description is sufficient to guide usage and distinguish from siblings, though could mention default timeframe or result structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; description adds minimal value beyond schema, only briefly mentioning 'optional indicator bundle' which relates to with_indicators parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb+resource ('Trend-index OHLCV') and differentiates from siblings by referencing marketdetail_get_kline, get_indicator_history, and get_technical_analysis for specific use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use alternatives: fine intervals → marketdetail_get_kline, columns → get_indicator_history, signals → get_technical_analysis, effectively guiding agent selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the analysis is based solely on OHLCV chart data and across multiple timeframes, which is useful context but does not disclose potential computational cost or response time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff, front-loading the core purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values are not needed in description. However, for a relatively complex multi-timeframe analysis tool, the description could clarify whether the output is a single verdict or per timeframe, and better differentiate from sibling tools. The current description is adequate but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all parameters. The description adds minimal additional meaning beyond the schema, such as implying the 'period' parameter relates to timeframes. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a multi-timeframe bull/bear/neutral analysis based on OHLCV data, distinguishing it from sibling tools like get_kline and get_indicator_history which provide raw data. However, it could be more explicit about the exact output format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs. alternatives. It only mentions that OHLCV data comes from get_kline and raw columns from get_indicator_history, implying those are for raw data, but does not state usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds valuable context: chain aliases, error types, Solana-specific fields, and behavior of empty sections being [] or null. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and includes output summary, chain aliases, errors, and a sibling pointer in a single paragraph. While concise, it lacks structure and readability, making it harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 params, output schema present), the description covers main outputs, error types, and parameter behaviors. It's sufficiently complete for agent usage, though slightly unstructured.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 6 parameters with descriptions (100% coverage). Description adds significant extra meaning: chain aliases, scope mapping (detailed maps to full), min_value_usd dropping unparseable values, upstream_raw_mode effects, and include_upstream_raw forcing full mode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a wallet profile including asset summary, token balances (USD descending), multi-chain balances, and labels/risk. It distinguishes from sibling tool info_onchain_get_address_transactions by directing transfers there.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for wallet profiling but does not explicitly explain when to use this vs other sibling tools. Only mentions that transfers should use get_address_transactions, lacking broader guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses pagination, BTC-specific fields (inputs/outputs/tx_status), and partial_upstream_response behavior for unparseable lists. This adds useful context for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (three sentences) and front-loaded with the key action. However, the dense jargon ('partial_upstream_response', 'Chain aliases') slightly reduces clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters and an output schema, the description is minimal. It explains pagination and partial failures but lacks an overview of output structure, how pagination works (e.g., cursor/page tokens), or deeper relationships with other tools beyond a brief mention.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to any parameter; it only refers to chain aliases without parameter-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Paginated transfers' combined with the tool name makes clear that this tool retrieves a paginated list of transactions for an address. It distinguishes itself from sibling info_onchain_get_address_info by noting 'Profile→get_address_info', implying different use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides only a hint about chain aliases being same as get_address_info and a profile reference to get_address_info, but no explicit guidance on when to use this tool versus alternatives like get_transaction or get_token_onchain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no behavioral context beyond these, which is acceptable but not enhancing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is very short and somewhat cryptic. While concise, the structure (using arrows and references) makes it less clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and an output schema, the description is minimal. It does not explain how scopes affect results or provide high-level context, leaving gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds no new semantic information beyond the schema; baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description mentions token scope and references siblings, but does not clearly state the tool's primary function. It is somewhat vague and requires inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus siblings like get_address_transactions or get_transaction. The description implies token-related queries but lacks clarity on context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent nature. The description adds useful context about fields being sparse if upstream data is thin, which is beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, perfectly concise, front-loaded with the main purpose. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description doesn't need to detail return values. It mentions sparse fields and cross-reference, but could note that using raw mode yields large payloads.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; all parameters have descriptions. The tool description does not add additional parameter meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a single transaction by hash, distinguishing it from siblings like get_address_transactions (multiple txs) and get_token_onchain (token data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a cross-reference to get_token_onchain for token view, but lacks explicit guidance on when to use this tool versus other on-chain tools like get_address_info or get_address_transactions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered. The description adds no additional behavioral context (e.g., response format, error behavior). With annotations present, a score of 3 is appropriate as it does not contradict and provides minimal extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description has two sentences, but the second is a run-on that is confusing and not concise. It mixes a cross-sector dashboard note with a redirection to another tool, wasting words without contributing clear value. Could be rewritten more clearly and briefly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and parameter descriptions, the tool's description fails to fully explain its two modes (ranking vs. breakdown) and references an external tool confusingly. Given 4 optional parameters, more context is needed for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all 4 parameters described. The description itself does not add new parameter details; it merely echoes the parameter hint about 'omit for ranked list' which is already in the schema. Baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool provides 'Bridge ranking or one-bridge chain breakdown' which gives a specific verb and resource but adds confusion with 'Cross-sector dashboard across DeFi, spot, perp, stablecoin, or bridge→get_defi_overview', blurring the purpose and linking to another tool. It distinguishes from siblings but not clearly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only hints at usage via 'bridge→get_defi_overview', suggesting a navigation path but not explicitly stating when to use this tool versus alternatives like get_defi_overview. No clear guidance on prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe, non-destructive behavior. The description adds context about data coming from 'warehouse indices' but does not disclose additional behavioral traits like rate limits or data freshness. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, compact and front-loaded with key information. The second sentence 'Gate native ladder→get_orderbook' is slightly cryptic and could be integrated into the first sentence for clarity, but overall no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich output schema and full parameter descriptions, the description is adequate but does not explain how to use parameters like limit, data_scope, or exchange in combination. For a tool with 5 parameters, slightly more guidance on usage patterns would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents each parameter. The description does not add significant meaning beyond what the schema provides; it only mentions '±1% order-book depth' which is not directly tied to any parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as fetching CEX order-book depth at ±1% range for spot/perp, used for BTC/ETH liquidity benchmarking. It distinguishes from siblings by specifying 'competitor CEX' and referencing order-book depth, which is not covered by other platform metric tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for benchmarking BTC/ETH liquidity and mentions 'Gate native ladder→get_orderbook' as a potential alternative. However, it does not explicitly state when to use this tool vs. the general get_orderbook sibling, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description goes far beyond: specifies granularity constraints (day only for l2), whitelist behavior for btc_l2, error states like unsupported_granularity and not_in_scope, and data sources. Adds rich context needed for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is information-dense with no fluff, but lacks structured formatting (e.g., bullets) and the main point is front-loaded. Each sentence serves a purpose given the complexity, so it's efficient without being overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (3 metric groups, 8 parameters, output schema exists), the description is thoroughly complete. It covers all groups with exact metrics, data sources, constraints, whitelist boundaries, error cases, and granularity restrictions. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The description adds value by contextualizing parameters: e.g., for metric_group it lists exact return fields per group, for chain it notes defaults and supported values. This augments the schema descriptions meaningfully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Chain-level activity metrics by metric_group' and enumerates three distinct groups (staking, l2, btc_l2) with specific metrics. This distinguishes it from sibling tools like bridge_metrics or defi_overview by naming unique data sources and return fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the name and description imply it's for chain activity data, it doesn't direct agents away from sibling tools or specify exclusive contexts. The sibling list exists but the description doesn't leverage it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate safe, idempotent, read-only behavior. The description adds that unknown category values are 'passed through' and empty matches yield no data, which is useful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences contain all necessary information without extraneous words. Every part is purposeful and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage boundaries, and parameter behavior adequately. With an output schema present, the agent can understand return structure. However, it could specify what metrics the dashboard includes, but it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already fully describes the category parameter with accepted values and behavior for unknown inputs. The description adds no additional meaning, consistent with the baseline for 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a 'cross-sector dashboard' for DeFi categories, distinguishing it from specific tools like get_bridge_metrics and get_platform_info. The verb 'dashboard' indicates an overview aggregation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when not to use this tool: 'One bridge ranking or chain detail→get_bridge_metrics. One protocol→get_platform_info.' This tells the agent when to choose alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds behavioral context beyond annotations: explains conditional returns based on scope and flags (flows.series[], events[]). Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so description complements them well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-loaded with core purpose. Every sentence adds new information. Efficient and no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main usage scenarios and output types. Mentions defaults for dates. Output schema exists so return details are handled. Could mention exchange mapping but schema already does. Mostly complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining conditional parameter interactions (e.g., scope=full required for include_flows/events, history_window only effective with include_history=true). Does not repeat schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides exchange reserve snapshots by venue and asset, and distinguishes from sibling tools like get_platform_history by name. Specific verb 'snapshots' and resource 'exchange reserves'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to use different scopes and parameters (scope=full for PoR, include_flows for flows, include_events for events). Points to sibling 'get_platform_history' for TVL history. Lacks explicit when-not-to-use or comparison to other sibling tools like get_cex_orderbook_depth.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds that the tool returns 'density by symbol and price buckets', which gives some output structure context. However, it does not disclose data freshness, caching, or any additional behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence of 8 words that efficiently conveys the tool's output. It is well-structured and front-loaded, though it could briefly mention the data source or update frequency without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and thorough annotations, the description is minimally complete. It states the core output (liquidation density by symbol and price buckets) but lacks context such as data source, update frequency, or typical use cases. Still, it covers the essential purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter already described clearly (e.g., 'Price range or bucket spec' for range). The tool description does not add any additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns 'liquidation density' grouped by 'symbol' and 'price buckets', which is a specific verb+resource. The name 'liquidation_heatmap' further reinforces this, and it is distinct from sibling tools like 'get_bridge_metrics' or 'get_cex_orderbook_depth'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus siblings such as other platform metrics tools. There is no mention of context, prerequisites, or alternatives, leaving the agent to infer usage solely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds no additional behavioral context beyond the data it returns. It is consistent but does not go beyond structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose clearly, second lists alternatives and special case. No redundant information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present and 100% schema coverage, the description is sufficient for an agent to understand the tool's purpose, usage, and parameter behavior. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description does not add significant meaning beyond what the schema already provides for parameters. The mention of exchange_slug and platform_name is helpful but baseline is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns daily TVL, volume, and fees time series for one named protocol. Distinguishes from sibling tools like get_platform_info and search_platforms by explicitly noting their use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (one named protocol) and when-not-to (use get_platform_info for profile, search_platforms for list). Also covers special case for CEX perps history with exchange_slug or platform_name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: 'One-shot profile' (idempotent), scope=full adds competition_metrics, and detail on include_oi_symbol_detail. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences packed with information, no filler. Front-loaded with main purpose, then details on options and alternatives. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, output schema exists), the description covers all essentials: purpose, scope options, parameter interactions, and alternatives. Output schema exists, so no need to describe return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds meaning by clarifying scope values ('basic (default)|with_chain_breakdown|full'), explaining include_oi_symbol_detail only works with 'scope=full', and specifying oi_symbol_limit range (1-100, default 20). This goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'One-shot protocol profile by name and scope,' clearly stating the verb (get profile) and resource (protocol/platform). It distinguishes from siblings by mentioning 'Ranked multi-protocol list→search_platforms' and 'Daily time series→get_platform_history.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when-to-use and alternatives: 'Ranked multi-protocol list→search_platforms. Daily time series→get_platform_history.' Also explains scope options and parameter behavior, guiding appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by explaining what data is returned for different parameter combinations (e.g., sections=issuance_flow vs usage_structure), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded: it states the purpose first, then explains sections, then gives alternatives. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 optional parameters and an output schema, the description adequately covers the main functionality, including parameter combinations and data sources (CryptoQuant). It also directs to related tools for broader contexts, making it complete for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter has a description. However, the tool description adds meaning by explaining how parameters interact (e.g., 'scope=full with sections=issuance_flow returns issuance_flows[]'). This combination logic is not present in individual parameter descriptions, enhancing semantic clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides 'Stablecoin-only ranking or per-symbol chain breakdown', which is a specific verb+resource. It also distinguishes from siblings by referencing get_market_overview and get_defi_overview as alternatives for broader dashboards or cross-sector rollups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool vs alternatives: 'Broad market dashboard→get_market_overview. Cross-sector rollup→get_defi_overview.' It also explains the conditions for using scope=full with sections, providing clear context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and repeatable. The description adds that 'scope=full' includes additional fields, which is behavioral 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at three sentences. The first sentence states the purpose, the second clarifies an important parameter, and the third directs to sibling tools. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (8 parameters, none required, full schema coverage, and an output schema), the description sufficiently covers the core functionality and key parameter nuances. The output schema handles return values, so no need for further detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already documented. The description adds value by explaining the effect of 'scope=full' (adding specific fields) and the default behavior of 'min_tvl_usd' (default 100000, 0 for no floor). This enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Lending and LP pools by APY or TVL', identifying the resource (yield pools) and action (get). It also distinguishes from siblings by mentioning related tools for different queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use this tool (getting yield pool data) and directs to alternative tools for platform profile and TVL history, helping avoid misuse. It lacks explicit 'when not to use' but the alternatives provide good guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavior beyond stating it is a ranked list, which is already implied by the name and schema. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The first sentence delivers the core purpose, the second links to related tools. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a complete picture for a read-only list tool: it explains what it returns (ranked list), how to filter/sort (implied), and when to use it vs siblings. Output schema exists, so return values need not be explained. Missing minor details like default sort order or limits, but those are in the schema. Good enough for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with all 5 parameters documented. The description adds only generic 'filter and sort' without enhancing meaning beyond the schema. Baseline of 3 is appropriate as the description does not add significant value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it returns a 'Ranked multi-protocol list with filter and sort', clearly indicating the resource (platforms) and action (search/list). It also references sibling tools get_platform_info and get_platform_history, distinguishing this tool as a list endpoint versus single-profile or history endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool vs alternatives: 'One-shot profile→get_platform_info' and 'One named protocol daily series→get_platform_history'. This provides clear context for when to choose this tool over related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.