Gate Info MCP

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, but the description adds 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This goes beyond the annotations by specifying data type and the absence of trading/auth features, fully aligning and enriching the behavioral profile.

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?

Single sentence with zero filler. Front-loads the core purpose, then packs routing and safety disclaimers in clean, scannable clauses. Every phrase 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?

For a read-only lookup tool with a full output schema and comprehensive annotations, the description covers purpose, sibling routing, edge-case hint (chain), and behavioral boundaries. Nothing essential for correct invocation is missing.

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 meaningful insight by explaining that 'Chain fixes address clashes', which clarifies the chain parameter's purpose beyond the schema note. It also implies query flexibility ('ticker, name, or contract'), though most parameter details are left to the well-documented schema. This is a modest but real increment.

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 'Single-target lookup: ticker, name, or contract→rows' – a specific verb, resource, and input types. It also distinguishes itself from siblings by naming search_coins for filtered lists and get_coin_rankings for boards, leaving no ambiguity about scope.

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 routing: 'Filtered lists→search_coins. Boards→get_coin_rankings.' Also clarifies the chain parameter's role for address disambiguation and notes what is not included (no account access, no orders/funds), giving clear when-to-use and 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.

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice,' which reinforces safety and purpose beyond what annotations provide. It doesn't contradict annotations, and the added context is useful for the agent's risk assessment.

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 compact, front-loading the core function (boards) and then addressing critical usage and safety points in a few short sentences. Every sentence adds value, with no extraneous content.

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 (6 parameters, output schema present) and rich annotations, the description covers the essential aspects: board enumeration, time_range constraint, alternative tool routing, and safety disclaimers. The output schema handles return-value details, so nothing critical is missing for correct 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 covers 100% of parameters with detailed descriptions (e.g., limit, time_range, ranking_type). The description adds minimal new parameter information beyond re-stating the time_range constraint for gainers/losers, which is already in the schema. Thus it meets the baseline for full schema coverage without significantly enhancing semantics.

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 coin rankings across named boards (popular, gainers/losers, etc.) and explicitly distinguishes it from get_coin_info and search_coins, which are sibling tools. The verb 'get' is implied by the title and the description's focus on board selection makes the purpose unambiguous.

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

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

Explicitly tells the agent when to use alternatives: 'Single match→get_coin_info. Filtered list→search_coins.' It also specifies that time_range only applies to gainers/losers, providing clear usage constraints without ambiguity.

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 the annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds valuable behavioral context: 'Read-only public research data' clarifies the data scope, and 'No account access, no order placement or fund transfers' explicitly discloses what the tool does not do, preventing misconceptions about capabilities not implied by annotations alone.

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 compact and front-loaded: the core purpose is stated in the first sentence, followed by routing and safety notes. Every sentence adds value—no fluff. It effectively balances brevity with clarity, making it easy for an agent to quickly parse.

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 explain return values. It covers the tool's core purpose, routing to siblings, behavioral aspects, and exclusions. Given the tool's moderate complexity (8 optional parameters) and rich annotations, the description provides all necessary context for correct invocation.

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 all 8 parameters have detailed descriptions in the schema. The description only mentions 'category, chain, cap, type' which maps to some parameters but adds no extra semantics beyond what the schema already provides. Baseline of 3 is appropriate since the schema does the heavy lifting.

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's function: 'Multi-row asset list by category, chain, cap, type.' It uses a specific verb (list/search) and resource (assets) with filters. It also explicitly differentiates from siblings by naming get_coin_info for single clear matches and get_coin_rankings for boards, making it immediately distinguishable.

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 direct routing guidance: 'One clear match→get_coin_info. Boards→get_coin_rankings.' This tells the agent when to use this tool versus alternatives. It also adds usage context ('Read-only public research data') and exclusions ('No account access, no order placement or fund transfers'), making the tool's appropriate use explicit.

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 meaningful context beyond those: it's a heuristic, not a security guarantee, no account access, no fund movement, and reiterates 'not investment advice'. This clarifies the operational boundaries beyond the structured hints, 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?

Three sentences deliver purpose, disclaimers, routing, and parameter logic without excessive verbosity. The key purpose is front-loaded, and each sentence earns its place. Slightly run-on with multiple clauses, but still reads cleanly and is appropriately sized 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?

With an output schema present and 100% parameter coverage, the description doesn't need to describe return values. It covers purpose, limitations, routing, parameter logic (xor), and safety disclaimers. The only minor gap is not explicitly stating prerequisites (e.g., need chain plus either token or address), but that's implied by the xor note and required chain.

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 baseline is 3. The description adds genuine value by explaining the 'Token xor address with chain' relationship, which is not fully spelled out in individual property descriptions. Also notes that 'scope' is in the schema (redundant but harmless). This goes slightly beyond the schema's documentation.

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?

States a specific verb/resource (checks token security) and gives concrete examples of what it surfaces (tax/holder-risk signals). Explicitly routes on-chain activity stats to a sibling (get_token_onchain), clearly distinguishing its scope from that tool. The purpose is unambiguous and distinct from all 30+ 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?

Provides a direct routing rule ('On-chain activity stats→get_token_onchain') which tells the agent when to pick the alternative. Implies usage context through 'public heuristic', 'read-only public research data', and explicit exclusions ('no order placement or fund transfers'). Doesn't state a formal 'when to use this' sentence, but the intent and exclusions are clear enough.

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 provide readOnlyHint and idempotentHint, and the description adds 'Read-only public research data. No account access, no order placement or fund transfers.' This provides additional safety context beyond the annotations and is consistent with 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 four short sentences, each serving a distinct purpose: core purpose, routing, safety, and disclaimer. It is front-loaded with the main purpose and wastes no 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 full schema descriptions, annotations, and an output schema, the description covers all necessary aspects: what it does, when to use it, and safety constraints. The routing logic addresses key alternatives among siblings, making it sufficient for correct invocation.

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 descriptions cover 100% of the parameters with details like defaults and sorting. The tool description does not mention parameters at all, so it adds no additional meaning beyond the schema. The baseline 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?

