The Stall

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

No annotations provided, so description bears full burden. It discloses data sources, detected threats, and output format (risk score 0-100 with per-flag breakdown), but lacks details on computation, rate limits, auth, or error handling.

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

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

The description is a tight, informative paragraph: purpose, key features, data sources, and supported chains in three sentences. No redundancy or 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?

No output schema exists, but description partially covers return structure (risk score and per-flag breakdown). Missing details on exact output fields, error states, and chain coverage ('and more'). Adequate but not 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 covers 100% with descriptions; description adds no new parameter semantics beyond repeating supported chains. Baseline 3 is appropriate as schema already explains parameters 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's purpose: 'Wallet/address security and reputation check.' It lists specific threat categories (phishing, sanctions, etc.) and data sources, distinguishing it from sibling security tools like sanctions-screening or evm-token-security.

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 quick security checks but does not explicitly state when to use this tool versus siblings like block-intel or wallet-screener. No alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description fully carries the burden. It transparently describes all actions (fetching specific files and headers) and the return values (allowed/blocked status, disallowed paths, etc.). No hidden behaviors or 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 with four sentences, each adding value. The main purpose is front-loaded, followed by specific actions, use case, and return values. 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?

Given the tool's complexity (multi-file fetch and header inspection) and the lack of an output schema, the description adequately covers input and output. Minor omissions like error handling do not significantly detract from 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?

The single parameter 'url' is already well-described in the schema (100% coverage). The description does not add additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: checking website accessibility and agent-friendliness, with specific actions listed (fetching robots.txt, .well-known/ai.txt, sitemap.xml, inspecting HTTP headers). This distinguishes it from sibling tools like http-headers or page-intel.

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

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

The description explicitly mentions when to use: when agents need to decide whether to scrape, crawl, or interact with a domain. It does not explicitly state when not to use or name alternatives, but the context from sibling tool names and the clear use case provides sufficient 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, the description fully carries the burden. It enumerates all return elements (score, tier, sanctions, breakdown, attestations, stats, spending limits) and states the tool is chain-agnostic. 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 moderately lengthy but each sentence adds value. It is structured with a core statement followed by output details and usage context. Could be slightly tighter but effective.

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 all return values and usage context. It provides a complete picture for an agent to understand 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% (one parameter 'address'). The description adds context by repeating the schema's description and clarifying chain-agnostic nature. However, it does not add meaning beyond the schema, meeting the baseline expectation.

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: 'Know Your Agent (KYA) trust score for any EVM wallet.' It details the output (score, tier, breakdown) and distinguishes from siblings by focusing on trust assessment for agents. The verb 'score' and resource 'EVM wallet' are specific.

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

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

The description explicitly says when to use: 'Use before accepting payment from an agent or before dispatching a sub-agent with funds.' It provides clear context but does not mention alternatives or when not to use, which would elevate it to a 5.

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

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

No annotations exist, so the description carries the burden. It discloses that the image URL is hosted for 1 hour, returns a public URL and revised prompt, and specifies output format depending on response_format. It also mentions pricing. However, it does not address auth requirements 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?

The description is concise with several sentences, front-loading the main purpose. It is well-structured but could be slightly more organized (e.g., grouping pricing info). No unnecessary repetition.

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

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

Given the tool's complexity (3 parameters, no output schema), the description explains what is returned (public URL, revised prompt, output format) and provides pricing. It lacks information about whether authentication is needed to access the URL, but overall covers key aspects adequately.

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% for all 3 parameters, providing adequate baseline. The description adds extra context by explaining the default style (vivid), exact pixel dimensions for sizes, and prompt tips. It also mentions response_format (which is not in schema), adding some confusion but also 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?

Clearly states 'Generate an AI image from a text prompt using DALL-E 3', which is a specific verb+resource. Distinguishes from siblings like meme-generator and image-detect by specifying the model (DALL-E 3), supported styles, sizes, and pricing.

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 features but no explicit guidance on when to use this tool vs alternatives. It does not mention when not to use it or suggest any sibling tools for related tasks.

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. The description discloses data freshness (updated hourly) and source (CAMS) but does not clarify geographic scope (US-only vs global) or mention any limitations, rate limits, or authentication needs.

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

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

The description is two sentences, front-loaded with purpose, no fluff, and efficiently conveys key information.

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

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

The description lists return fields, data source, update frequency, and use cases. However, without an output schema, it could be improved by hinting at the response format or units.

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 (lat/lon with examples). The description adds context about what the tool returns but does not add meaning beyond the schema for the parameters themselves.

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 real-time US AQI and pollutant readings for any lat/lon, listing specific pollutants and data source. It distinguishes itself from weather-related siblings by focusing on air quality.

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, etc.) but does not mention when not to use the tool or compare it 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?

Without annotations, the description carries full burden. It discloses data source (Yahoo Finance, free, no API key) and output details. No contradictions; transparency is adequate for a non-destructive 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?

Three well-structured sentences: purpose, output details, and context. Every sentence adds value, front-loaded with main action.

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 all returns: breakdown, score, count, price target range, upside. Also notes US equity scope and free data source. Complete for the tool's complexity.

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

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

Schema covers ticker with description. Description adds that ticker is case-insensitive, providing extra clarity 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 analyst consensus and price targets for US equities, listing specific outputs. It distinguishes itself from siblings by mentioning the 'analyst conviction layer' complementing us-stock-price and equity-technicals.

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?

Context is provided: the tool complements specific siblings and uses free Yahoo Finance data. While it doesn't explicitly state when not to use it, the purpose is clear enough for appropriate selection.

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

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

No annotations are provided, so the description must convey behavioral traits. It implies a read operation ('snapshot') but does not confirm whether it is read-only, mention auth requirements, rate limits, or data freshness. The lack of such details in the description leaves the agent without critical 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?

Two sentences: first lists contents, second explains usage. No extraneous words, front-loaded information, and efficient for agent consumption.

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 covers the main data points. It does not detail return format (e.g., numbers vs percentages), but the listing is sufficient for a snapshot tool. Could be more complete on data structure.

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

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

With zero parameters, schema coverage is 100%. The description adds value by listing the output components (e.g., top protocols, category breakdown) beyond what the empty schema provides. Baseline for 0 params is 4, and the description meets this.

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

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

The description clearly states it provides a Base chain snapshot with specific data points: total TVL, top 10 protocols, category breakdown, 7d trend, and top tokens. It explicitly requires no input, distinguishing it from other crypto tools that may require parameters.

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 specifies usage for pre-trade orientation before DeFi, lending, or liquidity calls on Base. It provides clear context but does not explicitly list cases when not to use it or alternatives, though the specificity to Base chain differentiates it from siblings.

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

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

Although no annotations are provided, the description implies a read-only operation by listing the returned data fields. It does not explicitly state the absence of side effects or mention authentication needs, but the context makes it reasonably clear.

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 the first sentence conveying the core purpose and output, and the second providing input details and a pricing comparison. 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?

The tool has no output schema, so the description compensates by listing output fields. It covers input types and defaults. Minor gap: no mention of error handling or rate limits, but sufficient for a simple block data 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?

With 100% schema description coverage, the description adds significant meaning: it specifies valid block identifiers ('latest', 'safe', 'finalized', numbers) and provides default values for both parameters, going beyond the bare 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 returns block header data and lists specific fields (number, hash, timestamp, etc.). It explicitly names the supported chains (Base, Ethereum, Arbitrum), distinguishing it from chain-specific tools like 'eth-block'.

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 the input types (block tag or number) and provides default values. It also mentions a pricing alternative, but lacks functional guidance on when to use this over sibling tools like 'eth-block' or 'tx-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?

With no annotations provided, the description fully covers behavioral aspects: 'Pure URL parsing — zero external calls' assures safety and speed. It also discloses internal logic like identifying numeric vs named path segments. 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?

Description is two sentences: first sentence states the primary action, second adds detail and use cases. No wasted words, front-loaded with key information.

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

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

