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

With no annotations, the description carries full burden. It discloses data sources (GoPlus Labs, SlowMist, BlockSec) and return values (risk score 0-100, per-flag breakdown) but omits potential rate limits, authentication needs, or data freshness details.

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 concise sentences, front-loading the core purpose then adding detection details, data sources, return values, and supported chains. Every sentence is necessary and 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?

The description explains what the tool does and returns (risk score and per-flag breakdown) but lacks examples or details about the response structure. Since no output schema exists, slightly more detail would improve completeness, but it is adequate.

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

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

Schema coverage is 100%, so schema already describes parameters. The description adds value by expanding on the 'chain' parameter with a specific list of supported chains and implying extensibility ('and more'), and by contextualizing the 'address' parameter within the tool's purpose.

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 performs wallet/address security and reputation checks, listing specific detection categories (phishing, sanctions, cybercrime, etc.) and data sources. It distinguishes itself from sibling tools like 'sanctions-screening' or 'solana-token-risk' by mentioning multi-chain support and comprehensive risk detection.

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 needing to check an address's security but lacks explicit guidance on when to use this tool versus similar siblings. No mention of when not to use or prerequisites.

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

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

No annotations provided, so description carries burden. It describes the network fetches and return values, but does not disclose potential side effects, rate limits, or failure modes. Adequate but not exhaustive.

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

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

Concise, front-loaded with purpose, then details. Every sentence adds value without fluff.

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

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

Given no output schema, description sufficiently covers input, logic, and output fields. Complete for the tool's purpose.

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

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

Schema coverage is 100% and parameter description is clear. The description adds no additional meaning beyond the schema, so baseline score of 3.

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

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

The description clearly states it checks website accessibility and agent-friendliness, listing specific files and headers inspected. It distinguishes itself from siblings by focusing on a combined readiness verdict.

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 states 'Useful for agents that need to decide whether to scrape, crawl, or interact with a domain before committing to a workflow.' Clear when to use, but does not mention alternatives or when not to use.

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

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

No annotations provided, so description carries full burden. It thoroughly describes output components (score, tier, sanctions, breakdown, attestations, stats, limits) and implies a read-only, non-destructive operation. No side effects are mentioned, but the level of detail compensates.

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 somewhat long but each sentence provides useful information. It is front-loaded with the main output and purpose. Could be slightly trimmed, but overall efficient given the complexity of outputs.

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

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

The description comprehensively covers the return values despite no output schema. It lists all major components (score, tier, sanctions, breakdown, attestations, stats, limits) and provides use cases. Given the tool's complexity, the description is complete and 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?

The only parameter 'address' is fully described in the schema (100% coverage). The description adds valuable context: 'EVM wallet address to score (0x-prefixed, 42 chars). Works on any EVM chain — score is chain-agnostic.' This clarifies format and scope 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 returns a KYA trust score for any EVM wallet, with a detailed list of outputs including score, tier, sanctions, breakdowns, attestations, and limits. It distinguishes itself from sibling tools like wallet-balance and wallet-screener by focusing on trust assessment.

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 recommends use 'before accepting payment from an agent or before dispatching a sub-agent with funds' and answers specific questions. It does not explicitly exclude use cases or mention alternatives, but the context 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?

Discloses key behaviors: uses DALL-E 3, URL hosted for 1 hour, supports styles/aspect ratios, pricing, and output format. No annotations exist, so description carries full burden and does well, though rate limits and auth are not mentioned.

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

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

Four concise sentences that front-load the main purpose, then efficiently provide details on output, styles, aspect ratios, and pricing. No unnecessary 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?

Covers input details and output expectations (URL, revised prompt) despite no output schema. Missing error handling or examples, but sufficient for an image generation 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 covers 100% of parameters with descriptions, and the description adds valuable context for prompt (specific tips, max length), and clarifies style and size options, going beyond the schema.

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

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

Clearly states it generates AI images from text prompts using DALL-E 3, lists output (public URL, revised prompt), and specifies supported styles and aspect ratios. Distinguishes itself from sibling tools, which are not image generation 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?

No explicit guidance on when to use this tool vs alternatives or when not to use it. Provides pricing and feature details but lacks context for decision-making.

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?

No annotations are provided, so the description carries full burden. It discloses the data source (CAMS), update frequency (hourly), and specific data returned (AQI category, PM2.5, PM10, etc.). However, it could be more transparent about geographic scope—'US AQI' implies a US standard but the lat/lon input suggests global coverage, which might cause ambiguity.

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

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

The description is two sentences with no wasted words. The first sentence defines the tool's core function, and the second lists returned data and use cases. It is front-loaded and 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?

No output schema exists, so the description must explain return values. It lists AQI category, specific pollutants (PM2.5, PM10, etc.), and UV index. It also mentions update frequency and data source. However, it omits units (e.g., µg/m³ for particulate matter) and could clarify whether the AQI uses US EPA standards exclusively. These are minor gaps for a tool with simple inputs.

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?

Both parameters (lat, lon) are fully described in the input schema with decimal degree examples. The description adds 'any lat/lon' but this does not extend the meaning beyond the schema. With 100% schema description coverage, the baseline is 3, and the description provides no additional parameter 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 it returns 'Real-time US AQI and pollutant readings for any lat/lon', specifying the verb (returns), resource (AQI and pollutants), and scope (US AQI, global lat/lon). Among sibling tools like 'weather' and 'weather-alerts', it distinguishes itself by focusing on air quality metrics and pollution data.

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

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

The description provides explicit use cases: 'health advisories, outdoor event planning, environment-sensitive routing, or regulatory compliance checks'. While it doesn't explicitly state when not to use or compare with alternatives like a general weather tool, the listed use cases offer clear guidance on appropriate contexts.

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?

With no annotations provided, the description carries the full transparency burden. It discloses data source (Yahoo Finance, free, no API key) and the output fields. It could mention data freshness or rate limits, but overall adequately transparent for a simple data retrieval tool.

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 with four sentences, each adding value: purpose, output details, data source, and sibling relationship. No redundancy or unnecessary 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 (one parameter, no output schema), the description covers purpose, output fields, data source, and complementary role. It lacks mention of rate limits or authentication, but is largely complete for its scope.

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 a clear description of the ticker parameter. The tool description adds context about the parameter's role (returning analyst data for US equities) but does not introduce new constraints or format details, so baseline 3 is appropriate.

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

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