The description opens with 'Filtered release calendar in a date window', clearly identifying the resource and the action. It explicitly contrasts with get_macro_summary and get_macro_indicator, making the purpose and differentiation unmistakable.

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?

It provides explicit routing logic: 'Zero-arg dashboard→get_macro_summary. Indicator snapshot or series→get_macro_indicator.' This tells the agent exactly when to choose this tool over those siblings, and also states read-only and no account access for safe 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 already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful context beyond these: 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This clarifies the scope of operations and the absence of trading actions, which is not fully captured by generic annotations. 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?

The description is compact and information-dense, leading with the core purpose, then exclusions, alternatives, and safety disclaimers. Every sentence adds value, and it avoids fluff. The structure front-loads the purpose and quickly guides the agent to decide whether the tool is appropriate.

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 9 parameters but only one required, an output schema, and rich annotations, the description covers the essential context: what it returns (macro stats), the mode options, the no-event-feed caveat, and the non-investment-advice disclaimer. It lacks explicit mention of parameter aliases, but the schema covers those. Overall, it is complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so all 9 parameters are documented in the schema. The description itself does not add new parameter details; it mentions indicator examples (CPI, rates, jobs) and mode ('latest or series'), which slightly reinforces the existing mode and indicator descriptions, but does not go 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?

Description states a specific verb and resource: 'Official macro stats: latest or series by country/indicator (CPI, rates, jobs).' It enumerates the kinds of indicators (CPI, rates, jobs) and explicitly distinguishes from siblings by noting 'No event feed' and naming the alternatives (Calendar→get_economic_calendar, Dashboard→get_macro_summary). This clearly differentiates the tool from its 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?

The description provides clear context: it is for macro stats, read-only research data, and not the event feed. It explicitly points to get_economic_calendar for events and get_macro_summary for dashboards, giving alternative tools. However, it does not explicitly state when to prefer this over get_macro_summary beyond the dashboard reference, so it lacks a full when/when-not directive but is close.

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 description's 'Read-only public research data' aligns with those. It adds valuable extras: 'No account access, no order placement or fund transfers, not investment advice'—context beyond the annotations that clarifies limitations. These are non-repetitive and useful for an 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 compact yet information-dense: it opens with the singular purpose, then provides routing alternatives, then safety/usage constraints. Each sentence adds distinct value with 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?

For a zero-argument tool with an output schema defined, the description covers all the essentials: purpose, use-case segmentation, security and compliance caveats. Nothing an agent needs to decide whether to call it (or not) is missing.

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?

The tool has zero parameters, so the baseline is 4. The description reinforces 'Zero-arg' at the start, but since there are no parameters, there is nothing to clarify beyond confirming the tool takes no input.

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 'Zero-arg macro dashboard: key snapshots plus upcoming releases,' stating a specific verb-resource with clear scope. It explicitly distinguishes itself from sibling tools by naming get_economic_calendar and get_macro_indicator as alternatives 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?

It gives explicit when-to-use directions: 'Filtered calendar list→get_economic_calendar. Indicator snapshot or series→get_macro_indicator.' It also clarifies that this tool is for the general dashboard, not those detailed queries. This is direct, actionable routing advice.

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, covering safety. The description adds value by specifying a prerequisite ('needs Gate base URL') and reinforcing that it is read-only public research data with no trading capabilities. It adds 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.

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

Three sentences, all informative: main purpose, alternative tool, and safety/usage constraints. No filler, and the most important information is front-loaded. 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?

With an output schema present and 100% parameter coverage, the description covers the core essentials: what it does, when to use it, prerequisites, and safety. Nothing critical is missing for an agent to decide and execute a call, though it doesn't mention rate limits or custom return handling, which are minor given the structured 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%, so the schema fully documents all parameters. The description's mention of 'fine intervals such as 1m or 5s' duplicates the schema's timeframe examples and doesn't add new meaning. It does not compensate for any gaps because none exist, but it also doesn't add extra value 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 a specific verb-resource: 'Exchange pair or contract candles', and specifies fine intervals (1m, 5s). It explicitly differentiates from the sibling tool: 'Trend-index OHLCV or indicator bundle→markettrend_get_kline', so an agent knows exactly what this tool returns and how it differs from similar 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?

It gives explicit when-to-use and when-not-to-use guidance: 'Trend-index OHLCV or indicator bundle→markettrend_get_kline' directs to an alternative for different data needs. It also states non-usage: 'No account access, no order placement or fund transfers', clarifying it is for public research only.

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 value beyond these by noting 'needs base URL' (a practical requirement) and reinforcing safety with 'No account access, no order placement or fund transfers'. It also disclaims investment advice. 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?

The description is concise, front-loading the purpose, then alternatives, then disclaimers. It is slightly longer than strictly necessary due to safety disclaimers, but each sentence earns its place. It avoids redundancy with the schema.

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 5-parameter tool with a full output schema and comprehensive annotations, the description covers the core purpose, usage routing, a key prerequisite (base URL), and safety profile. It does not describe return values, but that is handled by the output schema. Remaining gaps are minor.

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 fully documents all 5 parameters. The description does not add per-parameter details beyond mentioning the base URL requirement, which is not a parameter. Per the rubric, a baseline of 3 is appropriate when the schema carries the semantic load.

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 the tool retrieves 'Order book depth: bids/asks ladder from Gate', naming the specific resource (Gate order book) and the verb (get depth). It distinguishes from siblings by referencing trade tape (get_recent_trades) and trend-index bars (markettrend_get_kline), making its unique purpose clear.

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?