For a tool with 2 parameters and no output schema, the description provides a complete picture: it explains inputs, outputs (even without schema), behavior (zero external calls), and appropriate use cases. Nothing essential is missing.

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

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

Schema coverage is 100% but description adds significant value beyond field descriptions: it explains the output structure (domain, path segments, labels, query params, trail string) and the numeric ID identification feature. This helps the agent understand what the tool returns.

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 extracts structured breadcrumb navigation from a URL. It lists exact outputs (domain, path segments, labels, query params, trail string) and identifies a distinguishing feature (numeric IDs vs named segments). This differentiates it from sibling tools like page-links or page-intel.

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 provides explicit use cases: agents processing sitemaps, navigation menus, or understanding page hierarchy. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an 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 the full burden. It discloses that no API key is required and sources are from mempool.space and CoinGecko. However, it does not mention rate limits, caching behavior, or whether the tool modifies any state (it appears read-only). This is adequate but leaves 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?

The description is well-organized, starting with purpose, followed by a list of outputs, then sources, and finally use cases. It is reasonably concise but slightly verbose with the output list. Could be tightened by removing minor redundancies.

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

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

Given the tool's complexity (multiple outputs, 3 optional parameters, no output schema), the description covers outputs, parameters implicitly via schema, sources, and usage. Minor gaps include behavioral details and explicit output schema description, but overall adequate.

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

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

Schema description coverage is 100%, with each parameter having its own description that includes defaults and implications. The tool description does not add additional parameter meaning beyond that, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: providing Bitcoin mining game theory and systems dynamics metrics. It lists specific outputs (selfish-mining threshold, 51% attack cost, etc.) and sources. However, it does not explicitly differentiate from siblings like 'btc-miner-econ' or 'btc-systems-theory', which may overlap.

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: 'miner-incentive analysis, network security assessment, and pre-investment regime detection.' This provides clear context. However, it does not mention when not to use this tool or suggest alternatives, which could be useful given the presence of related siblings.

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

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

No annotations are provided, so the description carries the full burden. It describes what data is returned without side effects, but lacks details on rate limits, error handling, or performance. For a read-only data tool, it is adequate 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?

Two sentences: first sentence states purpose and source, second lists outputs and use cases. Every word earns its place, front-loaded with key info. 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 no output schema, the description enumerates all returned data categories (fees, revenue split, difficulty, pools, mempool) and mentions use cases. It is nearly complete, though it could mention error conditions or data freshness.

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% (the 'include' parameter is described in the schema). The tool description does not repeat or add parameter information, but the schema already provides sufficient meaning. 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 explicitly states it returns Bitcoin mining economics data from mempool.space, listing specific data points (fee rates, miner revenue split, difficulty adjustment, pool concentration, mempool backlog). It clearly 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?

The description provides clear use cases: 'USEFUL for agents reasoning about BTC transaction timing, miner incentive structures, or on-chain network health.' It implies context but does not explicitly compare to alternatives or state when not to use, which is acceptable given the specific domain.

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 of behavioral disclosure. It mentions the data source (mempool.space) and that no API key is required, but does not disclose any side effects, authorization requirements, rate limits, or impact of parameter choices beyond the schema.

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

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

The description is concise yet detailed, listing all seven output lenses in a structured bullet-like format. It is front-loaded with the core purpose, with no redundant 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 one optional parameter and no output schema, the description thoroughly explains what each of the seven lenses returns. It also mentions the data source and complementary tool, making the context relatively complete.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter. The description does not add additional meaning beyond what is in the schema, meeting the baseline for high coverage.

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

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

The description clearly states it performs a seven-lens systems theory analysis of the Bitcoin network, listing all seven output categories. It distinguishes itself from the sibling tool 'btc-game-theory' by noting they pair for full 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?

Explicitly states it pairs with 'btc-game-theory' for comprehensive analysis, providing clear usage context. However, it does not explicitly state when not to use the tool or list alternative tools for specific needs.

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 cover behavioral traits. It adds useful context: data sources (DRPC + DeFiLlama), free usage, no API key required, and supported chains (Ethereum, Base, Polygon, Arbitrum). However, it does not mention rate limits, caching behavior, or what happens on invalid inputs. For a read-only tool, this is adequate but not comprehensive, missing potential warnings about downstream dependencies.

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 long, with the main purpose stated first. It efficiently lists key fields, supported chains, and data sources without redundancy. Every sentence adds unique information, and there is no fluff or repetition of schema details. Excellent balance of completeness and brevity.

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 is provided, but the description lists the return fields for both block and stablecoin data, giving a clear understanding of the output structure. It also covers supported networks and data sources. While it does not explain terms like 'composite alert level' or 'MILD_DEPEG', these are likely domain-specific and acceptable. Overall, it provides sufficient context for an AI agent to effectively invoke and interpret results.

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% (each parameter has a description), so baseline is 3. The description adds extra value by listing the supported networks (Ethereum, Base, Polygon, Arbitrum) which is not in the schema's network parameter description. It also clarifies the behavior of alert_only ('only return stablecoins depegged (MILD_DEPEG or worse)'). This goes beyond the schema's terse description, justifying a higher score.

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 combined result: Ethereum block header and stablecoin depeg status. It specifies the exact fields for both (block fields: number, hash, miner, timestamp, gas_used, tx_count; stablecoin fields: symbol, price, peg_deviation, depeg_status, composite alert level). This directly differentiates it from sibling tools like eth-block and stablecoin-watch, as it collapses a two-hop chain into 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 implies the tool is for when you need both block and stablecoin data, but does not explicitly state when to use it vs. alternatives. It lacks exclusions or conditions like 'use this instead of calling eth-block and stablecoin-watch separately.' The phrase 'collapses the eth-block → stablecoin-watch 2-hop chain' hints at its combined nature, but more direct guidance would improve clarity.

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?

The description states 'Pure math — instant, zero API calls,' which is good transparency for a calculator tool. No annotations provided, so the description carries the burden and adequately discloses the behavior (no side effects, no external calls).

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

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

The description is four sentences, front-loaded with the core purpose, and every sentence contributes meaning without redundancy. Very concise and well-structured.

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

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

All 4 parameters are covered, no required parameters, and no output schema needed. The description explains what is computed and common use cases, making it sufficiently complete for a calculator 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 descriptions for all 4 parameters. The description adds value by mentioning optional wavelength sweep (C-band, L-band, or custom) and implying default values for fiber_length_km and wavelength_nm, which enriches the schema.

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

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

The description states it is a 'Fiber optic chromatic dispersion calculator' and specifies exactly what it computes (dispersion coefficient, accumulated dispersion, dispersion slope) and for which fiber types (SMF-28, NZDSF, etc.). This clearly distinguishes it from the unrelated sibling tools (all financial, crypto, etc.).

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 says 'Useful for optical network design, DWDM link budget, and dispersion compensation planning,' giving clear use cases. However, it does not explicitly state when not to use it or compare alternatives within the same domain (though none exist among siblings).

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

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

With no annotations, the description fully discloses behavior: it accesses CrossRef (free registry), covers 148M+ works, and returns formatted citations and metadata. It implies read-only, safe operation without contradictions.

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

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

Two sentences with no wasted words. The first sentence states core functionality, the second adds scope and use cases. 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?

Given no output schema and simple input, the description covers purpose, scope, and use cases. It lacks details on error handling or rate limits, but is adequate for the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. The description adds value by listing specific format options (BibTeX, APA, MLA, Chicago) beyond the schema's generic description, clarifying the expected input.

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

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

The description clearly states it looks up a paper by DOI and formats citations in specific styles (BibTeX, APA, MLA, Chicago). It distinguishes from sibling 'research-paper-search' by focusing on citation formatting rather than general search.

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: useful for reference lists, literature reviews, and knowledge extraction. However, it lacks explicit guidance on when not to use it (e.g., if a DOI is unknown, use research-paper-search).

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 states it returns data but lacks information on side effects, rate limits, or limitations. The tool is likely read-only, but this is not explicitly stated.

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

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