The description clearly states the tool provides Wall Street analyst consensus and price targets for US equities, listing specific output fields like buy/hold/sell breakdown, mean recommendation score, and price target range. It distinguishes from siblings by stating it complements us-stock-price and equity-technicals with the analyst conviction layer.

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 names sibling tools (us-stock-price, equity-technicals) and positions itself as a complement, providing clear context for when to use. However, it does not detail when not to use or specific prerequisites beyond the ticker parameter.

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

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

With no annotations, the description discloses key behaviors: abstract truncation (600 chars), author limit (6), returned fields. But omits details like rate limits, pagination, or mutability (implicit read-only).

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

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

Four concise sentences, front-loaded with action, returns, and use cases. No redundant 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?

Lists all returned fields despite no output schema. Could mention default limit or result count limitations, but overall complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description provides examples for query and category but does not add significant new meaning beyond the schema.

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

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

Clearly states verb 'Search', resource 'arXiv preprints', and scope 'by query, filtered by field and category'. Differentiates from siblings like 'research-paper-search' by specifying arXiv-specific fields.

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

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

Provides positive context (useful for AI research, literature scouts, etc.) and mentions that arXiv is ahead of journals. However, no explicit exclusions or comparisons to 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?

With no annotations, the description carries the full burden. It discloses the use of Whisper, supported formats, size limit, and output fields. However, it omits important behavioral traits like processing time, error handling for large or inaccessible files, and model version.

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 paragraph of about five sentences, front-loading the main purpose. It is mostly concise, though the pricing comparison line may be slightly extraneous for tool selection.

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 two parameters and no output schema, the description covers core functionality, output structure, and use cases. However, it lacks details on error scenarios and performance expectations, leaving some gaps for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reiterates the language hint and URL requirements but adds no new 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 specifies the verb 'transcribe', the resource 'audio', and the method 'OpenAI Whisper'. It clearly states what the tool does and lists supported formats and a size limit. However, it does not explicitly differentiate from sibling tools, though none appear to offer transcription.

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 use cases such as 'voice memos, meeting recordings, podcast snippets' and notes the option to provide a language hint. However, it lacks explicit guidance on when not to use the tool or mention of 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?

No annotations provided, so description carries full burden. It discloses real-time data from NOAA, no API key needed, and specifies output includes current conditions and 24-30 hour forecast. Lacks details on error handling or rate limits, but sufficient for a simple tool.

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

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

Two sentences, front-loaded with most important info (what it returns), then input format and source. No wasted words.

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

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

Given low complexity (1 param, no output schema), the description covers essential aspects. It could be more complete by hinting at the output structure (e.g., includes both METAR and TAF), but current version is adequate.

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

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

Schema coverage is 100% with a clear description of the airport parameter. The description adds context by specifying IATA/ICAO formats and providing examples, adding value beyond schema.

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

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

The description explicitly states the tool returns aviation weather (METAR + TAF) for any airport, listing specific data points (temp, wind, etc.). It distinguishes itself from siblings like 'weather' by specifying aviation-specific data and source.

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 clearly states accepted input formats (IATA/ICAO). While it doesn't explicitly contrast with alternatives like the general 'weather' tool, the context of aviation weather is sufficient. Could be improved by mentioning when not to use it.

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

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

With no annotations, the description carries full burden. It lists the data returned (TVL, protocols, etc.), implying a read-only operation. However, it does not explicitly state that the operation is safe or discuss data freshness or 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?

Two concise sentences: first lists contents, second gives usage context. No wasted words, front-loaded with essential 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?

For a zero-parameter tool with no output schema, the description provides sufficient context: what data is returned and when to use it. It could improve by mentioning output format or an example, but overall 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?

No parameters exist, so the description correctly has no param info. Baseline for 0 params is 4, and the description does not need to compensate.

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 provides a snapshot of Base chain TVL, top protocols, category breakdown, trend, and ecosystem tokens. It distinguishes itself from siblings like 'chain-pulse' or 'defi-market-pulse' by specifying the Base chain and the specific data items.

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 advises using this tool for pre-trade orientation before DeFi actions on Base. It implies when not to use (for other chains or execution), but does not explicitly list alternatives or exclusions.

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

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

With no annotations, the description carries the burden. It explains what the tool does (returns block data) and what inputs it accepts, but does not disclose potential side effects, rate limits, or that it is read-only.

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

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

Two sentences, no waste. The first sentence covers output and scope; the second adds supplementary context. Well-structured and 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?

For a simple data retrieval tool with two parameters, the description is fairly complete. It specifies networks, block identifiers, and return fields. Lacks error handling or rate limit information, but adequate for basic 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 coverage is 100%, so the description adds minimal value. It mentions pricing but does not elaborate on parameter meaning 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 returns block header data for specific chains and lists the fields. However, it does not differentiate from siblings like 'eth-block' which may have overlapping functionality.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions a pricing comparison but does not provide usage context for an AI agent.

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?

No annotations exist, so description carries full burden. It states 'Pure URL parsing — zero external calls,' clarifying no side effects. It also mentions identifying numeric vs named path segments, but lacks detail on error handling or output format structure.

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, a single paragraph of two sentences, with the main action front-loaded. It is well-structured and easy to read, though could be slightly more compact.

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

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

Given no output schema, the description thoroughly explains the return values (domain, path segments, labels, query parameters, formatted string) and additional behavior (identifying numeric vs named). It covers all necessary aspects for a tool of this complexity.

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

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

Schema coverage is 100%, and description adds context by explaining the URL parameter's purpose and mentioning the default separator. It provides meaningful interpretation 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 it extracts structured breadcrumb navigation from a URL and specifies the return components (domain, path segments, labels, query parameters, formatted string). It also mentions identifying numeric IDs vs named segments, making it distinct from any sibling 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 mentions it is useful for processing sitemaps, navigation menus, or understanding page hierarchy, providing context. It does not explicitly state when not to use or mention alternatives, but given no similar siblings, this is adequate.

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?

No annotations are provided, so the description carries the full burden. It discloses data sources (mempool.space, CoinGecko) and that no API key is needed, implying a read-only, safe operation.

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 paragraph that efficiently lists outputs and sources, with zero wasted words. It is front-loaded with the core purpose.

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

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