It provides explicit guidance on when to use this tool versus alternatives: 'Trade tape→get_recent_trades' and 'Trend-index bars→markettrend_get_kline'. It also mentions the prerequisite 'needs base URL', giving concrete context for invocation. This is direct and actionable.

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, covering the safety profile. The description adds context that this is public research data with no account access or fund transfers, which is slightly beyond annotations but not substantial. It does not contradict annotations, and the extra context is useful though minimal.

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 four sentences, front-loaded with the main purpose, immediately followed by sibling routing, and then security notes. It is concise with zero filler, precisely earning its length.

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 high schema coverage (100%) and the presence of an output schema, the description need not explain return values. It covers purpose, usage routing, and safety. The only vague element is 'needs base URL,' which is an ambiguous prerequisite not tied to any parameter, but overall the description is sufficiently complete for an 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.

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

Schema coverage is 100%, so all parameters are already explained in the schema. The description does not add parameter-specific guidance beyond mentioning a base URL, which is not clearly tied to a parameter. Since the schema carries the burden effectively, the baseline 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 the tool fetches recent trade prints (tapes) from Gate, which is a specific verb+resource. It explicitly differentiates from siblings by naming get_orderbook for depth ladders and markettrend_get_kline for trend-index bars, so an agent can immediately identify its unique 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 routing instructions: 'Depth ladder→get_orderbook' and 'Trend-index bars→markettrend_get_kline.' This tells the agent when to use this tool versus alternatives. It also adds a prerequisite ('needs base URL') and clarifies it is for public research only.

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 (readOnlyHint, idempotentHint), the description discloses meaningful limitations: 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' It also notes partial misses are OK, which is critical behavioral context for batch calls. 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?

The description is compact and front-loaded with the core purpose, followed by targeted routing guidance and necessary safety disclaimers. Every clause earns its place with no filler.

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 moderate complexity (5 params, 1 required), the presence of an output schema, and reactive annotations, the description fully equips an agent with purpose, usage criteria, alternative routing, and behavioral constraints. Nothing essential is missing.

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 per-parameter descriptions, so the schema already documents all parameters. The description adds only the max-20-symbol limit (already in the schema) and partial-miss behavior, but doesn't explain each parameter beyond the schema. The baseline of 3 is appropriate since the description adds no significant semantic 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 clearly states the tool's purpose: 'Batch quotes up to 20 symbols' with partial-miss tolerance. It explicitly names sibling tools and the conditions under which to use them instead, making it unmistakably distinct from get_market_snapshot, markettrend_get_kline, and get_market_overview.

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 direct routing guidance: 'One symbol→get_market_snapshot. Deep trend→markettrend_get_kline. Breadth→get_market_overview.' This tells an agent exactly when to choose this batch tool versus the alternatives, leaving no ambiguity.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: it explains that channel selection 'nulls non-selected fields' and that CME data is often null with the status 'cme_source_not_procured'. It also reiterates the read-only/public nature and adds that it is not investment advice. These behaviors go beyond the annotations and inform the agent about data quality and side-effect‑free 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?

The description is roughly 70 words and front-loaded: it states the core purpose first, then parameter guidance, then key data-quality notes, then safety/scope. There is no fluff; every sentence introduces a distinct fact (purpose, parameter semantics, null behavior, return shape, read-only nature). The structure is efficient and scannable.

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 5 optional parameters, full schema coverage, an output schema (present per context), and annotations covering safety, the description covers everything an agent needs: it explains parameter semantics, return structure, and data-quality quirks (CME nulls). It even clarifies that this is public research data and not investment advice, preventing misuse. Nothing critical is missing.

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?

The schema already documents all five parameters and their defaults (coverage 100%), so the baseline is 3. The description provides additional nuance: it clarifies the enum-style values for asset and channel, and explains that selecting a channel nulls non-selected fields—something not explicitly in the schema. It also notes the relationship between CME nulls and the data_status field. This adds real meaning 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 states a specific purpose: 'BTC/ETH institutional ETF/CME/CFTC daily metrics' and goes on to clarify the data source (OpenSearch) and the structure of results (assets[].latest and series[]). This clearly distinguishes it from sibling market snapshot and overview tools, which focus on general market data, not institutional metrics. No ambiguity remains about what it does.

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 does not explicitly name alternatives or state when not to use this tool, but it provides clear context: it is for institutional ETF/CME/CFTC metrics, read-only research data, and is explicitly not for trading or account actions. Given the narrow scope, an agent can infer when to call it, and the 'Read-only' note signals it is safe for research. However, it does not mention any sibling that covers overlapping data, so the exclusion guidance is implicit rather than explicit.

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=false, covering the safety profile. The description adds context by stating 'Read-only public research data' and clarifying 'No account access, no order placement or fund transfers,' which reinforces the non-destructive nature and adds a disclaimer about investment advice. This goes slightly beyond annotations by framing the tool's purpose as research 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?

The description is concise and well-structured. It leads with the core purpose and contents, then immediately provides routing instructions to sibling tools, and ends with safety disclaimers. Every sentence serves a purpose, and there is no redundant 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 that this is a simple zero-parameter tool with an output schema available, the description fully covers what the tool does, what it includes, and when to use alternatives. There is nothing else an agent needs to know to 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?

The tool has zero parameters, so the input schema is empty. Per the baseline rule, with 0 params the score is 4. The description doesn't need to elaborate on parameters, and it doesn't, instead focusing on scope and alternatives. This 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 broad market dashboard covering cap, volume, dominance, and sentiment, and explicitly distinguishes it from siblings by noting it does not include stablecoin ranking. It names specific alternatives for different use cases, making the purpose unambiguous.

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

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

