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

With no annotations, the description carries the full behavioral burden, and it does add real context by disclosing the backing model (Claude) and per-call pricing ($0.01/$0.02), which affects invocation decisions. It omits auth requirements, rate limits, latency, and failure behavior, so the disclosure is useful but incomplete for a six-parameter 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?

Two dense sentences: the first front-loads the core operation and maps each enum value to its behavior, the second carries cost information. No filler, no repetition, and the highest-value information (what it does, what it costs) comes first.

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 four-mode tool with no output schema, the description sketches returns for each mode (N-sentence summary, translation, label plus confidence score, structured JSON), which is enough to call it correctly. It stops short of fully specifying output shape (e.g., what summarize/translate return) and error behavior, which matters given no output schema exists.

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 every parameter, including the 'classify only'/'extract only' conditionals. The description reinforces the task-to-parameter mapping (N sentences, target language, your labels, JSON Schema) but adds little syntax or constraint detail beyond what the schema provides, matching the baseline 3.

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

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

The description names a specific verb and resource ('Run a Claude-powered text task') and enumerates the four distinct modes with their concrete outputs, so an agent knows exactly what the tool produces. It does not, however, distinguish itself from siblings like verify_fact or search_web, leaving the agent to infer when this generic task runner is the right choice.

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

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

Usage is implied through the per-mode enumeration (use `summarize` for N sentences, `classify` with your labels, etc.), which helps pick a mode but not a tool. There is no guidance on when to prefer this over verify_fact/check_market or on prerequisites such as required inputs per mode beyond what the schema already states.

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 and does reasonably well: it discloses the data source (public RPC, live), that no API key or aggregator is involved, and a concrete cost ($0.005 per check). It does not mention rate limits, latency, failure modes, or the units/precision of gas_price, so it is good 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 tight sentences, front-loaded with the action and scope, then the operational facts (open RPC, no key, price). Every clause earns its place; nothing is padding.

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?

There is no output schema, so the description correctly takes on describing return content for latest_block and naming the gas price metric, plus cost and auth profile. It stops short of specifying units for gas_price, block-height semantics, or error/timeout behavior, which leaves minor gaps for a read 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% and both params are enums, so the baseline is 3. The description goes beyond the schema by spelling out what each metric yields — 'current gas price' for gas_price and 'number, timestamp, hash' for latest_block — which the enum descriptions ('Which on-chain data point to fetch') do not convey.

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

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

States a specific verb (check/read) and resource (live on-chain data) and enumerates the exact metrics (gas_price, latest_block) and chains (Base, Ethereum) it covers. An agent can distinguish it at a glance from siblings like verify_fact, check_market, and search_web, since 'on-chain via RPC' is a distinct domain.

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

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

Usage is implied by 'live on-chain data' and 'Read live via a public RPC endpoint', which tells the agent the tool is for direct chain reads rather than web or market lookups. However there is no explicit when-to-use/when-not statement and no routing to or away from the sibling tools, leaving the boundary with check_market to inference.

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 behavioral burden. It usefully discloses cost asymmetry ($0.005 for prices/TVL/stablecoins/FX vs $0.05 for any yields metric, attributed to live DeFiLlama data), which is real value-add. Beyond pricing it says nothing about rate limits, failure/error behavior, or result shape, so a mutation-and-read mix of behaviors stays undisclosed.

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?

Front-loaded with the verb and the primary payload, then a dense but necessary enumeration of twelve metrics; the closing sentence delivers the parameter convention and pricing without padding. It is long, but for a twelve-metric dispatch tool nearly every clause 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 nine-parameter, no-output-schema tool the description covers metric selection, the metric-to-parameter convention, and pricing. It does not mention pagination/limit behavior or the shape of returned rows, but with no output schema that omission is a minor gap rather than a blocker.

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

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

Schema description coverage is 100% and each parameter's description already scopes it to a metric ('fx_rate only', 'protocol_tvl only', etc.), so the schema does the heavy lifting. The description's metric-to-parameter mapping largely restates that structured data, yielding the baseline 3.

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

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

States a specific verb ('Check') and resource (crypto/DeFi/FX market data point) and enumerates every supported metric with its parameter name, so the agent knows exactly what class of data this returns. It does not, however, differentiate itself from the sibling check_chain, which plausibly overlaps on chain-level TVL, leaving one ambiguity unresolved.

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 final sentence gives invocation guidance ('Give `metric` and whichever of coins/protocol/chain/symbol/pool/base/limit/min_tvl that metric needs'), which tells the agent how to drive the tool but not when to prefer it over check_chain or the other siblings. No when-not conditions or alternatives are named, so usage is implied rather than stated.

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, and it discloses a real behavioral trait the schema cannot express: per-call pricing for each mode ($0.005 / $0.01 / $0.02). That is meaningful cost information an agent can act on. It still omits rate limits, auth requirements, and return-shape behavior, which keeps it from a 5.

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, both front-loaded and dense with useful information; the mode list is the highest-value content and comes first, with pricing relegated to a second sentence. It is slightly run-on, but every clause 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 7-parameter, five-mode tool with no output schema, the description does the essential job of explaining what each mode returns (Markdown, AI answer, extracted JSON, HN stories). It does not differentiate from siblings like verify_fact or check_market, and gives no return-format constraints, but it is complete enough to call correctly.

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

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

Schema description coverage is 100%, so every parameter (url, limit, query, schema, country, num_results) is already documented in the schema, including mode applicability. The description adds no parameter syntax or format detail beyond what the schema provides, so the 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 names a concrete verb ('search or read the live web') and then disambiguates all five modes with a distinct purpose each ('structured Google results', 'semantic/intent search with an AI-generated answer', 'main content as clean Markdown', 'structured data extracted per a JSON Schema', 'top Hacker News stories'). An agent can map a user intent to the correct `mode` value without opening the schema.

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

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

By enumerating each mode's behavior the description implicitly tells the agent which mode to pick for a given intent (e.g. want an AI answer -> search_semantic; want raw page text -> read_page). It does not, however, state any exclusions, prerequisites, or how to choose between overlapping modes like search_google vs search_semantic for plain keyword lookups.

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 carry the behavioral burden. It discloses the cost ($0.005 per check via x402 USDC on Base) and the no-wallet fallback behavior (explains the payment challenge instead of paying), which are crucial operational details 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 front-loaded: it begins with purpose and source types, then explains required parameters, then payment behavior. Every sentence earns its place with no filler.

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

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

For a 3-parameter tool with full schema coverage and no output schema, the description covers purpose, source options, required inputs, and payment behavior. It omits return format and error cases, which are less critical without an output schema but still leave minor gaps.

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 restates that source selects the fact kind and subject is the exact name to check, but it adds no syntax or format details beyond what the schema already 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 states a specific verb ('verify or look up') and resource ('one specific, named fact'), then enumerates five source types. This distinguishes it from broad siblings like search_web and ai_task by scope and fact source, even without naming them.

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

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

It gives clear context: use for one specific named fact from the listed sources, and requires source and subject. It does not explicitly say when to prefer this over search_web or ai_task, nor does it list exclusions.

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