Despite having no output schema, the description enumerates all returned values and explains their significance. For a complex tool with 3 parameters, this is 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 coverage is 100% and the description adds context beyond each parameter's schema description by explaining their role in the models and providing sensible defaults.

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 uses a specific verb ('Returns') and names multiple concrete metrics (selfish-mining profitability threshold, 51%-attack electricity cost, etc.), clearly distinguishing it from siblings like btc-miner-econ and btc-systems-theory.

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 states explicit use cases ('miner-incentive analysis, network security assessment, pre-investment regime detection') but does not mention when to avoid this tool or suggest 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?

With no annotations, the description carries full burden. It does not disclose behavioral traits like read-only nature, safety, or side effects. Lists returned data but omits important context such as no destructive actions.

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 well-organized paragraph with front-loaded purpose, enumerated data items, and closing use-case guidance. No wasted sentences.

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

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

Given the complexity of multiple data sections and no output schema, the description adequately explains all returned fields. Covers key aspects for a query tool, though could mention return format details.

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 parameter description. The tool description adds context about data sections but does not enhance parameter meaning beyond the schema. Baseline 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 clearly states it returns Bitcoin mining economics and fee-market game theory data, listing specific data sections. It distinguishes from sibling tools like 'btc-game-theory' by focusing on mining economics.

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 context on when to use: 'useful for agents reasoning about BTC transaction timing, miner incentive structures, or on-chain network health.' Does not explicitly exclude alternatives but implies appropriate scenarios.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently lists the seven outputs, states the data source (mempool.space), and confirms no API key is required. It does not mention rate limits, error handling, or performance, but for a read-only analysis tool, the provided info is adequate.

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

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

The description is a single, well-structured paragraph that uses numbered items to enumerate the seven lenses. Every sentence adds value, with no filler. It is concise yet comprehensive, front-loading the key action and output list.

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

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

Given no output schema, the description fully explains what the tool returns by detailing each of the seven analysis components. It also includes information on data sourcing and API requirements, making it complete for an agent to understand the tool's capabilities.

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 has 100% coverage for the single parameter 'pool_window', described as a rolling window for mining pool distribution. The description adds semantic value by linking this parameter to the mining pool related outputs (Nakamoto coefficient, HHI index), giving practical context beyond the schema 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 it performs a seven-lens systems theory analysis of the Bitcoin network, listing each lens explicitly. It distinguishes itself from the sibling tool 'btc-game-theory' by indicating they pair for full analysis, making the purpose specific and differentiated.

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 mentions pairing with 'btc-game-theory' for complete Bitcoin systems and incentive analysis, providing context on when to use this tool in combination. However, it does not explicitly state when to use this tool alone or versus other sibling tools, missing clear usage boundaries.

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?

No annotations are provided, so the description carries the full burden. It discloses supported chains (Ethereum, Base, Polygon, Arbitrum), free upstreams (DRPC + DeFiLlama), and that no API key is required. It lists the fields returned. It does not mention rate limits or error handling, but for a read-only tool this is adequate.

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

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

Three well-structured sentences with no wasted words. The first sentence states purpose, the second explains what it does, and the third gives supported chains and upstream details. Front-loaded and 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?

The description covers purpose, supported chains, free API, and missing API key requirements. It lists fields returned, which compensates for the absence of an output schema. It does not explain depeg status values, but that is minor. Fairly complete for a simple 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 baseline is 3. The description adds context by listing block and stablecoin fields and explaining the alert_only filter, but does not add deep semantics beyond what the schema already provides for each parameter.

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

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

The description clearly states the tool returns an Ethereum block header and stablecoin depeg status in one call, with a specific verb 'returns' and resources 'block header + stablecoin depeg status'. It distinguishes from siblings like eth-block and stablecoin-watch by collapsing the two-hop chain.

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 this tool is for when both block and stablecoin info are needed together, but it does not explicitly state when not to use it or mention alternatives (like calling eth-block and stablecoin-watch separately). Guidance is implied but not 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?

Discloses behavior: groups commits into sections, returns markdown or JSON, no API key needed. However, does not mention maximum commit limit (500 in schema) or handling of non-conventional commits. Since no annotations, description carries full burden but leaves some gaps.

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

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

Three sentences, front-loaded with purpose, efficient explanation of grouping and output. No unnecessary 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?

No output schema, but description clarifies return types. Covers core functionality; could detail JSON structure more, but sufficient for a straightforward transform.

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 parameter descriptions. Description adds value by explaining grouping logic and output types (markdown/JSON), which goes beyond schema. Slight extra context on default version and date (defaults are in schema but description reinforces).

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

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

Description clearly states the verb 'Converts' and resource 'commit messages to a keep-a-changelog release block'. It distinguishes from siblings as no other tool handles changelog generation.

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?

Implies usage for converting conventional commits to changelog format. Notes 'No API key — pure transform' which guides usage as a local transformation. Could be more explicit about when to use vs alternatives, but no direct sibling exists.

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?

With no annotations provided, the description carries the full burden. It notes 'Pure math — instant, zero API calls,' which informs about reliability and speed. It also lists the computed quantities, but does not detal side effects or constraints beyond what the schema provides.

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

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

Two sentences that are front-loaded with the main verb ('computes') and resources. No redundant information; every sentence contributes meaning.

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

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

Given no output schema, the description lacks details on the return structure (e.g., units format for accumulated dispersion, how sweep results are returned). For a calculator with 4 parameters, more explicit output description would enhance completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by mentioning fiber type examples (SMF-28, NZDSF, etc.) and the sweep options (C-band, L-band, custom), but it does not significantly enhance 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 clearly states it is a 'fiber optic chromatic dispersion calculator' that computes specific metrics like dispersion coefficient, accumulated dispersion, and dispersion slope for listed fiber types. It is specific and distinct from the long list of sibling tools, which are unrelated.

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

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

The description explicitly lists use cases: 'optical network design, DWDM link budget, and dispersion compensation planning.' It does not state when not to use it or compare to alternatives, but the niche application is 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?

No annotations provided, so description carries full burden. It discloses return metadata, data source (CrossRef), and scale (148M+ works). Does not mention rate limits, authentication, or error handling, but sufficient for a read-only lookup.

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: purpose, return info, and use cases. No unnecessary words, front-loaded with the core function.

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

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

No output schema, but description explains return values (authors, year, etc.). Covers data source and scope. Lacks mention of error cases like invalid DOI, but overall adequate for the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond what's in the schema for doi and format parameters; it only provides context about return format.

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

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

Description clearly states it looks up a paper by DOI and formats into multiple citation styles. Specific verb+resource, distinguishes from siblings like research-paper-search or arxiv-intel by focusing on formatting.

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?