The description gives explicit usage guidance: use this tool for a broad market overview, but for stablecoin-only ranking use get_stablecoin_info, for a single asset use get_market_snapshot, and for many symbols use batch_market_snapshot. This clearly specifies when to use this tool versus 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice,' which reinforces the safety profile and clarifies limitations beyond the annotation booleans. 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?

One sentence packs the purpose, usage routing, and safety disclaimer without wasted words. The core scope is front-loaded ('One-symbol'), followed by actionable routing. Every phrase earns its place, making it easy to scan and understand.

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 moderate complexity (six parameters, one required), the description provides sufficient routing and safety context. An output schema exists, so return format is covered structurally. It could mention default parameter values (e.g., quote default USDT) but the schema already provides that, so completeness is adequate for an agent to call 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?

The schema describes all six parameters with 100% coverage, so the description carries no burden to explain them. It mentions 'price, kline clip, project' as part of the output, which hints at what the snapshot contains but does not add parameter-specific semantics. Baseline 3 is appropriate given full 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 opens with 'One-symbol: price, kline clip, project,' which clearly identifies the tool as a single-symbol snapshot getter. It also names sibling tools for other use cases (trend, gate, batch, breadth), distinguishing it from alternatives without needing to inspect other schemas. Slightly fragmentary phrasing keeps it from a 5.

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?

Explicit routing guidance is given: 'Trend→markettrend_get_kline. Gate→marketdetail_get_kline. Many→batch_market_snapshot. Breadth→get_market_overview.' This tells the agent exactly when to use this tool versus alternatives. It also notes the read-only research context, which implies when it's appropriate to call.

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, and idempotentHint=true, covering the safety profile. The description adds disclaimers like 'No account access, no order placement or fund transfers' and 'public research data', which mostly reinforce the read-only nature rather than introducing substantial new behavioral context. It adds minimal value 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.

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

The description is brief and front-loads the core function before routing and safety disclaimers. It is somewhat fragmented with repeated 'Not investment advice' phrasing, but it is still efficient and under 50 words, with no wasted 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 tool's simplicity (read-only data retrieval) and the presence of full schema and output schema, the description covers all essential aspects: what it returns, when to use it versus alternatives, and its safe read-only nature. It also implicitly states that no auth is needed ('public research data'). Nothing an agent needs to decide whether to call it is missing.

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 all six parameters are documented with meaningful descriptions (e.g., 'ES field names e.g. rsi, macd...'). The tool description itself does not elaborate on parameter usage, semantics, or relationships; it only lists example indicators in the schema. The description adds no extra value on top of the schema, so the baseline 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 opens with 'Historical indicator columns (RSI, MACD, MAs)' which clearly identifies the function and resource. It explicitly distinguishes itself from siblings by stating 'OHLCV→get_kline. Chart-label snapshot→get_technical_analysis', so an agent can differentiate it without inspecting those 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 gives explicit routing guidance: it names the exact alternatives (get_kline for OHLCV data, get_technical_analysis for chart-label snapshots) and implies this tool is for indicator history. This is a clear when-to-use vs when-not-to-use pattern, leaving no ambiguity.

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, destructiveHint, and idempotentHint, so the description adds value by stating 'no account access, no order placement or fund transfers' and 'not investment advice.' This reinforces the read-only nature and provides user-facing context 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.

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

The description is compact and front-loaded with the core purpose (trend-index OHLCV). It uses concise routing notes and safety disclaimers without redundancy. A few segments could be merged, but overall it's efficient and structured logically.

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 an 8-parameter tool with a rich output schema, the description covers purpose, routing, and safety. It doesn't describe the output format or pagination, but the output schema exists, so this is not a gap. The description is sufficient for an agent to understand when and how to call it.

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 adds minimal new meaning beyond the schema—it mentions 'optional indicator bundle' which maps to with_indicators, but doesn't clarify other parameters like start_time/end_time or size/limit. It does not need to repeat schema details, so this 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 the tool returns trend-index OHLCV for symbols with an optional indicator bundle. Distinguishes from siblings by naming specific alternatives: marketdetail_get_kline for fine intervals, get_indicator_history for columns, and get_technical_analysis for chart-label snapshots.

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 routes to alternatives based on use case: fine intervals to marketdetail_get_kline, column-specific needs to get_indicator_history, and chart-label snapshots to get_technical_analysis. Also clarifies this is for trend-index data and adds a read-only safety note.

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, and the description reinforces this with 'Read-only public research data' and 'No account access, no order placement or fund transfers.' It adds the important distinction that output is descriptive research, not a forecast, which is beyond annotation coverage. This provides valuable behavioral context without contradicting 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 with a few dense sentences. It front-loads the core purpose, then provides alternatives and safety cues. Each sentence contributes to understanding, and no redundant information exists. It's slightly packed but still structured effectively.

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 tool has an output schema, so return format is covered elsewhere. The description explains the data source (OHLCV only), its research nature, and its read-only scope. It also names related tools for alternative needs. For a moderately simple tool with a required symbol and optional time parameters, this is adequately complete.

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 all four parameters are documented in the schema. The description adds no extra parameter-specific details, but doesn't need to because the schema is comprehensive. Baseline 3 is appropriate since the description doesn't enhance parameter 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 the tool produces multi-timeframe chart-derived labels (bullish/bearish/neutral) from OHLCV data, explicitly differentiating itself from siblings by noting 'OHLCV→get_kline' and 'Raw columns→get_indicator_history'. This distinguishes it from similar tools and provides a precise resource and verb.

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?