The description is two sentences: the first states the core action, the second lists outputs and use cases. No wasted words; it is clear and efficiently structured.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description adequately covers inputs, outputs, and use cases. It explains what the tool returns without needing additional context.

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 each parameter described. The description reinforces the keyword parameter with examples (e.g., 'London', 'LHR'), adding marginal value. Baseline is 3 since schema already does most of the work.

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 specifies what is returned (IATA/ICAO codes, coordinates, country, timezone). It uses specific verbs and resources, distinguishing it from siblings like 'geocode' or 'country-info'.

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 travel planning and geographic enrichment but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or sibling comparisons are 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 must disclose behavior fully. It describes the read operation and data source, but does not address rate limits, authentication, data freshness, or potential errors. This is a moderate gap.

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

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

The description is three sentences: purpose, output, use cases. It is well-structured and front-loaded, though the use-case sentence is somewhat generic and could be omitted without loss.

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

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

Given 5 non-required parameters and no output schema, the description covers inputs and outputs well. However, it does not explain default behavior when no parameters are provided, nor error scenarios. Still fairly 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 already describes all 5 parameters with 100% coverage. The description adds value by explaining what returned data (subjects, cover images, etc.) corresponds to each parameter, going beyond schema definitions.

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 looks up books by title, author, or ISBN via Open Library, listing specific output fields (year, subjects, page count, etc.). It effectively distinguishes itself from unrelated 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 use cases like research and recommendation workflows, but does not explicitly state when not to use or provide alternatives. Since no similar sibling exists, it's adequate but lacks 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?

With no annotations provided, the description carries the full burden. It discloses source and cost but lacks details on pagination, default sorting, rate limits, or error handling. The basic read-only behavior is implied, but more specificity would improve transparency.

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

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

The description is concise with three sentences: first states the action, second lists returns, third adds source and cost. No wasted words, front-loaded with key information.

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

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

Given the tool's simplicity (6 defined params, no output schema) and lack of annotations, the description covers purpose, returns, and source adequately. It misses output structure details, but the schema's parameter descriptions and the tool's straightforward nature keep it mostly 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 input schema has 100% parameter description coverage, so the schema already explains each parameter. The description adds no additional parameter meaning beyond summarizing search fields, 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 clearly states the tool searches ClinicalTrials.gov for clinical studies by condition, intervention, or keyword, and lists the return fields. It distinguishes itself from sibling tools by specifying the authoritative NIH source and a cost per 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 provides context by stating the source (NIH) and cost, implying authority and cost-consciousness, but does not explicitly mention when not to use this tool or provide alternatives. The unique purpose among siblings partially compensates.

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 explicitly states 'pure static analysis — no code execution', mentions cost per call, and indicates recommended max code size in schema. It does not cover error handling or rate limits but is sufficiently 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?

Four sentences with no fluff. Front-loaded with main purpose, then supported frameworks, safety note, and output/cost info. Every sentence adds unique 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?

Given complexity and no output schema, the description covers purpose, inputs, output fields, supported frameworks, and safety. It lacks error handling or performance details, but is complete enough for an agent to decide to call.

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 mentions return structure (routes[], exports[], etc.) which provides output context, but adds no new information about parameters beyond what the schema already describes for 'code' and 'detail'.

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

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

The description clearly states it analyzes code snippets to return API surface, listing specific supported frameworks and specifying static analysis. It distinguishes from siblings like code-test-detector which focus on test 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 provides context on when to use (code analysis for API surface) and which frameworks are supported, but lacks explicit exclusions or alternatives. It implies usage for any of the listed frameworks.

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 full burden. It clearly states 'No code execution — pure static analysis', which discloses safety and read-only nature. It also details what is identified (test functions, assertions, etc.) for both modes, providing rich behavioral context.

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

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

The description is three sentences, front-loaded with the main verb, and efficiently covers both modes without redundancy. 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?

For a tool with 3 optional parameters and no output schema, the description is fairly complete. It covers both input modes and what to expect (e.g., 'gives a coverage verdict'). However, it does not describe the return format, which 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 coverage is 100% so baseline is 3. The description adds meaningful context beyond schema: explains the purpose of 'filename' in confirming naming conventions, and describes the 'github_repo' analysis scope. This adds value above 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 uses a specific verb ('Detects') and resource ('testing frameworks and test coverage presence') and clearly distinguishes two usage modes: code snippets and GitHub repos. It is not a tautology and differentiates from 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 explicitly states the two primary use cases (code snippet analysis and GitHub repo analysis), providing clear context for when to use. However, it does not explicitly mention when not to use or provide alternatives, which would improve 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?

The description implies a read-only operation and mentions the free API and cost, but does not explicitly state non-destructive nature or other behavioral traits. No annotations exist to contradict.

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 that front-load purpose, list included data, and mention filtering and cost. 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 sufficiently explains what data the tool returns (price, high/low, range, previous close, exchange, contract name) and how to use it, despite lacking an output schema. No gaps are apparent.

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 rephrases the same filtering options, adding minimal 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?

The description clearly states it returns live price and intraday metrics for major commodity futures, listing specific commodities and metrics. It is distinct from sibling tools which cover stocks, crypto, etc.

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 when to use (to fetch commodity futures data) and how to filter, but does not explicitly state when not to use or provide alternatives among siblings.

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

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

No annotations provided, so the description must convey all behavioral traits. It discloses that it queries SEC EDGAR and optionally analyzes websites, but omits details like external API calls, latency, authentication needs, or side effects.

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

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

The description is three sentences, efficiently conveying purpose, data sources, and optional functionality 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 no output schema, the description mentions a 'structured report with risk flags' but lacks details on report fields. For a complex due diligence tool, slightly more detail 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 coverage is 100% and the description closely mirrors the schema's parameter descriptions. It adds minimal new meaning beyond restating the schema, so 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 performs due diligence on companies using SEC EDGAR and optionally website analysis, returning a structured report with risk flags. It distinguishes itself from siblings like 'company-intel' and 'web-company-intel' by combining SEC data and website signals.

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 the tool is for comprehensive company due diligence using SEC data and optional website checks. It does not explicitly contrast with alternatives, but the context of 'AI-agent due diligence' helps guide 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 discloses the data source (SEC EDGAR public API), cost (free), and currency (always current). However, it doesn't mention rate limits or potential latency.

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 lists outputs, second gives usage context, third notes data source. Every sentence adds value, front-loaded, no redundancy.

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

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

For a single-parameter tool with no output schema, the description fully covers all returned data fields and usage context. No missing critical information.

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 useful nuance beyond schema, such as case-insensitivity and handling of class-suffix tickers like BRK.A being submitted as BRKA.

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 SEC EDGAR due diligence data for US public companies by ticker symbol, listing specific data fields. It distinguishes itself from sibling tools like company-due-diligence and sec-filing-intel by focusing on comprehensive due diligence data including filing history.

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

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

Explicitly states to use before tasks involving US public company identification, regulatory filing assessment, financial analysis, or industry classification. While it doesn't mention alternatives, the guidance is clear and contextual.

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. Describes computation and return of a score, implying read-only behavior, but doesn't explicitly state non-mutation, auth needs, or other constraints. Adequate but 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: first lists return components, second explains use case. No wasted words, front-loaded, 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?

Lists all return components (HHI, payer counts, risk tier) and explains purpose. However, lacks definitions of metrics like HHI or persistence, which may be needed for interpretation. No output schema, but description covers main aspects.

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 provides 100% coverage with descriptions for both parameters (address format, window_days default/max). Description does not add significant new meaning beyond listing return metrics, 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?

Clearly states it returns a concentration-risk score for an x402 pay_to wallet, listing specific metrics (HHI, payer count, top-payer share, persistence, risk tier). Describes agent use case for assessing single-agent dependency, distinguishing it from general wallet 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?