Mentions use cases (reference lists, literature reviews, knowledge extraction) providing context. Lacks explicit when-not-to-use or alternatives, but the purpose is clear enough to guide appropriate 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?

No annotations are provided, so the description carries full burden. It discloses output fields and search inputs, which is adequate for a simple lookup. However, it lacks details on error handling, empty results, or rate limits.

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

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

Two concise sentences with no filler. Front-loaded with the action and resource, then details on output and use cases.

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 simple lookup tool with no required parameters, the description covers purpose and output adequately. It could mention behavior with empty queries, but overall it is complete enough for an agent to select and invoke.

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 context by relating inputs to examples (e.g., 'London', 'LHR') but does not significantly enhance 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 searches airports and cities by keyword, IATA code, or city name, and lists the returned fields (IATA/ICAO codes, coordinates, country, timezone). It is specific and distinct from siblings.

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

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

The description mentions usefulness for travel planning, routing, and geographic enrichment, providing some context. However, it does not specify when not to use this tool or differentiate it from siblings like flight-tracker or geocode.

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?

No annotations are provided, so the description carries the burden. It discloses the return fields (publication year, subjects, page count, cover images, links) but doesn't discuss limitations, authentication, rate limits, or default behavior (e.g., max results from limit parameter). It adds context about the data source but lacks depth.

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

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

The description is two sentences: first sentence states the core functionality and source, second sentence lists outputs and use cases. It is front-loaded, efficient, and every sentence adds value with no redundancy.

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

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

Given the absence of an output schema, the description adequately explains what the tool returns and its applications. It covers the main parameters and results. However, it doesn't specify how parameters combine or the default behavior when no parameters are provided, which could be improved.

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 all parameters described in the input schema. The tool description does not add extra meaning beyond what the schema provides; it only lists use cases without elaborating on parameter usage or combinations.

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

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

The description clearly states that the tool 'looks up classic and contemporary books by title, author, or ISBN via Open Library' and lists what it returns. It distinguishes itself from siblings by specifying the niche (classic and contemporary books) and sources (Open Library, Project Gutenberg, Internet Archive), though it doesn't explicitly contrast with similar research 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 mentions use cases ('research agents, reading recommendation workflows, literature analysis, and bibliographic data enrichment') which implies when to use, but it provides no guidance on when not to use or alternatives among sibling tools like 'research-paper-search' or 'arxiv-intel'.

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?

No annotations provided, so description carries full burden. It mentions source (NIH) and cost, but does not disclose behavior like read-only nature, rate limits, or side effects. Could be more explicit.

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

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

Two sentences, front-loaded with action and inputs, followed by output and context. Zero 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?

Covers inputs, outputs, source, and cost. Missing pagination or error handling, but output schema is absent. Good for a straightforward search 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% with good descriptions. Description adds little beyond schema (only hints at condition/intervention/keyword). Baseline 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?

Clear action 'Search ClinicalTrials.gov' and specific query types (condition, intervention, keyword). Lists return fields: phase, status, enrollment, sponsor, dates. No sibling tool overlaps, so differentiation is not needed.

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?

Implied usage from purpose, but no explicit when-to-use or alternatives mentioned. However, the tool's niche is distinct among siblings, so the lack of alternatives is acceptable.

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?

With no annotations, the description carries full burden. It discloses the static analysis nature (no execution), cost per call, and supported frameworks. However, it lacks details on limitations (e.g., max code size, potential failure modes).

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 purpose. It includes all key details in one paragraph. Could benefit from bullet points or more structured formatting, but it is effective and not verbose.

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

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

Given no output schema, the description explains the output JSON structure (routes[], exports[], etc.) and mentions cost. It covers supported frameworks and the nature of analysis. Missing error handling or explicit size limits beyond recommendation.

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 does not add significant meaning beyond the schema's parameter descriptions (code and detail). The cost and output fields are mentioned, but not parameter-specific.

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

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

The description clearly states it analyzes code snippets to return API surface (routes, exports, middleware) and lists supported frameworks. It distinguishes itself from siblings like 'code-test-detector' by focusing on API-specific analysis.

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 mentions 'Pure static analysis — no code execution' which implies safety, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Usage context 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?

With no annotations, the description must disclose behavioral traits. It states 'No code execution — pure static analysis,' indicating safety and non-destructiveness. It explains what it identifies (test functions, assertions, etc.) but does not mention permissions, rate limits, or API dependencies for GitHub repo analysis.

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

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

Two efficient sentences: first sentence states the purpose, second expands on both usage modes. Every sentence adds value with no redundancy. Front-loaded with the key action and scoped with examples.

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

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

Given the complexity of dual modes (snippet and repo) and no output schema, the description adequately covers what the tool does and what it returns (e.g., coverage verdict, config files). It lacks detailed output structure but provides sufficient context for an agent to decide on 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 coverage is 100% with descriptive parameter explanations. The description adds value by explaining processing modes (e.g., 'surfaces config files' for repos) beyond the schema's basic descriptions. It compensates well for the lack of required parameters.

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 precisely states it detects testing frameworks and coverage presence for code snippets or GitHub repos, with concrete examples (Jest, pytest, etc.) and specific actions (counts test files, surfaces config files). It clearly distinguishes itself from siblings like code-api-surface.

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

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

The description implies usage for analyzing test coverage in code or repos but does not explicitly state when to use this tool over alternatives or when not to use it. It provides clear context for two modes (snippet vs. repo) but lacks exclusion guidance.

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

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

No annotations exist, so the description fully covers behavior: it's a read-only live price tool, lists included metrics, and mentions pricing and API source. Could add update frequency but overall good.

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 with no fluff: purpose, included metrics, filtering options, and pricing. Front-loaded with key info.

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?

No output schema, but description lists return fields (price, day high/low, 52-week range, etc.). Parameters are well-explained. Complete for a simple data retrieval 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 baseline 3. Description adds value by explaining the interaction between 'commodities' and 'category' (e.g., ignoring category if commodities list provided).

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 verb ('Returns'), resource ('live price and intraday metrics for major commodity futures'), and lists specific commodities. It distinguishes from sibling financial tools by focusing on commodity futures.

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?

Clear filtering options (by commodity name or category) and pricing information are provided. It does not explicitly compare to alternatives, but the context is sufficiently 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?