It gives clear context on when to use it (for descriptive research labels) and when not to (not a price forecast or investment recommendation). It also names alternatives (get_kline, get_indicator_history) and implies they are for raw data needs. However, it doesn't explicitly state 'use this tool when you need a technical analysis summary' but the alternatives and exclusions make it clear enough.

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 convey read-only, idempotent, and non-destructive. The description adds beyond that: it lists potential errors (invalid_chain, invalid_address, upstream_not_ready), clarifies no account access or order placement, includes a disclaimer, and notes Solana-specific output additions. These are valuable behavioral disclosures not present in 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 packed with information but remains efficient. It front-loads the core purpose, then provides aliases, errors, an alternative, and a safety disclaimer. No redundant sentences; each clause adds useful content. It is slightly dense but not bloated.

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 6 parameters and no output schema, the description gives a good overview of the response contents (asset summary, balances, labels/risk) and error cases. It also clarifies chain handling and the alternative for transfers. However, it does not describe the exact response structure or pagination, which could be inferred from the parameter `min_value_usd` but is not explicitly stated. Still, it is fairly complete for a read-only info 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 coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics, such as chain aliases (op→optimism, avax|avalanche-c→avalanche) and behavior of scope/errors. It also hints at the effect of chain on output (Solana adds fields). This adds value 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 'Wallet profile' and enumerates the specific data contents (asset_summary, token_balances, multi_chain_token_balances, labels/risk). It also names a sibling tool for transfers, distinguishing itself from alternatives. The purpose is unambiguous and action-oriented.

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?

It explicitly directs transfers to get_address_transactions, providing a clear alternative for a specific use case. It states it's read-only public research data, implying appropriate contexts. However, it does not give comprehensive guidance on when to choose this over other info tools, such as token-specific or platform-specific 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 cover read-only, idempotent, and non-destructive behavior. The description adds specific behavioral details: 'partial_upstream_response when upstream total>0 but list unparseable' and 'BTC items include inputs/outputs/tx_status'. It also includes disclaimers like 'No account access, no order placement or fund transfers' which reinforce the read-only nature but add little beyond annotations. Overall, it adds some edge-case context and per-chain behavior, but not deeply.

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 about 55 words and includes several short declarative sentences. It front-loads the core purpose and includes useful edge-case info. However, it contains somewhat lengthy disclaimers ('No account access... Not investment advice') that, while harmless, are not central to invoking the tool and could be trimmed. The structure is acceptable but not maximally efficient.

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 exists, the description need not detail return values. It covers a key edge case (partial_upstream_response), BTC specifics, and cross-references for chain aliases and profile usage. However, it does not clarify pagination mechanics (e.g., cursor vs. offset) beyond 'paginated', nor does it state explicitly what types of transactions are included (transfers only vs. all tx types). It is adequate but has noticeable gaps for a complex 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 like chain, tx_type, time_range, and filters are already documented. The description adds 'Chain aliases same as get_address_info', which could clarify chain naming conventions, but the schema already lists examples and open-ended dots. No additional parameter semantics beyond the schema are provided, so the baseline 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 states 'Paginated transfers' as the core action, implying retrieval of address transactions. It also specifies BTC-specific data ('inputs/outputs/tx_status'), which adds nuance. However, it does not explicitly name 'transactions' beyond the tool name, and it omits mentioning that tx_type can be 'contract_call' or 'token_transfer', so the purpose is clear but not fully exhaustive.

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 a pointer to a sibling: 'Profile→get_address_info' suggests using get_address_info for profile queries, implicitly indicating this tool is for transactions. It also mentions 'Chain aliases same as get_address_info' for reuse. However, it does not explicitly state when to prefer this tool over other on-chain tools (e.g., get_transaction or get_token_onchain) nor give exclusions. The guidance is implied rather than explicit.

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. The description adds valuable context beyond that: 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This reinforces the read-only nature and clarifies boundaries (no account access, no trading), which is useful for an agent deciding whether to call it. 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 extremely concise – four short sentences that front-load the core purpose (token scope), then give alternatives, then safety disclaimers. Every sentence earns its place, with no filler or 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 5-parameter schema with 100% coverage and an output schema, the description covers essential usage context: it states the data scopes, points to alternatives, and clarifies the read-only, non-advice nature. It doesn't explain return format, but the output schema covers that. It also doesn't detail behavior like pagination or rate limits, but those aren't critical for a read-only research tool. Overall, it provides enough context for correct selection and invocation.

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 already documents all parameters (chain, scope, token, upstream_raw_mode, include_upstream_raw). The description adds little beyond repeating scope names (holders, transfers, activity, smart_money) that are already in the scope property's description. It doesn't elaborate on param formats or defaults beyond what the schema provides, so the 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 opens with 'Token scope' and enumerates the specific data types (holders, transfers, activity, smart_money), making it unambiguous what the tool returns. It also distinguishes itself by pointing to sibling tools for address-ledger and single-transaction queries, so an agent can tell it apart without opening the schema.

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 alternates: 'Address ledger→get_address_transactions' and 'One tx→get_transaction'. This tells the agent when NOT to use this tool and which sibling to use instead. The 'Token scope' prefix clarifies that this is for token-level queries, not general on-chain address queries.

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 cover read-only and idempotent aspects. The description adds valuable behavioral context: 'fields sparse if upstream thin' warns of incomplete data, and it reaffirms no account access or order placement. 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 concise sentences front-load the core function, then add the token alternative, read-only restriction, and disclaimers. No wasted words; efficient and well-structured.

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 annotations, the description covers all necessary usage context: single transaction lookup, sparse-field behavior, the distinction from token tool, and safety boundaries. Nothing essential is missing for an agent to call 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?