Explicitly states when an agent should use this tool: to assess whether an endpoint is a single-agent dependency before building a workflow. Doesn't mention alternatives or when not to use, but the use case 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?

With no annotations, the description discloses the data source (Quiver Quant), output fields, and cost. It lacks explicit mention of limitations (e.g., data freshness, depth of history) but provides a good overview. The description does not contradict any annotations (none provided), and it adds useful behavioral context.

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

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

The description is four well-structured sentences: purpose, modes, returns, and source/cost. It is front-loaded and avoids redundancy, with each sentence serving a clear role. No extraneous information, making it ideal for quick agent consumption.

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 effectively lists return fields. It explains the two usage modes and provides cost and source. It does not cover error cases or default behaviors beyond the schema, but for a straightforward tool with optional parameters, it is sufficiently 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 covers all 4 parameters with descriptions (100% coverage). The description adds value by explaining the role of ticker (mode switch) and connecting it to performance data. The other parameters (limit, chamber, transaction_type) are left to the schema, which is sufficient. The description goes beyond the schema for the ticker 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 is for US Congressional stock trades from STOCK Act disclosures and explicitly explains two distinct usage modes (with ticker vs. without ticker). It also lists the fields returned, making the purpose unambiguous and distinguishable from sibling tools like insider-trades.

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 outlines two modes: supply a ticker for specific stock trades or omit for market-wide activity. It also mentions cost and no API key required, aiding the agent's decision to use it. While it doesn't explicitly name alternatives, the modes are sufficiently contextualized for the intended 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?

The description discloses the tool fetches 8 FRED signals and uses GPT-4o-mini for LLM synthesis, indicating external calls and processing behavior. Without annotations, it carries the transparency burden well, though it could mention response time or data freshness.

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

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

The description is a single dense paragraph containing all key information. It is concise but could benefit from bullet points or clearer separation of input vs. output. Still, 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?

Given no output schema, the description adequately lists the seven output components (consumer posture, spending regime, etc.) and mentions the narrative and risk. It covers the tool's purpose and output comprehensively.

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?

With zero parameters, the description adds meaning by explaining the data sources and output components. Since schema coverage is 100% and no params exist, a baseline of 4 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 generates an AI-synthesized US consumer health briefing, which is a specific verb+resource combination. It distinguishes from sibling tools like labor-brief and housing-brief by focusing on consumer health using FRED signals.

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 outlines when to use the tool for retail sector exposure, recession probability, and consumer credit risk. It does not explicitly list when not to use it or compare to alternatives, but the specific output context implies 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?

With no annotations, the description must fully disclose behavior. It lists returned fields but does not explain how multiple parameters interact (e.g., if both name and code provided), error handling, or whether partial name searches return multiple matches. This is insufficient for an agent to reliably invoke the 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?

Three sentences, no fluff. First sentence front-loads the action and search methods. Second sentence lists output fields concisely. Third sentence provides 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?

For a simple lookup tool with no output schema, the description adequately covers search options and return fields. However, it omits details on behavior when multiple parameters are supplied, error conditions, or case sensitivity. Still, it is mostly complete 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?

Input schema has 100% coverage with descriptions for all 4 parameters. The description adds no significant meaning beyond what the schema already provides, so 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's purpose: country lookup by name, ISO code, or capital. It lists the returned fields and distinguishes itself from siblings like city-lookup and geocode by focusing on country-level 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 mentions use cases (international business, geographic enrichment, etc.) but does not provide guidance on when to use this tool versus alternatives, nor does it specify when not to use it. Lacks explicit 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 provided, the description carries the full burden of behavioral transparency. It discloses the data source (FRED, free, no API key) and lists returned metrics. However, it lacks information on update frequency, data latency, output format, or error handling, which limits transparency.

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, consisting of two sentences. The first sentence clearly enumerates the tool's outputs, and the second provides a usage context by linking to a sibling tool. There is no redundant or irrelevant information, and the most critical details are 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?

Given the tool's simplicity (zero parameters, no output schema), the description covers key aspects: specific metrics returned, data source, and pairing advice. It lacks details on error cases or data freshness, but overall it is sufficiently complete for a straightforward 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?

The input schema has zero parameters, so the description does not need to add parameter meaning. According to the guidelines, a baseline of 4 is appropriate for tools with no parameters. The description does not mention any parameters, which is consistent and acceptable.

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

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

The description clearly identifies the tool's purpose: returning current US corporate credit spreads from ICE BofA indices via FRED. It lists specific metrics (High Yield OAS, Investment Grade OAS, BBB OAS, HY-IG differential, risk regime) and distinguishes itself from the sibling tool 'treasury-yields' by mentioning they pair together for discount rate construction.

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 states that the tool pairs with 'treasury-yields' for complete fixed-income discount rate construction, providing clear context on when to use it. However, it does not include when-not-to-use scenarios or alternative tools, missing an opportunity for stronger 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 full burden. It discloses update frequency and cost, but does not discuss rate limits, authentication needs, or output format. For a read-only data retrieval tool, this is adequate but not thorough.

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 outputs, no wasted words. Efficiently conveys purpose, data source, and cost.

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 optional param, no output schema), the description covers the main return values and operational details. It could briefly note that the index is for the overall crypto market, but this is implied. Still, it is mostly complete.

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

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

Schema description coverage is 100% for the single parameter 'days'. The description adds context like 'trend and summary' but does not significantly enhance understanding beyond the schema's description of 'History depth for trend and summary (1–30). Default: 7.' 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 provides the Crypto Fear & Greed Index with specific outputs: current score, 7-day trend, 30-day min/max/avg, and trading regime signal. It is distinct from sibling tools like 'crypto-pulse' or 'crypto-news-impact' which focus on different aspects.

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 the data source ('Free alternative.me data updated daily') and cost, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternatives among the many sibling 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?

Without annotations, the description carries the full burden and discloses that it returns current price, 24h percent change, and last updated timestamp. It states the upstream is CoinGecko public API (free, no key). It could mention rate limits or data freshness but 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 concise, consisting of four well-structured sentences. Each sentence adds value: purpose, input details, output details, and use cases. 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 has only 2 parameters and no output schema, the description adequately covers input, output, and use cases. It explains return values (price, 24h change, timestamp) and provides enough context for an agent to select and invoke the tool appropriately.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by providing concrete examples (e.g., bitcoin, btc) and mentioning the default for currencies, which enhances understanding beyond the schema.

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

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

The description clearly states the tool returns cryptocurrency price in any fiat currency, listing specific coin names and currency codes. It distinguishes from sibling tools like 'forex-rates' by focusing on crypto-to-fiat conversion and mentions use cases for Asian/European markets.

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

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

The description provides context on when to use this tool: free, no API key, useful for multi-currency portfolio valuation. However, it does not explicitly mention alternatives or when not to use it, leaving room for improvement.

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 fully bears the burden. It discloses data sources (CoinDesk RSS with 5-min TTL, CoinGecko prices), return limits ('up to 10' but schema allows up to 20, a minor inconsistency), and behavior (enriches articles with asset prices). This is thorough for a read-only tool.

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

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

The description is a single paragraph, well-structured, front-loading the core purpose. It efficiently lists return fields and usage advice 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 no output schema, the description thoroughly explains return fields (title, URL, timestamp, category, sentiment, enriched assets with price change). Parameter count is minimal (1), and the description covers all relevant aspects for a news fetching 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% for the single 'limit' parameter. The description adds context ('up to 10 recent articles') but does not significantly extend beyond the schema's own description. The baseline of 3 is appropriate.

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

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

The description clearly states it provides latest cryptocurrency news headlines with live price correlation, explicitly stating 'Returns up to 10 recent articles' with specific fields. It distinguishes from siblings by positioning itself as the go-to tool for understanding market-driving news, contrasting with other crypto tools like crypto-fear-greed or crypto-pulse.

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 includes direct usage guidance: 'Use before any crypto research, portfolio review, or market sentiment task'. It does not explicitly state when not to use or name 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?