No annotations provided, so description must cover behavioral traits. It mentions querying SEC EDGAR and optionally analyzing the website, but does not disclose authentication needs, rate limits, failure modes (e.g., company not public), or what happens to data. The description lacks depth on side effects or restrictions.

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

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

Description is four sentences, front-loads purpose, and uses no filler words. It efficiently conveys the tool's functionality and optional behavior.

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?

Description covers the tool's two sources and output type (structured report with risk flags) but lacks details on report fields, error handling, or performance. Given no output schema, more specificity on return value would improve completeness.

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

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

Schema description coverage is 100% with both parameters having descriptions. The description adds that providing a domain adds website intelligence, which slightly extends the schema. Since coverage is high, baseline 3 is appropriate; the added value is minimal.

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

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

Description clearly states the tool performs due diligence on any company, querying SEC EDGAR for public data and optionally analyzing the website for contact and legitimacy signals, returning a structured report with risk flags. This distinguishes it from siblings like 'company-intel' (likely SEC-only) and 'web-company-intel' (likely website-only).

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?

Description implies usage for company due diligence but does not explicitly state when to use this tool versus alternatives or when not to use it. It notes that the website analysis is optional, which provides some context, but lacks explicit comparisons or exclusions.

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

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

With no annotations, the description discloses the upstream source (SEC EDGAR public API), that it is free and always current. It does not explicitly state read-only behavior or discuss rate limits, but the disclosed source and nature imply safe read operations.

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 efficient paragraph with front-loaded purpose. Every sentence adds value, though it could be slightly more concise by omitting minor details like 'Free upstream: SEC EDGAR public API' which could be inferred.

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

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

Given no output schema, the description lists return fields and mentions data freshness. It covers the tool's main functionality but lacks behavior on invalid tickers. Overall, it provides sufficient context for a tool with a single parameter.

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 single parameter 'ticker' has a schema description clarifying case-insensitivity and class-suffix handling. Since schema coverage is 100%, the description adds little beyond the schema, meeting the baseline of 3.

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

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

The description explicitly states the tool returns SEC EDGAR due diligence data for US public companies by ticker, listing specific data fields like legal name, CIK, SIC code, etc. It clearly distinguishes itself from siblings with a unique set of outputs.

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 use cases: 'Use before any agent task involving US public company identification, regulatory filing assessment, financial analysis, or industry classification.' It mentions the free, always-current data source but does not specify when not to use it or contrast with overlapping siblings like 'sec-filing-intel' or 'company-due-diligence'.

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?

No annotations are provided, so the description must disclose behavioral traits. It describes what the tool returns but fails to state whether it is read-only, if authentication is required, or any side effects. This is insufficient for safe agentic decision-making.

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

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

The description is two sentences, front-loading the return values and usage context. No redundant information; every sentence serves a purpose.

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

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

For a simple scoring tool with 2 parameters and no output schema, the description covers the purpose and key return metrics. However, it lacks details on error conditions, data freshness, or output format, leaving some gaps for an agent.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds the context 'x402' and 'pay_to wallet' but does not significantly enhance understanding beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a concentration-risk score for an x402 pay_to wallet, listing specific metrics (HHI, unique payer count, etc.). It names the resource and verb, but does not explicitly differentiate from sibling tools like 'address-security' or 'agent-access-check' that may also assess risk.

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 specific use case: assessing whether an endpoint is a single-agent dependency before building a workflow. However, it does not mention when not to use this tool or recommend alternatives, leaving the agent to infer boundaries.

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?

With no annotations provided, the description carries the full burden. It discloses return fields, source, and cost, but omits details on rate limits, data freshness, authentication requirements, and error handling. For a read-only query tool, this is adequate but not comprehensive.

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

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

The description is four sentences with front-loaded purpose, followed by mode explanation, return fields, and source/cost. Every sentence adds value with no redundancy, achieving excellent conciseness and logical 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 the tool has 4 optional parameters, no output schema, and no annotations, the description covers the essential aspects: modes, returned data, source, and cost. It lacks examples or interpretation of performance metrics, but is still fairly complete for a straightforward query 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 context beyond the schema by explaining the dual behavior of the 'ticker' parameter and summarizing what fields are returned. However, it doesn't enumerate permitted values for 'transaction_type' or 'chamber', leaving some ambiguity.

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

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

The description clearly states it retrieves US congressional stock trades under the STOCK Act. It distinguishes two explicit modes: supplying a ticker for stock-specific trades or omitting it for market-wide activity. This specificity and differentiation from sibling tools like 'insider-trades' (corporate insiders) earns top marks.

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 guidance on when to use each mode ('supply a ticker' vs 'omit ticker') and mentions no API key is required. However, it does not explicitly state when not to use this tool or suggest alternatives (e.g., for corporate insider trades), thus slightly lacking in exhaustive guidance.

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

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

With no annotations provided, the description must disclose behavioral traits. It does mention that the tool uses GPT-4o-mini and fetches 8 FRED signals, implying a read-only, external-data-dependent process. However, it lacks details on data freshness, latency, potential costs, or whether the LLM call introduces variability. It does not contradict any 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 paragraph that efficiently packs key information: data sources, LLM usage, output components, and use cases. It is front-loaded but could be slightly better structured with bullet points or clearer separation of input/output.

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

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

Given no output schema and zero parameters, the description thoroughly explains the tool's behavior. It lists the 8 FRED signals, the LLM synthesis step, the output components (including narrative and risk), and the intended applications. This provides a complete understanding of what the tool returns and when to use 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?