The input schema has 100% coverage for all four parameters, each with descriptive text. The description adds little beyond the schema for parameters; it only hints at sparse fields in the response, which is already noted in the schema for tx_hash. Baseline 3 is appropriate given high 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's purpose: retrieve one transaction by hash. It distinguishes itself from the token-view tool by explicitly pointing to get_token_onchain, making it unambiguous among 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?

It provides clear guidance for when to use this tool vs. the token alternative, and reinforces its read-only nature. It does not explicitly exclude other on-chain tools like get_address_transactions, but the single-transaction scope is evident.

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. The description adds 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This goes beyond annotations by clarifying it is public research, non-actionable, and not financial advice, which is valuable 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 short but the second sentence 'Cross-sector dashboard across DeFi, spot, perp, stablecoin, or bridge→get_defi_overview' is cryptic and potentially confusing, detracting from clarity. While it is brief, the unclear use of the arrow hurts the structure.

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 that an output schema exists and the schema covers all parameters, the description provides sufficient context: it states the two modes (ranking vs breakdown), the scope, and safety properties. It does not explain the output format, but that is already handled by the output schema, so it is complete enough.

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 fully documents all four parameters. The description does not add any parameter-specific meaning beyond what the schema already provides, so a baseline 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 explicitly states 'Bridge ranking or one-bridge chain breakdown,' which is a specific verb+resource with clear scope. It also names the sibling tool get_defi_overview, distinguishing this tool as the bridge-focused counterpart.

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 hints at usage via 'Cross-sector dashboard across DeFi, spot, perp, stablecoin, or bridge→get_defi_overview,' suggesting that for DeFi overview one should use get_defi_overview, while this tool handles bridge data. Though not perfectly explicit, it provides a routing clue without describing exclusions for other 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=true, idempotentHint=true, and destructiveHint=false. The description adds 'Read-only public research data, no account access, no order placement or fund transfers, not investment advice' — this reinforces the read-only nature but is largely redundant with the annotations. It adds some context about the data source ('warehouse indices') but does not materially expand behavioral disclosure beyond what the annotations already convey.

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 three sentences, front-loading the core purpose first, then the data source and safety caveats. Every sentence earns its place—no fluff or repetition. It is compact and easy to parse.

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 input schema (5 params, 1 required) and an output schema present, the description covers the essential context: purpose, scope, and safety. It does not detail response format or pagination, but the output schema presumably handles that. The only minor gap is lack of explicit alternative routing, though usage guidelines cover the intended use.

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 all five parameters are documented in the schema. The description adds no additional parameter insights beyond echoing 'spot/perp' which is already in the market_type property. Per the calibration rule, the baseline is 3 when schema coverage is high, and the description does not compensate further.

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 returns competitor CEX order-book depth within ±1% for spot/perp, sourced from warehouse indices, and positions it for BTC/ETH liquidity benchmarking. This specific verb+resource distinguishes it from the sibling info_marketdetail_get_orderbook, which is not competitor-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?

It provides clear context for usage: benchmarking competitor CEX liquidity for BTC/ETH. It does not explicitly name alternatives or say when not to use it, but the 'Competitor CEX' and 'benchmarking' phrasing makes the intended scenario obvious. No exclusions are given, so it's slightly below a 5.

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 the readOnly/idempotent/destructive annotations, the description discloses concrete behavioral traits: 'granularity day only', 'hour or minute returns unsupported_granularity', 'Non-whitelist project returns data_status=not_in_scope', the l2 field exclusions ('no tx_count/l1_fee_usd'), and 'No account access, no order placement or fund transfers. Not investment advice.' All of this is genuinely additive and consistent with 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.

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

The description is front-loaded with the core purpose and contains zero wasted sentences—every clause about fields, sources, and exclusions is functional. However, it is a single dense run-on paragraph covering three variants; the lack of structural separation makes it harder to scan, and some implications (chain default derivation) are ambiguous in the paragraph form.

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 an output schema exists and 100% schema coverage, the description is quite complete: it covers data sources, whitelist behavior, granularity constraints, error paths (unsupported_granularity, not_in_scope), and read-only caveats for all three metric groups. For an 8-parameter tool with variant behaviors per group, this is thorough, though the absence of explicit when-not-to-use guidance leaves minor room for improvement.

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 every parameter already has a useful description, so the baseline is 3. The description adds real value on top by enumerating exact return fields per metric group (tps_avg_1d, active_addresses_1d, blob_cost_usd_1d, sequencer_revenue_usd_1d, stage_label; the btc_l2 whitelist stacks|rootstock|merlin|bob|bitlayer) and clarifying derived defaults (chain defaulting to ethereum/btc). It complements rather than repeats 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 a specific verb+resource: 'Chain-level activity metrics' organized by metric_group, and enumerates three distinct variants (staking, l2, btc_l2) with concrete data sources (dwd_external_l2_metrics_daily_di, dwd_external_btc_protocol_di) and field lists. This level of specificity cleanly distinguishes it from siblings like get_bridge_metrics and get_defi_overview without opening any schema.

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 context about scope by mapping each metric_group to its domain (Ethereum staking, L2 ops, BTC L2 ecosystem) and explicitly notes granularity/limit/project are group-restricted, helping the agent configure calls correctly. It does not, however, explicitly name alternatives or state when not to use this tool versus the many platformmetrics/onchain 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=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context on top: it is read-only public research data, with no account access, no order placement or fund transfers, and not investment advice. This goes beyond the annotations and helps the agent set user expectations.

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 four short sentences, each carrying a distinct piece of information: the core purpose, routing to sibling tools, the read-only nature, and legal disclaimers. It is front-loaded with the primary purpose and efficiently communicates the key distinctions and constraints without any 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?