No annotations provided, so description carries full burden. Discloses it's a single call, returns specific data, mentions free upstream sources (DRPC + CoinGecko) and cost ($0.007/call). No destructive implications.

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 well-structured sentences that immediately state purpose, then list return fields. Efficient and 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?

Given no output schema, description details all return fields: block_number, timestamp, gas info, top movers with specific fields. Also covers cost and data sources. Complete for a 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% with clear parameter descriptions. The description adds context about combining block and market data but doesn't provide additional parameter semantics beyond defaults already in 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 the tool returns 'latest Ethereum (or Base) block context plus top crypto gainers and losers' with detailed field listing. Distinct from siblings like 'eth-block' or 'crypto-top-movers' by combining both aspects.

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

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

Provides explicit use cases: 'crypto portfolio context, on-chain/market correlation, or pre-trade situational awareness.' Does not explicitly state when not to use or alternatives, but context is clear.

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

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 stablecoins are excluded from movers ranking, data comes from CoinGecko public API, and refreshes every 1-5 minutes. This is adequate for a read-only market snapshot 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 concise and well-structured, front-loading the core output (top movers, largest coins, global stats) in the first sentence. Every sentence adds value, and there is 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 no output schema, the description covers all necessary return values: top 5 gainers and losers, top 10 largest coins, global market cap, BTC dominance, volume. It also notes stablecoin exclusion and data source/refresh rate. Complete for a zero-parameter 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?

The input schema has no parameters (100% coverage), so baseline is 4. The description adds meaning by detailing what the tool returns without needing any input, which aligns with zero-parameter tools.

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

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

The description clearly states the tool provides a real-time cryptocurrency market snapshot including top gainers, losers, largest coins, and global stats. It uses specific language and distinguishes from siblings by indicating it is for a 'current regime read' before any crypto 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 explicitly says 'Use before any crypto portfolio, trading, or market analysis task to get a current regime read.' This provides clear when-to-use guidance. It does not list alternatives or when-not-to-use, but the context is sufficient.

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 describes the data sources (live EOL from endoflife.date, benchmarks) but does not disclose any side effects, rate limits, or error handling. It is clearly read-only, so no contradiction, but more detail could improve transparency.

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 well-structured sentences: purpose, use cases, and data sources. It is concise without being vague, though it could be slightly more compact. Word choice is efficient.

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

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

Given the simplicity (no required params, no output schema), the description gives enough context about what is returned (versions, EOL, performance profiles). It is complete for its complexity, though a brief note on return format would push it to 5.

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 both parameters are already documented. The description adds context by listing the supported databases and data types, but it does not add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it provides database versions, EOL status, and performance profiles for a specific list of databases. The verb 'provides' is implied, and it distinguishes itself from siblings by covering a unique domain (database performance intelligence).

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 states the tool is useful for infrastructure audits, database selection, and upgrade urgency checks, giving clear context. However, it does not mention when NOT to use it or provide alternative tools, which would make it a 5.

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

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

Discloses data sources (DeFiLlama, crypto/equity markets), cross-signal logic, and cost. No annotations provided, so description carries full burden. Could mention data freshness or rate limits, but is still 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 plus usage statement, front-loaded with key benefits. 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?

Explains returns (yield pools, market movers, cross-signal layer) and includes usage. No output schema, but description partially compensates by naming 'boosted' and 'at_risk' pools. Could elaborate on return structure.

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

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

Schema coverage is 100% with detailed descriptions. The description adds little beyond schema for parameters, so baseline score 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 provides combined DeFi yield intelligence and market momentum, listing specific outputs (yield pools, market movers, cross-signal layer). It distinguishes from siblings by noting cost savings over separate calls.

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, pre-trade context, portfolio rebalancing. Mentions cost savings vs. alternatives. However, lacks explicit 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 must carry the transparency burden. It mentions collapsing a 'seam' and the cost per call, providing some insight into the underlying service, but does not disclose rate limits, latency, or potential error behaviors, leaving gaps for a read-only scanner.

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 succinct and front-loaded with the core purpose, but includes extraneous details like '41 payers' and cost per call that may confuse an AI agent. It earns its place overall but has minor noise.

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 adequately explains return values (token holdings and USD values) and covered assets/chains. It lacks details on pagination, limits, or error handling, but is sufficiently complete for a straightforward portfolio scanner.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining the chains parameter defaults to all four and listing covered assets, which enriches semantic understanding beyond the schema definitions.

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 multi-chain DeFi portfolio scanner that returns token holdings and USD values for any EVM wallet, specifying supported chains (Ethereum, Base, Polygon, Arbitrum) and assets. It effectively differentiates from sibling tools like wallet-balance by its multichain scope and portfolio focus.

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

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

The description implicitly indicates when to use this tool: for a comprehensive multi-chain portfolio snapshot. However, it does not explicitly state when not to use it or list alternative tools for single-chain or simpler balance checks, which would improve 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 carries full burden. It transparently states parallel fetching, free upstreams, no API key, supported chains, and filtering. However, it does not mention response structure, error handling, or potential upstream failures.

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 the main purpose, no redundant information. Efficiently conveys key points: combination, parallel, chains, filters, free access.

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 10 optional parameters and no output schema, the description lacks details on response structure, error handling, and what happens if an upstream fails. For a composite tool, this is a significant gap.

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 individual parameter descriptions. The description adds summary context (e.g., filters) but doesn't significantly enhance individual parameter meaning beyond the schema. Slight improvement from baseline 3 due to clarifying usage of string booleans.

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 combines three resources (Ethereum block header, stablecoin depeg status, top DeFi yield pools) in one call, distinguishing it from siblings like eth-block, stablecoin-watch, and yield-farming-active which each handle only one.

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 use when all three data types are needed and mentions parallel fetching, but lacks explicit guidance on when not to use it or alternatives. It does not state to use specific sibling tools for individual needs.

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 it is a read operation from a public API with no key needed and continuous updates. Describes response content (APY breakdown, TVL, 7-day change, link). Does not mention rate limits or errors, but is transparent enough for a safe read 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?

Concise paragraph of four sentences, front-loaded with purpose, then coverage, filters, and response. No redundant or verbose 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?

Covers purpose, data source, filters, and response fields. Lacks mention of sorting behavior (implied by 'ranked by APY') and any error handling, but is largely complete for a simple data retrieval tool without an output schema.

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

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

Schema coverage is 100%, providing full parameter descriptions. The description reiterates these filters without adding significant new semantics, staying at baseline.

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

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

Description clearly states the tool returns top DeFi yield pools ranked by APY from DeFiLlama, specifying the exact resource and action. It distinguishes from siblings by focusing on yield pool rankings rather than broader DeFi data or yield farming positions.

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?

Describes when to use: to get top yield pools with optional filters. No explicit when-not-to-use or alternatives, but the context of ranking and filters is clear enough for an 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?

No annotations are provided, so the description carries the full burden. It discloses the tool's read-only nature (searching and returning data) and mentions it is free. It does not specify rate limits, auth requirements, or error handling, but the core behavior is transparent enough for an agent to understand it is a query 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 compact paragraph of 4 sentences, each adding value: purpose, scope, return details, and use cases. It is front-loaded with the primary action and avoids redundancy with the schema. 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?

With 4 parameters, no output schema, and no annotations, the description covers the tool's purpose, supported tokens, return data, and use cases. It mentions the underlying source (DexScreener). It could be slightly more explicit about optional parameter effects, but the schema handles that. Overall, it is nearly complete for a 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 description coverage is 100%, so the baseline is 3. The description adds context by listing example chains and the return fields (price, volume, etc.), but the parameter meanings are already fully explained in the schema. The description does not add significant additional semantic detail beyond what the schema provides.

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

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