The input schema is empty (0 parameters), so schema coverage is trivially 100%. The description compensates by explaining what the tool does without needing parameters, clearly implying no user input is required. While no parameter-specific info is needed, the description adds value by listing the underlying data sources and outputs.

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: it produces an AI-synthesized US consumer health briefing by fetching 8 specific FRED signals and using GPT-4o-mini for synthesis. The verb 'fetches' and 'produces' specify action and output, and the detailed list of output components distinguishes it from sibling tools like macro-brief or equity-brief.

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 implicitly provides usage context by listing the tool's inputs (8 FRED signals) and outputs (consumer posture, spending regime, etc.), indicating it is appropriate for US consumer economic analysis. It mentions specific use cases like retail sector exposure and consumer credit risk, but does not explicitly contrast with alternatives or provide when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool fetches a URL, extracts article text, and returns specific data fields, plus cost. However, it does not mention failure modes (e.g., non-article URLs), rate limits, or authentication requirements. The behavioral picture is decent but incomplete.

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: first states purpose, second lists output specifics, third gives use cases and cost. No wasted words, front-loaded with essential information. Highly 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 no output schema, the description thoroughly enumerates return fields (summary, key points, entities, sentiment, topics, classification, credibility). It covers cost and typical use cases. Missing are constraints (e.g., URL type limitations, content length caps) but for a single-purpose analysis tool, this is quite 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 coverage is 100%, so the baseline is 3. The description adds minimal context: it repeats the schema descriptions for 'url' and 'focus' but does not provide additional details beyond examples. The focus parameter's description ('Narrows the analysis') adds slight value, but overall the description does not significantly surpass 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 it performs AI-powered URL content analysis, fetching a URL and extracting article text to return structured intelligence. It lists specific outputs (summary, key points, entities, sentiment, etc.), which distinguishes it from general web scraping or page fetching 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 provides use cases ('content intelligence pipelines, research synthesis, or automated brief generation') but does not explicitly contrast with sibling tools like 'readable-content' or 'page-intel', nor does it specify when not to use this tool. The guidance is adequate but lacks exclusions or alternative recommendations.

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?

No annotations provided, so description carries full burden. It discloses return fields (flagged status, risk level, categories, confidence scores, safe rewrite) and notes latency for rewrite. However, it does not explicitly state read-only nature or auth requirements.

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

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

Two concise, information-dense sentences. Front-loaded with purpose, then enumerates return fields. No extraneous 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?

Covers purpose, parameters, and output adequately. Missing edge cases like simultaneous text and image handling or error scenarios, but sufficient for typical 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 coverage is 100%, baseline 3. Description adds value by explaining the 'rewrite' parameter's latency implication and clarifying 'text' conditionality. Enhances schema description.

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 classification of text and optional images for harmful content with specific categories like hate speech and violence. Distinguishes from sibling 'content-analyze' by focusing on moderation.

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?

Implied usage for content moderation, but no explicit guidance on when not to use or alternatives. Sibling tools like 'content-analyze' could be confused without further direction.

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?

No annotations provided. Description does not disclose behavioral traits such as rate limits, required permissions, or side effects. It is implied to be read-only but lacks explicit behavioral context.

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

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

Description is a single, focused paragraph. It front-loads the purpose, lists outputs, then provides use cases. 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?

For a simple lookup tool with no output schema, the description adequately lists return fields and use cases. It covers the main functionality and context, though could include more about parameter combinations or edge cases.

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 explains each parameter. The tool description does not add additional meaning beyond listing search methods, which is already clear from parameter 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?

Clearly states the tool looks up country information by name, ISO code, or capital city, and lists return fields. Purpose is specific but does not explicitly differentiate from siblings like city-lookup or geocode.

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?

Mentions use cases (international business, geographic enrichment, etc.) but does not specify when to use versus alternatives or provide exclusion 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?

No annotations provided. Description discloses source and data points but not update frequency, historical depth, or limitations. Partially transparent.

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

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

Two sentences, front-loaded with key action and resource. No fluff.

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

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

Covers data sources, specific metrics, and relationship with sibling. No output schema, but enough context for a simple retrieval 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?

No parameters; schema coverage 100%. Description adds context about data content (which indices, OAS values) beyond schema.

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

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

Clearly states it returns US corporate credit spreads from ICE BofA indices via FRED. Specifies three OAS values, HY-IG differential, and risk regime. Distinguishes from treasury-yields by mentioning pairing.

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?

Tells when to use (for credit spreads) and pairs with treasury-yields for discount rates. Notes free FRED data but lacks explicit when-not or 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?

No annotations provided, so description carries full burden. It describes core behavior (parsing, returning runs, supporting shortcuts) and 'Zero external calls', but does not detail default values, error handling, or input validation. The schema parameter descriptions cover defaults, but the tool description could add more behavioral detail.

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

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

Description is four concise sentences, front-loaded with purpose, then output, then features, then performance note. No redundant or irrelevant 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 low complexity, rich schema coverage, and no output schema, the description sufficiently explains purpose, outputs, supported formats, and a key behavioral trait (no external calls). 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 coverage is 100% with clear parameter descriptions, so baseline is 3. The tool description does not add additional semantic context beyond what the schema provides; it mentions return components but not parameter specifics.

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 'Parse and explain any Unix cron expression in plain English' with a specific verb and resource. It lists return components and supported shortcuts, distinguishing it from all sibling tools (none parse cron).

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 context: whenever a cron expression needs parsing or explanation. It does not explicitly state when not to use or provide alternatives, but given the unique functionality, this is acceptable. The note 'Zero external calls' adds reliability 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?

No annotations given, so description carries full burden. It discloses read-only nature, data source (alternative.me), update frequency (daily), and cost ($0.005/call). No contradictions; behavior is clearly a data retrieval.

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

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

Two sentences, front-loaded with main output, then details on trend, summary, data source, and cost. Every sentence contributes information without redundancy.

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

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

Given simple tool with one parameter and no output schema, description fully covers expected output (score, trend, min/max/avg, regime signal), data source, update frequency, and pricing. No gaps for agent to infer.

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

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

Schema already describes the single parameter 'days' with full coverage. Description adds value by explaining that it affects trend (7-day) and summary (30-day min/max/avg), linking parameter to output components.

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

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

Description clearly states the tool provides the Crypto Fear & Greed Index with current score, trend, min/max/avg, and trading regime signal. It distinguishes from generic crypto tools by specifying the index and included metrics.

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?

Description implies usage for market sentiment but does not explicitly state when to use this tool versus alternatives like crypto-momentum-pack or crypto-pulse. No exclusions or alternative suggestions provided.

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?

With no annotations, the description carries full burden. It discloses that the upstream is CoinGecko public API (no key required) and states the return includes 'current price, 24h percent change per currency, and last updated timestamp.' This provides good behavioral insight, though rate limits or error handling are not mentioned.

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

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

The description is concise: three sentences with no wasted words. It is front-loaded with the core purpose, followed by examples, then context. Every sentence adds value.

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

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

Without an output schema, the description explains the main return fields: current price, 24h percent change, and timestamp. However, it omits details on response format (e.g., JSON structure) and error handling if a coin is not found. For a simple tool, this is mostly complete but could be slightly more explicit.

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 both parameters described. The description adds value by providing examples of coin names and currency codes, and specifies the default for currencies ('Default: usd,jpy,eur'), which goes beyond the schema alone.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Cryptocurrency price in any fiat currency.' It lists example currencies and coin names, and distinguishes from siblings by noting it is free and simple, with explicit comparison to 'specialized fiat oracles.'

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

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