The tool has a single optional parameter, an output schema, and clear routing for specific needs. The description covers the primary use case, the available categories, the read-only nature, and explicit disclaimers. Nothing an agent needs to correctly invoke this tool is missing, making it complete for its intended function.

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 parameter description already lists the allowed values (all|defi|spot|perp|stablecoin|bridge) and behavior for unknown values. The description's mention of the same categories does not add meaningful new semantics beyond the schema. It restates what is already structured, so a 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 states a specific purpose: a cross-sector dashboard covering DeFi, spot, perp, stablecoin, or bridge categories. It also explicitly contrasts with sibling tools by noting when to use get_bridge_metrics or get_platform_info, making the tool's scope unambiguous. Even without the title, an agent can tell what this tool does and how it differs from its 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?

The description clearly indicates when to use this tool versus alternatives: it is the cross-sector dashboard, while specific bridge rankings or chain details should go to get_bridge_metrics, and single protocol details to get_platform_info. This explicitly provides when/when-not guidance, leaving no ambiguity about which tool to select for a given intent.

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. The description adds meaningful context beyond these: it states 'Read-only public research data,' 'No account access, no order placement or fund transfers,' and 'Not investment advice.' This gives the agent a better sense of the tool's safety and purpose without contradicting 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.

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

The description is compact yet dense, using only a few sentences to pack the core purpose, optional behaviors, a routing pointer, and safety disclaimers. It is front-loaded with the main action and then proceeds to details, with no filler. 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 (11 parameters) and the presence of an output schema, the description provides sufficient orientation: it explains the scope modes, flow/event options, and the distinction from TVL history. The safety and public-data nature are also covered. There is no obvious missing information that an agent would need to 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?

The schema covers 100% of parameters, so the baseline is 3. The description adds value by explaining how parameters interact: e.g., 'scope=full adds por,' 'include_flows=true returns flows.series[],' and 'include_history=true returns precomputed comparison fields only, not raw historical snapshots.' This contextualizes the combination rules beyond individual parameter descriptions, raising it above the baseline.

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 opens with a specific verb and resource: 'Exchange reserve snapshots by venue and asset.' It immediately conveys what the tool does and distinguishes it from related tools by noting 'TVL history→get_platform_history.' This is far from a tautology and clearly differentiates it from siblings like get_platform_history 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 an explicit routing hint: 'TVL history→get_platform_history,' which tells the agent when to use an alternative. It also outlines optional parameter combinations (scope=full, include_flows, include_events) that clarify when those are applicable. It does not state exhaustive 'when not to use' conditions, but the guidance given is clear and actionable.

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 'public research data' and 'no account access, no order placement or fund transfers,' which reinforces read-only behavior and adds a bit of context about permissions. However, it does not describe rate limits, pagination, or other behavioral details beyond what annotations cover.

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 and front-loaded with the core purpose, followed by safety and advisory notes. It consists of four short sentences, each adding distinct information. No unnecessary repetition, though some content (e.g., read-only) duplicates annotations.

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 (as indicated), the description does not need to explain return format. With simple parameters and clear annotations covering safety, the description provides sufficient context for an agent to invoke the tool correctly. Minor omissions like rate limits do not significantly hinder usability.

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 (range, symbol, exchange) having its own description. The tool description does not add any additional meaning beyond what the schema already provides, so it relies on the schema. According to the baseline for high coverage, a 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 states a specific verb and resource: 'Liquidation density by symbol and price buckets.' This is clear and distinct from other platformmetrics siblings like bridge metrics or orderbook depth. However, it does not explicitly name an alternative tool, so it doesn't fully satisfy the 'distinguishes from siblings' criterion.

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 when you need liquidation density data, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions. Phrases like 'Read-only public research data' clarify safe usage but not selection criteria.

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, covering the basic safety profile. The description adds extra behavioral context: 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This reinforces that no side effects occur and clarifies the data scope. The description also clarifies a data-specific behavior (CEX perps via exchange_slug) that isn't captured in annotations. It doesn't add details on return format or pagination, but the output schema exists. Hence a 4 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.

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

The description is concise, with each sentence earning its place. It front-loads the core purpose, then provides routing alternatives, then a specific usage case, then safety disclaimers. No fluff or redundancy. The information density is high without being unwieldy.

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 read-only time series tool with a full output schema, the description covers all essential aspects: it names the exact data (TVL, volume, fees), clarifies the single-protocol scope, routes to sibling tools, explains CEX perps handling, and declares safety limitations. The output schema handles return value explanation, so no further detail is needed. The description is fully sufficient for an agent to decide when to call it and how.

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 adds value by clarifying the interplay between exchange_slug and platform_name: 'CEX perps history: pass exchange_slug (e.g. gate) or platform_name.' This explains when to use which parameter, which is not fully evident from the schema alone. It also mentions the metrics parameter's default in a prior sentence ('Daily TVL, volume, and fees'), which helps understand the metric options. This extra guidance justifies a 4.

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 returns 'Daily TVL, volume, and fees time series for one named protocol,' specifying the exact resource (one protocol) and data type. It also distinguishes itself from siblings by naming them: 'One-shot profile→get_platform_info. Ranked multi-protocol list→search_platforms.' This disambiguation is explicit and leaves no ambiguity about scope.

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 direct routing guidance: for a single protocol profile, use get_platform_info; for a ranked multi-protocol list, use search_platforms. It also gives a specific conditional usage: 'CEX perps history: pass exchange_slug (e.g. gate) or platform_name.' This goes beyond general usage and covers edge cases, making the when-to-use crystal 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, idempotentHint=true, destructiveHint=false. The description adds meaningful context: 'Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.' This goes beyond the annotations by specifying the nature of data access and safety boundaries. 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?