The description clearly states the tool searches DEX trading pairs by token symbol, name, or contract address across 50+ chains. It specifies the output includes top pairs by liquidity with real-time data. While siblings like dex-trending-pools exist, the description implicitly distinguishes by focusing on search rather than trending.

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: ideal for tracking on-chain trade flow, entry/exit signals, and multi-chain token prices without DEX integrations. It mentions the tool is free via DexScreener. However, it does not explicitly state when not to use it or provide alternatives, but the use-case guidance is sufficient.

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, description must disclose behavior. It reveals it uses Li.Fi aggregator, returns specific data points, and costs $0.012/call. It implies read-only (quote). No destructive behavior stated; could be more explicit about read-only nature, but sufficient.

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 compact: 4 sentences. First sentence states core function, second lists outputs, third gives usage examples, fourth lists chains and cost. No wasted words, well 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?

Given no output schema, description explains return fields (expected output, exchange rate, gas cost, price impact, route). Covers chains and cost. Missing error handling or rate limits, but adequate for a quote 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%, baseline 3. Description adds value by explaining token symbol/address usage and the '!' prefix for wei strings, but schema already describes parameters well. No major additional semantics 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?

Description clearly states it returns a best-route DEX swap quote across 20+ chains via Li.Fi aggregator. It lists specific outputs (expected output, exchange rate, gas cost, etc.) and distinguishes from sibling tools like dex-pair-search (pair search) and dex-trending-pools (trending pools). The verb 'quote' and resource 'DEX swap' are specific.

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

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

Description mentions it works for same-chain and cross-chain swaps, provides example tokens and chains. It implicitly advises using this for quotes before execution, though it doesn't explicitly state when not to use it or mention alternatives like dex-pair-search for finding token addresses.

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 transparency burden. It discloses the tool is free, requires no API key, supports 100+ networks, and returns specific metrics (price, volume, buy/sell counts, buy_pressure_24h_pct). It does not mention rate limits or pagination behavior beyond max page, but overall provides a good understanding of what the tool does and its limitations.

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 6 sentences, front-loaded with the core purpose. It includes all necessary details (timeframes, source, networks, return fields, use cases) without unnecessary repetition. It is efficient and clear, though could benefit from slight restructuring for readability.

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

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

Given no output schema, the description effectively explains the return fields (pool name, price, price change %, volume, buy vs sell counts, buy_pressure_24h_pct). It covers parameters, use cases, and data source. It is complete enough for an agent to understand how and when to use the tool, though more detail on edge cases (e.g., empty results) 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. The description adds value by explaining the buy_pressure_min parameter in context and defining the buy_pressure_24h_pct metric in detail. This goes beyond the schema's parameter descriptions, providing a richer understanding of how to use the filters.

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 trending DEX pools with buy/sell pressure data across multiple timeframes, sourced from GeckoTerminal. It specifies the verb ('provides' implied), the resource (liquidity pools), and the distinct data (buy/sell counts, pressure metric). It distinguishes itself from sibling tools like dex-pair-search by focusing on trending pools and flow 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 explains when to use the tool: 'spotting early momentum', 'identifying which on-chain tokens agents are accumulating', and 'validating signals from price feeds with raw flow data'. It does not explicitly state when not to use it or list alternative tools, but the use cases are clearly defined.

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 returns specific fields and importantly mentions the cost ($0.008/call). This adds value beyond basic read-only behavior. However, it lacks details on rate limits, idempotency, or potential side effects.

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

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

The description is a single sentence that concisely states the purpose, scope, return fields, and cost. No extraneous information. Front-loaded with the most critical 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 no output schema, the description adequately explains the return values by listing the fields. It covers the essential context for a date-range query tool. Could be improved by noting ordering or default limit, but overall 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 input schema has 100% description coverage for all three parameters. The description adds no extra context beyond what the schema already provides (e.g., date format, default values, max days). 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 specifies the tool's purpose: retrieving upcoming dividend ex-dates from NASDAQ for a given date or date range. It identifies the resource (dividends), source (NASDAQ), and scope (all stocks). The list of returned fields distinguishes it from sibling tools like 'dividend-intel'.

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 fetching upcoming dividend ex-dates with a default of today and a range of 1-7 days. However, it does not explicitly state when to use this tool versus alternatives like 'dividend-intel' 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 provided; description covers single-call nature and no API key requirement. However, it omits details on data freshness, rate limits, or what happens with invalid tickers. For a simple data-retrieval tool, this is adequate but not exemplary.

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 with no fluff. Front-loaded with 'Full dividend intelligence' and immediately lists contents. 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?

Given single parameter, 100% schema coverage, no output schema, the description fully explains what the tool does and what data it returns. Covers all necessary context for an AI agent to use it appropriately.

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 for 'ticker' already covers case-insensitivity and examples. Description adds 'any US equity' but doesn't add significant new meaning beyond schema. Schema coverage is 100%, 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?

Description clearly states it provides 'Full dividend intelligence for any US equity' and lists specific data points (yield, frequency, CAGR, history). Distinguishes itself from sibling 'dividend-calendar' by offering comprehensive historical data rather than just upcoming dates.

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 mentions ideal use cases: 'income screening, dividend safety analysis, and yield comparison across a portfolio'. Does not explicitly mention when not to use or alternatives, 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; description partially compensates by noting Cloudflare DoH backend and TXT extraction details, but omits rate limits, caching policy, or response size constraints.

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 main action, no fluff, each sentence adds distinct 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?

Given the tool's simplicity (2 parameters, no output schema), the description is nearly complete: covers purpose, supported records, use cases, and backend. Minor gap on behavioral 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% (both parameters described). Description adds value beyond schema by explaining TXT lookups include email security signals and listing all supported record types.

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 DNS lookups via Cloudflare DoH, lists supported record types (A, AAAA, etc.), and mentions TXT extraction SPF/DMARC/DKIM. This differentiates it from sibling tools like domain-whois or email-verify.

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 enumerates use cases (domain audits, email configuration, CDN checks, infrastructure recon) but does not explicitly state when not to use or name alternatives, leaving slight ambiguity.

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

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

No annotations provided, so description carries full weight. It discloses that processing is local with no LLM calls, chunking at paragraph/sentence boundaries, deterministic IDs, token estimation, and overlap support. This is adequate for understanding 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?

Three sentences with no fluff: first sentence states core function, second lists key actions, third gives usage placement. 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?

Though no output schema, the description explains returns 'ready-to-embed chunks' and lists specific metadata extracted (word count, type, headings). Sufficient for an agent to understand output without excessive detail.

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

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

Schema covers all parameters with descriptions (100% coverage). The tool description adds extra context on chunking boundaries and token estimation method, enhancing 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 prepares documents for QA and RAG pipelines, with specific actions like chunking, ID assignment, token estimation, and metadata extraction. It distinguishes itself from a large set of 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?

Explicitly advises to use 'mid-task' after fetching a document and before querying a vector store. Mentions that it is pure text processing without LLM/API, guiding safe usage. Lacks explicit when-not-to-use scenarios but overall 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, and the description does not disclose behavioral traits such as rate limits, authentication needs, or error handling. It is a read-only lookup, but this is implied rather than stated.

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 short sentences provide all essential information without redundancy. The purpose is front-loaded and 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?

For a one-parameter tool with no output schema, the description covers basic use and data returned. However, it omits details about potential failures, output format, or limitations, which would be helpful for agents.

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 sole parameter 'domain' has a clear description with examples and instruction to strip 'www.' prefix. Schema coverage is 100%, and the description adds valuable context 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 'Domain WHOIS/RDAP lookup' and lists specific data fields returned. It distinguishes from sibling tools like dns-lookup by focusing on registration details.

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: 'domain due diligence, expiry monitoring, and identifying registrar/owner changes.' However, it does not explicitly contrast with similar tools like dns-lookup or ssl-cert.

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 mentions data source ('openFDA — no API key') and input type, but lacks explicit statements about read-only nature, error handling (e.g., unknown drug), or rate limits. Acceptable 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?