The description provides context for when to use the tool, such as 'Asian/European market agents, cross-border DeFi pricing, and multi-currency portfolio valuation.' It hints at alternatives by stating '85% below specialized fiat oracles' but does not explicitly name sibling tools or state when not to use it.

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

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

Despite no annotations, the description discloses key behavioral traits: it returns data from multiple sources, adds ~1s latency when include_yields is true, and notes cost savings (53% of chain cost). It also explains the effect of korean_only (faster, omits global movers). No contradictions.

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

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

The description is concise at four sentences, front-loading the core functionality. Every sentence provides unique information: first sentence states the combo, second mentions cost, third specifies returns, fourth gives use case. No wasted words.

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

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

Given the absence of annotations and output schema, the description covers the tool's inputs, outputs, and use cases well. It explains the multi-source nature, latency, and cost. A minor gap is the lack of output structure, but the description sufficiently sets expectations.

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 parameters, but the description adds significant value: for include_yields it notes latency impact, for korean_only it specifies speed and omission of global data, and for limit it clarifies 'per source'. This goes beyond the schema's base 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 what the tool does: combines Korean exchange volume leaders, global 24h movers, and optional DeFi yield cross-reference in one call. It specifies the return types (top gaining/losing/volume-leading tokens on Upbit, global CoinGecko movers, and DeFi yield pools). This distinguishes it from sibling tools like korean-crypto-movers, market-movers, and defi-yields.

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 use cases: 'pre-trade momentum confirmation, cross-exchange alpha identification, and DeFi capital allocation.' It also mentions that Korean volume often leads global moves, implying when this tool is valuable. However, it does not explicitly exclude scenarios or list alternative 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?

No annotations are provided, but the description fully discloses data sources (CoinDesk RSS, CoinGecko), caching TTL (5 min), output fields (title, URL, timestamp, category, sentiment), and enrichment logic (asset-to-price mapping). This covers key behavioral traits beyond what annotations would typically specify.

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

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

Description is 4-5 sentences, front-loading purpose and data freshness. Every sentence adds unique information: source, TTL, output details, enrichment, usage guidance. 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 single optional parameter and no output schema, the description thoroughly covers return fields, sentiment derivation, asset enrichment, and data provenance. For a news tool, this is complete and actionable.

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?

Only one parameter (limit) with schema coverage 100%, so baseline is 3. The description adds value by explaining the default (10) and the output structure (articles with enrichment), which helps the agent decide an appropriate limit.

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 specifies the tool fetches the latest crypto news from CoinDesk and correlates with live prices. It clearly states the verb (fetch), resource (news headlines), and enrichment (price correlation), distinguishing it from other crypto tools like sentiment indices or fundamental data.

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

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

Explicitly says 'Use before any crypto research, portfolio review, or market sentiment task to understand what news is driving the market right now.' Provides clear context but does not mention alternatives or when not to use, preventing a score of 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?

No annotations are provided, but the description discloses the data sources (DRPC + CoinGecko), the cost ($0.007/call), and the output fields. This is sufficient for a read-only data tool. It does not mention any destructive or side effects, which 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 a single paragraph that packs in a clear statement of purpose, return fields, use cases, data sources, and cost. It is well-structured and front-loaded, though could be slightly more concise.

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 no output schema, the description details the return fields comprehensively. It explains the data sources and use cases. It does not cover error conditions or rate limits, but for a simple data retrieval tool with two optional parameters, it 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?

The schema coverage is 100%, and the description adds meaning beyond the schema: it specifies that 'network' can be 'ethereum' or 'Base' (schema only says 'Chain for block context' and default 'ethereum'), and that 'movers_limit' ranges from 1-20 (schema only says '1–20'). This provides valuable context for parameter usage.

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 'Crypto market pulse — latest Ethereum (or Base) block context plus top crypto gainers and losers by 24h change, in a single call.' It lists the specific data fields returned and distinguishes itself from siblings like 'crypto-top-movers' and 'eth-block' by combining both in one call.

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

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

The description explicitly suggests use cases: 'Use for crypto portfolio context, on-chain/market correlation, or pre-trade situational awareness.' It also mentions cost savings compared to a two-endpoint chain. However, it does not mention when not to use or specific 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?

No annotations are provided, so the description carries the full burden. It discloses that data comes from CoinGecko public API refreshed every 1-5 minutes, that stablecoins are excluded from the movers ranking, and implies read-only, non-destructive behavior. This is transparent enough for an agent to understand the tool's behavior.

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 well-structured and front-loaded with the essential content. It is slightly verbose but every sentence adds value (purpose, usage, data source, refresh rate). No wasted words.

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

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

Given no output schema and no annotations, the description effectively explains the return content (gainers, losers, top 10 coins with prices and 24h change, global stats). It could detail the exact structure of responses, but the level of detail is sufficient for the tool's simplicity.

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 zero parameters, so the baseline is 4. The description adds no parameter info since none exist, but this is appropriate. The description's mention of what the tool returns compensates for the lack of output schema.

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

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

The description explicitly states that the tool provides a real-time snapshot of top 5 gainers and losers, top 10 largest coins by market cap, and global market statistics. It uses specific verbs (snapshot, gainers, losers, returns) and distinguishes itself from sibling tools like 'crypto-fear-greed' or 'crypto-fiat-price' by focusing on market movers and overall regime.

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 advises using this tool 'before any crypto portfolio, trading, or market analysis task to get a current regime read,' providing clear usage context. It does not explicitly list when not to use or alternative tools, but the directive is sufficient for an AI agent to decide.

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?

With no annotations, the description carries full burden. It mentions pure computation, no latency, and 150+ currencies. But it doesn't specify error behavior for invalid inputs or the exact structure of multiple-mode outputs, leaving gaps.

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?

Six sentences, well-structured with purpose first, then use cases. No unnecessary words; 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?

No output schema provided. The description implies return types via examples but does not explicitly define the structure for 'info' and 'both' modes (e.g., whether they return JSON objects). More completeness needed.

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 has 100% parameter descriptions. The description adds value by explaining modes, giving examples, and noting BTC exclusion, which aids 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 it performs locale-aware currency formatting and symbol lookup for ISO 4217 currencies, with examples. It distinguishes itself from other tools by being a pure computation utility.

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 lists explicit use cases like financial report generation and invoice display, and notes it requires no API key. However, it does not mention when not to use it or provide 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?