The description is compact yet information-dense. It leads with purpose, then explains scope, parameter interplay, alternatives, and safety—all in a few sentences with zero fluff. Perfectly front-loaded and well-structured.

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 an output schema exists, the description need not spell out return values. It covers usage, parameter interactions, alternatives, and safety constraints thoroughly. For a tool with 4 parameters and scope options, this is complete and self-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 coverage is 100%, but the description adds valuable semantics beyond the schema. It explains what scope=full truly adds: 'competition_metrics{} for CEX venues (spot/derivs/depth/OI core+extended/PoR)' and clarifies the purpose of oi_symbol_limit: 'for top-N OI breakdown'. This enriches parameter understanding 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 states the exact purpose: 'One-shot protocol profile by name and scope.' It clearly distinguishes from siblings by naming the alternatives: 'Ranked multi-protocol list→search_platforms. Daily time series→get_platform_history.' This leaves no doubt about what the tool does and what it doesn't.

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 usage context and alternatives with conditions: 'Ranked multi-protocol list→search_platforms. Daily time series→get_platform_history.' It also clarifies scope behavior and parameter prerequisites. The description tells the agent when to use this tool (single profile) and when to use others, with clear routing.

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 readOnly, idempotent, and non-destructive. The description adds contextual value by stating it is 'Read-only public research data' and clarifies it involves no account access, order placement, or fund transfers, plus 'Not investment advice.' This goes beyond annotations, disclosing the data nature and usage limits.

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 and well-structured. It starts with a clear purpose, then details the key sections, then routes to alternatives, and ends with safety caveats. Every sentence contributes value, and the most important information (purpose and sections) is front-loaded. It could be slightly more organized, but it's efficient.

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 9 optional parameters and an output schema, the description is sufficiently complete. It covers the core purpose, the behavior of the sections parameter, and safety/usage constraints. The output schema covers return values, and the schema descriptions handle parameter details, so nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions for every parameter, so the baseline is 3. The description adds extra meaning for the sections parameter, explaining what each section returns (issuance_flow gives CryptoQuant net issuance/redemption, usage_structure gives real usage metrics, depeg_events gives a de-peg event library). This provides semantic context beyond the schema's simple enumeration, justifying a 4.

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 a specific resource (stablecoin) and action (ranking or per-symbol chain breakdown), clearly distinguishing it from generic market overview tools. It explicitly differentiates from siblings by naming get_market_overview and get_defi_overview as alternatives for broader scopes, so an agent knows when this tool is the right fit.

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 context for when to use this tool (stockson stablecoin-specific queries) and explicitly points to get_market_overview for broad market dashboards and get_defi_overview for cross-sector rollups. It does not state exclusions beyond those alternatives, but the guidance is sufficient to route the agent correctly.

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=false, so the read-only nature is covered. The description adds valuable specificity beyond annotations: 'No account access, no order placement or fund transfers' and 'Not investment advice.' This fills in the operational envelope without contradicting 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.

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

The description is a single, dense sentence spread over a few lines. It front-loads the core purpose, then gives routing alternatives, then safety disclaimers. Every clause contributes meaning; there is no fluff or repetition. It is concise while packing substantial 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 tool has 8 optional parameters, an existing output schema, and comprehensive schema descriptions, the description covers the essential context: what the tool returns, how to adjust scope, which siblings cover adjacent use cases, and its safety boundaries. Nothing critical for an agent to correctly invoke the tool is missing, and the output format is already handled by the output 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 description coverage is 100%, so all eight parameters are already documented in the input schema. The description mentions 'scope=full adds apy_base_30d, ...' but this duplicates the schema's own description for scope. The main added value is the overall context that pools are sorted by APY or TVL, but that is not a parameter-specific explanation. The schema carries the semantic load, so a 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 opens with a specific verb+resource: 'Lending and LP pools by APY or TVL.' This precisely states what the tool retrieves and immediately distinguishes it from sibling tools like get_platform_info and get_platform_history, which are explicitly referenced. The purpose is clear and unambiguous.

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 routing guidance: 'One protocol profile→get_platform_info. TVL series→get_platform_history.' It also frames the tool's context as read-only public research data, clarifying when it is appropriate to use. This is strong, actionable guidance for an agent deciding between 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, idempotentHint=true, destructiveHint=false. The description adds disclaimers ('Read-only public research data', 'Not investment advice') and discloses edge-case behavior in the sort_order parameter: 'When CEX + sort_by volume_perps_* uses the HF derivatives sub-index only... response echoes the normalized value.' This goes beyond annotations, though it doesn't fully describe output shape or error handling.

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 three crisp lines with no filler. It front-loads the core purpose (ranked list with filter/sort) and then supplies routing and safety caveats. Every sentence earns its place—no redundancy with schema or annotations.

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 search tool with 5 optional parameters and an output schema, the description covers purpose, usage, safety, and parameter quirks. It doesn't mention pagination details or response format, but the output schema handles that. The routing to siblings and platform_type mapping are well-specified. A small gap: it doesn't explicitly state that the result is sorted by default but that's implied by sort_by default in 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%, so the baseline is 3. The description adds meaningful extra semantics: for sort_order it explains the CEX + volume_perps sub-index behavior and response echo, and for platform_type it already provides mapping in the schema but the description's parenthetical notes (e.g., 'any other value is passed through to the index') add context beyond the raw property definition.

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 returns a 'Ranked multi-protocol list with filter and sort', which is a specific verb (search) on a resource (platforms). It explicitly differentiates from siblings by pointing to get_platform_info and get_platform_history for other use cases, leaving no ambiguity about scope.

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?

Usage guidance is explicit: 'One-shot profile→get_platform_info. One named protocol daily series→get_platform_history.' tells exactly when to use this tool vs others. It also states the read-only, public-data nature and constraints (no account access, no order placement), giving clear context for appropriate invocation.

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