Four short sentences, front-loaded with core functionality. Each sentence adds unique information (data types, input, source, use cases). 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?

Describes return data (adverse event summary with top reactions + total count) without output schema. Could mention return format (JSON) or structure, but overall covers key outputs sufficiently for a 2-param 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 both parameters with descriptions (100% coverage). Description adds value by clarifying that drug_name accepts brand or generic, and that query_type defaults to 'label'. This enhances understanding beyond raw schema.

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

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

Description clearly specifies 'FDA drug intelligence' with enumerated data types (labeling, adverse events, recalls) and input format (brand or generic name). It distinguishes from sibling tools like fda-recall-watch and clinical-trials by covering multiple FDA datasets.

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 states it is 'useful for pharmaceutical research, clinical AI, drug safety due diligence,' providing clear context for when to use. It does not explicitly list when not to use or name alternatives, but the use cases adequately guide tool selection.

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

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

Discloses data source (Alpha Vantage 3-month calendar) and cache duration (2 hr), which is useful context beyond the tool's basic function. No annotations to contradict.

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 redundant text. Every phrase 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?

Describes return fields and filtering, but could be slightly stronger on ordering or what happens without a symbol. Still fairly complete given tool 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?

All parameters are already well-described in the input schema (100% coverage). The description adds no new param info beyond confirming 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?

Description clearly states the tool provides upcoming US stock earnings info (report date, EPS estimate, timing) and filtering by ticker or days ahead, distinguishing it from 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?

Implies usage (filter by ticker or days ahead) but does not explicitly state when to use versus alternatives like earnings-surprises or dividend-calendar.

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 mentions the data source (Yahoo Finance) and that no API key is needed, but does not disclose rate limits, data freshness, or the impact of the quarters parameter on output. It lists return fields but could provide more behavioral 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 a single, dense sentence that covers purpose, data points, source, and pairing. It is front-loaded and concise, though could be slightly restructured for readability without losing 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 no output schema, the description adequately lists the seven key data items returned. It also provides context on data source and complementary tools. However, it does not explain the relationship to the quarters parameter or how results are structured.

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 well-described (ticker with examples, quarters with range and default). The description does not add new semantic meaning beyond the schema; it merely lists output fields which are not 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 clearly states the tool provides historical EPS beat/miss data for US equities, listing specific data points (actual EPS, consensus estimate, surprise %, beat rate, estimate revisions, next earnings date). It differentiates from sibling tools by mentioning pairing with analyst-ratings and equity-fundamentals.

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 historical earnings analysis and suggests pairing with analyst-ratings and equity-fundamentals for a complete stack, but lacks explicit when-to-use or when-not-to-use conditions versus alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the API source (USGS FDSN), real-time nature, magnitude thresholds, and that no API key is required. It does not cover rate limits or error handling, but for a read-only tool, the essential behavioral traits are 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 concise sentences: first introduces the tool and source, second details modes, thresholds, and returned data. Every word adds value, no redundancy or filler.

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

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

Given 7 parameters and no output schema, the description is fairly complete. It explains the two modes, default values, and lists returned data fields (magnitude, depth, location, tsunami flag, shake intensity). It does not describe pagination or exact response format but covers the essentials for a 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 is 3. The description adds significant value by explaining the two modes, default magnitude thresholds per mode, radius, and days context. It clarifies which parameters are relevant for each mode, going 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 explicitly states it fetches earthquake data from USGS with two distinct modes: global significant quakes (M5.0+, last 7 days) and location-based quakes (M3.0+, within 500 km). It lists the returned data fields, clearly distinguishing it from potential siblings like 'usgs-earthquake' by specifying thresholds and 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?

The description provides clear guidance on when to use each mode (recent vs location) and default thresholds. However, it does not explicitly mention when not to use this tool or compare it to alternatives like 'usgs-earthquake', which is a sibling tool.

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

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

No annotations provided, so description carries full burden. It discloses source types (BLS live calendar, Fed/BEA/Census static 2026 schedule), time format (ET returns exact dates/times), and market-impact priority. It does not contradict any annotations (none exist). Additional behavioral details like output format or pagination are not covered, but the core behavior is 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 concise sentences: first sentence densely packs the tool's purpose and scope; second sentence provides use-case context. No waste, front-loaded with key information.

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

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

Given zero required parameters, three optional params, and no output schema, the description adequately covers what the tool does and what it returns (schedule with dates, times, priority). It implies output structure but does not explicitly describe the return format (e.g., list of events). Slight gap but still complete enough for most agents.

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 about US macro releases and explains market-impact priority categories (high includes CPI, NFP, etc.), which reinforces schema descriptions but does not add significant new meaning beyond the parameter descriptions already present.

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

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

Description clearly states it provides an upcoming US macro data release schedule with specific indicators (CPI, NFP, FOMC, GDP, PCE, PPI, JOLTS, Retail Sales, Housing Starts, and 20+ more). It uses a specific verb (schedule) and resource (US macro releases), distinguishing it from sibling tools like earnings-calendar or dividend-calendar.

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 it is essential for agents timing trades or building macro-regime signals, providing clear context for use. However, it does not mention when not to use this tool or explicitly name alternatives among siblings.

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

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

No annotations provided, so description carries full burden. It discloses use of external APIs (Kickbox free API, Cloudflare DoH) and explains the verification steps. It also states return values (score and verdict). This is transparent and adds value beyond basic function.

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 concise, with three sentences that front-load the primary purpose and then provide technical details. No redundant 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?

With one parameter, no output schema, and no annotations, the description is nearly complete: it explains the validation process, external dependencies, and output format. Minor improvement could clarify score interpretation, but overall sufficient.

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

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

Schema coverage is 100% for the single parameter 'email' with a good description. The tool description does not add additional parameter-level details beyond the schema. Baseline 3 is appropriate.

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

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

Description clearly states it validates email addresses, checks syntax, detects disposable domains, and verifies DNS MX records. It specifies output: quality score and verdict types. This differentiates it from sibling tools which have different functions.

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 provides explicit use cases (lead qualification, form validation, filter bot signups) but does not mention when to avoid using this tool or suggest alternative tools. Implied usage context is present but no 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 full burden. It discloses the use of GPT-4o-mini for synthesis, lists all signals and outputs, and notes the FRED data is free and no-auth. It does not detail limitations or latency, but the behavior is adequately described.

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

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

The description is two sentences, front-loaded with purpose, and every sentence adds value without redundancy. It is highly concise yet informative.

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 lists all return elements (regime label, risk, implication, narrative length). The tool is simple with one optional parameter, and the description provides sufficient context for an AI agent to understand and invoke it correctly.

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

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

Schema coverage is 100% for the single parameter 'style', and the schema description fully explains its values and defaults. The description does not add further meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it is an AI-synthesized US energy market briefing, lists specific signals and outputs, and distinguishes it from siblings like macro-brief and consumer-brief by emphasizing energy-specific 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 explicitly states the tool is critical for inflation analysis, commodity exposure, and sector rotation, providing clear context for when to use it. However, it does not mention when not to use it or compare to 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 must carry the full disclosure burden. It lists the returned fields (address, ens_primary, avatar_url, etc.) and describes both modes, but does not mention any behavioral aspects such as rate limits, authentication requirements, or potential errors. 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?

Two sentences: first sentence captures the core purpose, second enumerates return fields. No superfluous words. 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?

For a simple single-parameter tool with no output schema, the description fully explains the two use cases and lists all return fields. Covers both forward and reverse resolution completely.

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 the same information as the schema's property description (forward/reverse mode). It does not add significant new meaning beyond what the schema already provides. 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?

Explicitly states the tool resolves ENS names to Ethereum addresses and vice versa, with clear distinction between forward and reverse lookups. This verb+resource description is specific and differentiates from sibling tools like 'dns-lookup' which handles DNS, not ENS.

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?