No annotations are provided, so the description carries full burden. It discloses that the tool is a lookup (implying read-only), returns specific fields (CVSS, attack vector, CWEs, references), and covers 260K+ vulnerabilities. No contradictory or missing behavioral information.

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 covering source, query methods, return data, and scope. Every sentence adds value, and the most important information is front-loaded.

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 simple lookup tool with well-documented schema and no output schema, the description adequately explains return values and usage. The sibling list is large but no confusion, and the tool's purpose is fully covered.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only summarizing query methods and mentioning severity filter. It does not provide additional parameter details.

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

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

The description clearly states it is a CVE vulnerability lookup via NVD NIST, specifying query methods (CVE ID, keyword, severity) and return data. No other sibling tool covers CVEs, so differentiation is clear.

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

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

The description provides clear context on when to use the tool (query by ID, keyword, or severity), but does not explicitly mention when not to use or suggest alternatives. Given no similar CVE tool in siblings, this is acceptable.

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?

No annotations are provided, so the description carries the full burden. It discloses data sources (endoflife.date) and benchmarks (TPC-C, pgbench, etc.), but does not explicitly state that the tool is read-only, side-effect-free, or specify any rate limits or authentication requirements. The behavioral traits are implied but not fully transparent.

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

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

The description is two sentences with no redundancy. It front-loads the purpose and lists databases, then adds use-case context and data sources. 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?

The description is complete for the intended use cases but lacks information about the output format or structure. Since there is no output schema, agents would benefit from knowing what the response looks like (e.g., structured data per database). This gap limits completeness.

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

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

Schema description coverage is 100%; each parameter has a clear description in the schema. The tool description adds little beyond the schema, simply repeating the list of supported databases and include options. The schema already provides sufficient semantic meaning, so the description offers no additional value.

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 database performance intelligence including current versions, EOL status, and benchmark profiles for a specific list of databases. It also mentions use cases like infrastructure audits and database selection, distinguishing it from unrelated sibling 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 clear context for use ('mid-task for infrastructure audits, database selection, and upgrade urgency checks') but does not explicitly state when not to use or mention alternatives. Since sibling tools are mostly unrelated, this context suffices.

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?

No annotations provided, so description carries full burden. Discloses aggregation, ID types, and call limit, but does not mention error behavior, rate limits, or output format. Adequate but not rich.

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

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

Extremely concise: two well-front-loaded sentences. First sentence states purpose and usage, second provides a unique selling point. No redundant or irrelevant 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?

For a simple price lookup tool with no output schema, the description covers key aspects: data source, input formats, and call limit. However, it lacks details on return format (e.g., USD prices) and error handling, which would make it fully 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 coverage is 100% and already describes the single parameter in detail (ID formats, max 10). Description adds no additional meaning beyond the schema, so baseline 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?

Clearly states it returns on-chain aggregated token prices via DefiLlama coins API, specifying the exact resource (token prices) and action (returns). Distinguishes from siblings like defillama-pack and defillama-protocol by focusing specifically on coin prices.

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 clear usage context: accepts multiple ID formats and limits calls to 10 tokens. Mentions cost advantage over blockrun.ai, but lacks explicit guidance on when to use this tool versus other defillama siblings or alternative pricing 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?

With no annotations, the description carries full burden. It discloses zero auth, same upstreams, cost savings, and expected output. No mention of rate limits or error cases, but reasonable for a read-only data aggregation tool.

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

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

Two sentences with no wasted words. Front-loaded with purpose and key differentiators.

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

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

Despite no output schema, the description fully specifies return components (TVL, chain breakdown, fees, price). This is sufficient given the tool's straightforward nature.

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

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

Schema coverage is 100%, and the description adds value by specifying the format (lowercase-hyphenated slugs, max 3) and examples. This complements the schema well.

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 TVL, chain breakdown, fees, and native token price for 1-3 protocols, and explicitly contrasts with sibling tools defillama-protocol and defillama-coin-price, making its purpose distinct.

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 explains this tool collapses a two-call chain at lower cost, guiding when to use it over separate calls. Could be more explicit about when not to use, but the context is clear.

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

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

No annotations provided, so the description must solely disclose behavior. It does not state whether the tool is read-only, has rate limits, requires authentication, or any side effects. Only mentions returns data, which is insufficient for full behavioral disclosure.

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

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

Two sentences with no wasted words. The first sentence front-loads the core action and outputs. The second sentence provides a cost efficiency note that may be relevant but is not verbose.

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

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

For a simple 2-parameter tool with no output schema, the description covers the main return fields (TVL, chain breakdown, changes, fees, metadata). However, 'metadata' is vague and could be expanded. Still adequate given low tool complexity.

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

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

Schema coverage is 100% for both parameters. Description adds formatting guidance (lowercase-hyphenated slug) and clarifies default behavior for include_tvl_history. This extra context moves it above baseline 3.

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

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

The description uses a specific verb ('Returns') and lists exact resources (TVL, chain breakdown, TVL change, fees, metadata) for any protocol slug. It clearly distinguishes from sibling tools like 'defillama-coin-price' by focusing on protocol-level TVL and metadata.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., defi-yields, defi-market-pulse). The cost comparison to blockrun.ai is present but does not help an AI agent decide between siblings. Lacks when-not-to-use or prerequisite info.

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?

Despite no annotations, the description adequately discloses that it is a read operation returning combined data with no destructive effects. Mentions cost savings and the cross-signal layer, but lacks details on real-time vs historical or rate limits.

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

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

Five sentences, front-loading value proposition and cost savings. Could be more structured but is appropriately concise given the tool's complexity.

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?

No output schema, but description outlines the three layers returned (yield pools, market movers, signals). Adequate for understanding the output structure, though more detail on format would be helpful.

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

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

Schema coverage is 100% so baseline is 3. Description adds context about the tool's combined nature and output layers but does not enhance individual parameter meaning 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 that the tool combines DeFi yield intelligence and market momentum, distinguishes from siblings by mentioning cheaper alternative to separate calls, and specifies verb (returns) and resources (yield pools, market movers, cross-signal layer).

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 states use cases: capital allocation decisions, pre-trade context, portfolio rebalancing. Implicitly differentiates from alternatives but does not explicitly state when not to use.

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