Describes when to use forward lookup (pass .eth name) and when to use reverse (pass address), but lacks explicit guidance on alternatives or when not to use this tool. Usage context is clear, but no exclusions are mentioned.

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 transparently details the five parallel data sources, the use of GPT-4o-mini for synthesis, the output structure, and cost savings.

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

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

The description is a single dense paragraph that front-loads the purpose. It efficiently lists data layers and output, but could be slightly more structured for readability.

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

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

Given no output schema, the description explains the return value (structured brief with regime label, bull/bear case, etc.) and narrative word counts. It mentions data recency (last 60 days for insider trades), making it complete.

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

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

Schema description coverage is 100%. The description adds context by specifying ticker as US stock symbol, default style as 'standard' (160-word narrative), and 'concise' (90-word summary), supplementing 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 produces an AI-synthesized equity situation brief for any US stock, listing the five data layers and output components. It distinguishes from siblings by explicitly replacing a multi-call chain with a single 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 indicates it replaces a 4-call agent chain, implying efficiency, and notes no API keys required. However, it does not explicitly state when not to use it (e.g., if raw data is preferred).

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 disclosure burden. It mentions cost ($0.015/call) and 'No API key' but omits critical behavioral traits like rate limits, data freshness, error handling for invalid tickers, or whether data is real-time. This lack of safety or mutation information limits agent understanding.

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. The first lists the metrics, the second adds context (raw data for screening/DCF, no API key, cost). Efficient and front-loaded. Every word 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the output contents thoroughly. However, it could be more complete by mentioning the response format (likely JSON), data latency, or behavior on missing data. Slightly lacking for full autonomous 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?

There is only one parameter (ticker) with 100% schema coverage. The description adds meaning by specifying 'US public company' and listing the full set of returned metrics (P/E, margins, etc.), which is not present in the schema property description. This enriches the agent's understanding of what the parameter affects.

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 'provides fundamental valuation metrics' and explicitly lists over a dozen metrics (P/E TTM, forward P/E, etc.), distinguishing it from sibling tools like stock-brief or equity-brief which offer summaries or other data. The phrase 'Any US public company' sets clear scope.

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

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

The description implies usage for valuation screening and DCF inputs but does not explicitly state when to use this tool versus alternatives (e.g., equity-brief, company-intel). No exclusions or when-not-to-use guidance is provided, leaving the agent to infer from 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 provided, so description carries full burden. It discloses free sources, no API keys, and describes output format (composite score, regime label, per-signal breakdown). 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?

Three sentences, each informative: purpose, signal details, usage guidance. No redundant words, well-structured.

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

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

Despite no output schema, the description fully explains inputs (none), signals, output structure, and use cases. Complete for a parameterless 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 exist; baseline is 4. Description adds meaning by explaining the output and signals beyond the empty 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 provides an equity market Fear & Greed composite with four specific signals, and distinguishes itself from the sibling tool market-sentiment (crypto).

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 when to use: before sizing positions, adjusting portfolio risk, or routing capital. Also notes it is distinct from the crypto sentiment tool, providing clear 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 provided, so description must disclose behavior. It mentions data sourced from 1-year Yahoo Finance daily OHLCV, live data, no API key. This adds context beyond a simple return. However, it does not explain error handling (e.g., invalid ticker), rate limits, or whether the consensus signal is always provided. Lacks full transparency for a tool with no 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?

Description is a single dense paragraph listing indicators in a run-on sentence. While informative, it could be more structured (e.g., bullet points) for easier parsing. It front-loads purpose but the list format reduces clarity. Not overly verbose but not optimally 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 no output schema, description does a good job explaining what the output contains (list of indicators, data source, use cases). It covers input, output components, and data origin. However, it omits the exact structure of the output (e.g., nested objects) and potential caveats (e.g., delisted stocks). Still, it is largely complete for an agent to decide if the tool meets its needs.

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 (ticker) with schema description already covering US stock ticker. The tool description repeats 'US stock' but adds examples and case-insensitivity note, which are already in schema. Schema coverage is 100%, so description adds minimal extra value. Baseline 3 is appropriate.

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

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

Description clearly states it returns a complete technical analysis package for any US stock, listing specific indicators (RSI, MACD, Bollinger, SMAs, volume ratio, consensus signal). It explicitly distinguishes from simpler price endpoints, making the tool's purpose highly specific and actionable.

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

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

Description provides explicit use cases: entry/exit signal confirmation, momentum screening, pre-trade context. It contrasts with simple price endpoints, helping agent decide when to use this tool. However, it does not explicitly exclude other technical analysis tools or mention when not to use, leaving some ambiguity among sibling tools like equity-fundamentals or stock-brief.

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 explains the tool returns name, symbol, decimals, total supply (raw + formatted), wallet balance, and allowance. It also notes that no API key is required and supports multiple networks. It does not detail parameter dependencies (e.g., spender requires wallet) but that is covered in the schema. Overall behavior is well communicated.

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 superfluous information. The first sentence states the purpose and outputs, the second provides efficiency context and supported networks. It is front-loaded and 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?

Despite having no output schema, the description enumerates all returned fields (name, symbol, decimals, total supply, wallet balance, allowance) which is sufficient for understanding the tool's behavior. It also covers networks and cost details, making it complete for a tool of this complexity.

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

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 explaining what each parameter corresponds to in the output: 'wallet balance' for wallet, 'allowance' for spender, and supported networks for network. This goes beyond the schema descriptions.

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

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

The description states clearly that the tool provides a complete ERC20 token state including name, symbol, decimals, total supply, wallet balance, and allowance. It distinguishes itself from sibling tools that only offer a subset of these values, such as 'wallet-balance' or 'token-top-holders'.

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 when to use this tool: when a comprehensive token snapshot is needed, and it highlights the cost and efficiency gain over making four separate calls. It mentions supported networks but does not explicitly list cases where a user should use an alternative tool (e.g., if only balance is needed). However, the context is clear enough.

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

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

No annotations are provided, so the description carries full burden. It only mentions cost and a 25-position limit, omitting rate limits, error handling, or data freshness. Minimal behavioral disclosure beyond core functionality.

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 main function, no unnecessary words. Every sentence serves a purpose: output description, data scope, and pricing details.

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 single-parameter tool without output schema, the description adequately explains return data (holdings, weights, sector/cash split). Missing error handling or freshness details, but overall sufficient.

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

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

Schema coverage is 100% (ticker described). The description adds value by noting case-insensitivity, listing example tickers, and summarizing the response structure (positions, weights, breakdown), which enhances understanding.

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 top holdings, sector weights, and asset allocation for US ETFs, with specific examples. It distinguishes itself from siblings like hedge-fund-holdings by focusing on ETFs, but does not explicitly differentiate.

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 cost info but no guidance on when to use this tool versus alternatives, nor conditions or exclusions. Usage is implied as 'for any US ETF', but lacks explicit 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?

With no annotations, the description carries full burden. It discloses return fields, pricing, and supported networks, but lacks details on rate limits, authentication, error handling, or any destructive 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 a single well-structured sentence that efficiently conveys purpose, fields, networks, and pricing. 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 covers the main purpose, all parameters, return fields, and pricing. However, it could mention potential errors or limitations (e.g., max block number, tag restrictions).

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

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

The input schema has 100% description coverage, but the description adds value by explaining parameter defaults (number defaults to latest), enumerating valid tags, and listing supported networks for the network 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 'Returns an Ethereum block header and transaction hashes by block number, hex string, or tag'. It lists specific fields and supported networks, making the purpose unambiguous and distinguishing it from 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 provides clear context on parameters (number types, tags) and supported networks, but does not explicitly mention when to use this tool versus alternatives or any 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?

No annotations are provided, so the description carries full burden. It mentions a limit of 50 log entries and a per-call cost, but does not discuss rate limits, authentication, or what happens on broad queries (e.g., large block ranges). More detail on behavior beyond the basic limits would improve transparency.

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 that front-load the core purpose and key details (filters, limits, chains, pricing). Every sentence provides useful information 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?