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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the upstream sources and the shape of the result (citation counts, reconstructed abstracts, authors, Open-Access PDF links); it stops short of noting limits or rate 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?

Two tight sentences: purpose and sources first, return payload second, with no filler. Every clause carries information an agent can act on.

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

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

For a read-only, two-parameter search tool with full schema coverage and no output schema, the description is largely complete because it enumerates the returned fields. Only minor gaps remain, such as pagination/limit behavior context and any source-selection semantics.

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 (query, limit) are fully documented in the schema itself. The description restates the domain of the query but adds no syntax, format, or filtering nuance beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (queries) and concrete resources (OpenAlex and arXiv for peer-reviewed papers and preprints), plus what it returns. Against siblings like social_search, github_intel, and web_extract, an agent can immediately tell this is the scholarly-literature tool without opening a schema.

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

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

The phrase 'Deep scientific & academic research tool' implies the domain in which to reach for it, but there is no explicit when-to-use versus when-not-to-use guidance and no named alternative among the many sibling search tools. Usage is only implied.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds a cost ($0.10 USDC) and lists components but doesn't disclose rate limits, auth requirements, or output format beyond the high-level composition.

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, efficiently packed sentence that front-loads the core value proposition and lists components. It avoids unnecessary fluff, though the cost mention could be seen as slightly extraneous.

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

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

Given the tool's complexity (4-in-1 aggregation) and lack of an output schema, the description is minimal. It lists components but doesn't explain how results are structured or what an agent should expect to receive, leaving gaps for a tool that combines multiple data sources.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter details (e.g., format expectations or constraints for domain, company, location) 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 what the tool does: a 4-in-1 dossier combining DNS/MX/SaaS tech stack, website extraction, local business contacts, and social mentions. It distinguishes itself from siblings like domain_intel or web_extract by bundling these capabilities, though it doesn't explicitly name alternatives.

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

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

No guidance on when to use this tool versus siblings such as domain_intel, web_extract, or social_search. It implies usage for B2B sales intelligence but lacks explicit conditions or exclusions.

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

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

The description says the tool mints a key and charges $5.00 USDC via x402, which is a monetary, state-changing transaction, while annotations declare readOnlyHint=true and idempotentHint=true. Re-invocation would plausibly charge again and produce a new key, so both hints are contradicted by the described 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 critical facts (what is minted, price, chain, protocol) are front-loaded in the first sentence, and the second sentence adds genuinely useful deployment context. There is slight redundancy between '30-Day Prepaid API Key Pass' and the later 'for 30 days', but nothing is wasted overall.

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 paid onboarding tool with no output schema, the description covers mechanics well but omits what the caller receives and how (is ak_live_... returned inline in the response, or delivered out of band?), what happens on payment failure, and whether repeat calls are billed repeatedly. Those gaps matter for a tool that spends money on every invocation.

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

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

There is only one optional parameter (agent_name) and schema description coverage is 100%, so the schema already fully documents it. The description adds no syntax, format, or effect details for that parameter, which is the expected baseline when the schema does 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?

States a specific verb and resource ('Mint a 30-Day Prepaid API Key Pass'), plus the exact price, currency, chain, and protocol. This is unmistakably the payment/onboarding tool and cannot be confused with any of the read-oriented siblings like social_search or wallet_profiler.

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?

Gives clear context for when this is the right choice: it names the benefit (no per-call x402 signing) and the caller profiles it suits (LangChain, n8n, Make.com, OpenAI Actions, Python/JS bots). It does not explicitly name the alternative (per-call x402 signing, presumably via x402_ping or another sibling) or state a when-not condition, so it lacks true routing guidance.

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so safety is covered. The description adds genuinely new behavioral context beyond them: a $0.05 USDC cost (a payment requirement the agent must account for) and the data sources backing the verdict (GoPlus Security on Base + Ethereum plus a 4-chain RPC footprint).

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, with the screening scope front-loaded and cost stated inline. Dense with value and free of filler, though the first sentence reads as a keyword list rather than flowing prose.

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 read tool with full annotations, the description covers purpose, trigger context, cost, and data provenance. The one gap is that no output schema exists and the description does not hint at what a screening result looks like (e.g., risk verdict format), which an agent would need to interpret the response.

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 address parameter, so the schema already carries the documentation load. The description only adds the scope constraint that the input must be a 0x EVM address, which is already implied by the schema description — 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?

Names a specific verb ('Screens') and resource ('any 0x EVM address') and enumerates the exact check categories (AML, OFAC sanctions, phishing, mixer, malicious counterparty). No sibling tool in the list performs compliance screening, so the agent can place it immediately.

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 the usage context — screening 'before autonomous agents execute transfers' — which tells the agent when this tool fits in a workflow. It stops short of naming alternatives or when-not-to-use conditions, so it is clear context without exclusions.

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

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds real value beyond them: the aggregators queried, the $0.05 USDC cost, the exact calldata fields returned, and the supported chains. It does not mention slippage, latency, or failure modes, keeping it short of 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 dense sentences, front-loaded with the tool's identity and output, with no filler. The parenthetical pricing and chain list are compact. Slightly packed but every clause carries 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?

No output schema exists, and the description compensates by naming the return fields (to, data, value, gasLimit), which is the key information an agent needs. Cost and supported chains are also covered. Missing only secondary details like slippage handling or the difference between quoting and executing.

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 all six parameters including defaults for from_chain/to_chain and enum values. The description adds only the chain list, which duplicates the enum. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Executable DeFi Swap & Cross-Chain Bridge Action Calldata Builder') and names the mechanism (LI.FI and ParaSwap aggregators) plus the exact output payload (to, data, value, gasLimit). This clearly distinguishes it from read-only data siblings like defi_yields or token_alpha.

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 'Action Calldata Builder' framing implies this is the execution-prep step rather than a data lookup, and the named chains give context. However, it never states when to use this versus other DeFi siblings, nor any prerequisites or exclusions. Usage is implied, not specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context the annotations do not: the upstream data source (DeFiLlama), the defaults applied when nothing is supplied (Base, USDC), and the purpose of min_tvl_usd as a 'safety filtering' control. It still says nothing about result ranking, freshness, or failure behavior when no pools match.

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 the action and immediately followed by scope and filters. The lead-in 'DeFi highest APY & yield radar' is mildly promotional and duplicates 'yield' information, but the overall size is appropriate and nothing critical is buried.

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, zero-required-parameter, read-only lookup with a fully documented schema, the description supplies the essentials: what it finds, on which tokens/chains, what the TVL filter is for, and the defaults. With no output schema the description could say more about what a returned 'top pool' record contains (APY field, protocol name), which is the main remaining 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 description coverage is 100% — every parameter already has a description including defaults and ranges — so the baseline is 3. The description echoes the meaningful inputs (token, blockchain, minimum TVL) and frames min_tvl_usd as safety-oriented, but adds no syntax, format, or constraint detail 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?

States a concrete verb and resource: 'Finds top lending and liquidity pools for any token ... filtered by blockchain and minimum TVL', and names the data source (DeFiLlama). An agent can tell what the tool produces. The opening tagline 'DeFi highest APY & yield radar' is marketing framing rather than a distinct capability, and no sibling tool (e.g. token_alpha) is explicitly contrasted.

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 the phrase 'for any token (USDC, ETH, USDT, WBTC) filtered by blockchain and minimum TVL', which suggests when the tool is relevant (searching for yield on a token). However, there is no explicit when-to-use/when-not guidance and no routing to or away from any alternative tool such as token_alpha or prediction_markets.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description usefully adds that the tool reaches out to external infrastructure sources (DNS, RDAP, active subdomain probing), which is meaningful behavioral context. It does not, however, mention rate limits, latency, or partial-failure behavior for lookups across multiple record types.

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?

A single dense sentence with the broad purpose front-loaded and capabilities following. No filler, though the enumeration style trades some scannability for compactness.

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 no output schema, the description compensates reasonably by naming the categories of data returned (DNS records, email provider, tech stack, registration dates, subdomains). For a single-parameter read-only tool with rich annotations, this is nearly complete, missing only guidance on when to select it.

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

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

Schema description coverage is 100% and there is only one parameter, documented in the schema with examples, so baseline is 3. The description does not reference the domain parameter at all, adding no syntax or format guidance 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 names a specific resource (domain infrastructure) and enumerates the concrete operations it performs: DNS record resolution for A/MX/TXT/NS, email provider identification, SaaS stack fingerprinting, RDAP lookups, and subdomain discovery. An agent can distinguish this from siblings like github_intel or security_audit purely from the capability list.

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?

There is no statement of when to use this tool versus the alternatives, no conditions or exclusions, and no routing guidance. The capability list implies its domain of applicability but nothing tells the agent when domain_intel is the right call versus web_extract or security_audit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds real value beyond that: it discloses the underlying read-only RPC mechanism (eth_call / eth_estimateGas), the supported chains, and a concrete per-call cost of $0.005 USDC. It omits rate limits, auth requirements, and return shape, so not 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?

Only two sentences and the purpose is front-loaded, which is good, but the first sentence is a run-on list of five advertised capabilities plus a price tag that reads as marketing copy. It earns its place for discoverability yet is less economical than a clean single-purpose statement.

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

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

For an 8-parameter read-only tool with no output schema, the description covers the mechanism, supported chains, cost, and the multi-function surface (simulate, gas estimate, revert decode, allowance check, proxy detect). An agent has enough to call it correctly; the only gap is that no return-value expectations are set.

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 one of the 8 parameters is already documented in the schema with format and defaults. The description adds no parameter-level syntax or semantics beyond that, making the baseline 3 correct.

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 second sentence gives a concrete verb+resource: 'Simulates any transaction via eth_call & eth_estimateGas' before signing. The opening keyword-stuffed list (Simulator, Gas Estimator, Revert Decoder, Allowance Checker, Proxy Detector) muddles rather than sharpens the single core purpose, but the tool is still clearly distinguishable from siblings like defi_swap_quote or security_audit.

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 phrase 'before signing' implies the usage context (pre-flight validation of a pending tx), but there is no explicit when-to-use vs when-not guidance and no named alternative tools. Usage must be inferred from the purpose statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds mode-dependent behavior (deep metrics + releases vs. ranked growing repos), which is modestly useful, but it discloses nothing about auth requirements, rate limits, or result ordering/timeliness — notable gaps for an open-world GitHub-backed tool.

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

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

Two tight sentences, front-loaded with the tool's domain and then the two input branches. Every clause carries routing information; nothing is redundant or padded.

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 2-parameter, no-output-schema tool, the description covers both invocation modes and hints at the returned content (repository metrics, latest releases, fastest-growing repos). It leaves the shape/number of results and whether limit only applies to topic search unaddressed, but that is a minor gap given the annotations carry the safety 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%: both the 'owner/repo' vs. topic semantics of 'query' and the 1-15 range/default of 'limit' are already documented in the schema. The description echoes the owner/repo syntax without adding format rules or edge cases beyond it, 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?

States a specific verb+resource ('GitHub repository & open-source competitive intelligence') and distinguishes its two operating modes: single-repo deep metrics vs. topic-based discovery. It does not, however, differentiate itself from adjacent siblings like package_audit or security_audit, so an agent must infer that this tool is about growth/release intelligence rather than security or dependency auditing.

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

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

Explicitly tells the agent how to route input: 'Pass owner/repo for deep repository metrics... or a keyword topic to find the fastest-growing repositories.' That resolves the otherwise ambiguous single 'query' parameter. It stops short of stating when to prefer this over sibling tools (package_audit, security_audit, web_extract), so there are no true exclusions.

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

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

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds one genuinely useful behavioral fact the annotations do not: the $0.015 USDC cost, implying a paid call. It says nothing about auth requirements, rate limits, or what a scan returns.

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?

A single sentence with no filler, and the venue coverage and operation are front-loaded. It is dense and slightly marketing-flavored ('Unified', '$0.015 USDC' parenthetical), which keeps it just short of ideal.

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

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

For a read-only, 2-parameter tool with no output schema, the definition covers the domain, venues, and cost. However, it never explains what the arbitrage scan actually returns (spreads, matched markets, venue pairs), which is the key thing an agent needs to interpret results from a tool with no output schema.

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

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

Schema description coverage is 100%, so both 'query' and 'limit' are already documented in the schema (including the example keywords and the 1-25 range). The description does not add any syntax, format, or constraint detail beyond that, 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 specific domain (prediction markets), the three venues it unifies (Kalshi, Polymarket, Manifold), and the operation (cross-venue probability spread / arbitrage scanning). It is clear what the tool does, though it is written as a stacked noun phrase rather than a verb+resource statement and never distinguishes itself from the sibling 'prediction_markets' tool.

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?

There is no when-to-use guidance, no exclusions, and no mention of the obvious alternative 'prediction_markets'. The cost figure ($0.015 USDC) hints at a paid tier but does not tell the agent when this tool is the right choice over siblings like perp_funding_arbitrage or prediction_markets.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds value by disclosing the returned field set (name, phone, website, address, hours, GPS), but says nothing about pagination, rate limits, or how 'limit' interacts with result availability. With annotations carrying the safety burden, a 3 is appropriate.

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

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

Two tight sentences: the first establishes what the tool finds, the second what it returns. No filler, no redundancy, and the core capability is front-loaded.

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

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

With no output schema, the description correctly compensates by enumerating the returned fields, which is the most important missing piece. For a 3-parameter read tool with full annotation coverage, the description is nearly complete; only the usage-routing context is thin.

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

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

Schema description coverage is 100%, so all three parameters (query, location, limit with its 1-25 range and default) are already fully documented in the schema. The description's 'any city worldwide' loosely implies location is broad-scoped, but adds no syntax, format, or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Find local businesses, companies, and places in any city worldwide,' and enumerates the extracted fields. An agent can immediately tell this is a business-directory/lead lookup. It does not, however, name or contrast itself with any sibling (e.g., web_extract or social_search), so it stops short of full sibling differentiation.

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 phrase 'for lead generation and verification' implies the intended use case but gives no explicit when-to-use/when-not-to-use guidance and never mentions an alternative tool. The agent must infer that this is for prospecting rather than general web search, which is a reasonable but unstated 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the external dependency on Google OSV.dev and the specific result categories (vulnerabilities, deprecation status, latest stable version). It does not discuss rate limits or result volume, which keeps it short of 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 tight sentences with no filler; the core capability is front-loaded and the OSV.dev detail follows. 'for coding agents' is slightly redundant framing but costs little.

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 no output schema, the description helpfully enumerates what comes back (vulnerabilities, deprecation, latest stable version), which is exactly what is missing from structured fields. For a read-only scanner with full schema coverage, the definition is nearly self-sufficient, lacking only notes on result limits or upstream availability.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the ecosystem enum. The description confirms the ecosystem set ('npm, PyPI, or Rust crates') and implicitly describes the version parameter ('latest stable version'), adding marginal value over the structured fields rather than new syntax.

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 and resource: it scans open-source packages for CVEs, deprecation, and latest version. It also names the ecosystems and the upstream data source (Google OSV.dev), so the agent knows exactly what it does. It does not distinguish itself from the sibling security_audit tool, leaving an ambiguity an agent must resolve on its own.

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 the phrase 'for coding agents' and by the ecosystems listed, so an agent can infer this is the right tool when checking a dependency. There is no explicit when-to-use/when-not guidance and no mention of how it relates to the similarly named security_audit sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, covering the safety profile. The description adds genuinely useful context the annotations lack: real-time freshness and the $0.008 USDC cost/payment model, plus the specific exchanges (open-world scope). It stops short of explaining payment mechanics or rate limits, so it adds value but not richly.

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?

A single sentence with the core subject front-loaded and no filler sentences. It is dense and slightly keyword-listed, but every clause carries information (exchanges, data classes, price) rather than 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?

With no output schema, the description usefully enumerates what the result covers (arbitrage, APR, open interest, positioning). However, it leaves return structure and the payment/$0.008 USDC workflow unexplained, which matters for a paid tool in a large sibling set. Adequate but with clear 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% – both 'limit' (range and default) and 'symbol' (ticker examples and omission behavior) are fully documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description names a specific resource (perpetual funding-rate arbitrage) and scope (cross-exchange across Hyperliquid and dYdX v4), plus the data classes returned (APR, open interest, crowded positioning). It clearly distinguishes itself from siblings like defi_yields or kalshi_polymarket_arb. It reads as a keyword-stuffed noun phrase rather than a clean verb+resource, which keeps it just under a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many sibling tools (defi_yields, prediction_markets, kalshi_polymarket_arb). The 'radar' framing implies an arbitrage-scanning use case but leaves routing entirely 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the data is live, sourced from two named venues, and expressed as real-money implied probabilities in percent. It stops short of noting refresh cadence or coverage limits per venue.

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?

A single front-loaded sentence that packs verb, data type, sources, and domain coverage with no filler or redundancy. Nothing could be removed 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?

With no output schema, the description usefully states the return units (percent implied probability) and the sources, which is the key missing piece for interpreting results. It could go further by describing result ordering or how multiple markets per query are ranked.

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 (query, limit) are fully documented with examples and bounds in the schema. The description adds no parameter-level detail of its own, which is the expected baseline when the schema does the heavy lifting.

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

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

Specific verb (Query) plus a precisely scoped resource (live prediction market odds & implied probabilities) with named sources (Polymarket, Manifold) and supported domains (crypto, macro, political, tech). No sibling tool covers prediction markets, so it is unambiguously distinguishable.

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

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

The description implies when the tool is useful (any event with market-implied odds) but gives no explicit when-to-use vs. alternatives, no exclusions, and no guidance on how it relates to siblings like domain_intel or social_search. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: the external data sources (GoPlus & DexScreener) and the concrete risk classes evaluated, which tells the agent what kind of signal to expect. It omits rate limits, latency, and whether results are verdicts or raw provider data.

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

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

Two compact sentences, front-loaded with the tool's role and then the two supported target modes with their checks. No filler, no repetition of the title or annotations.

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

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

For a read-only, idempotent audit tool with no output schema, the description covers inputs, data sources, and the risk dimensions being probed. It stops short of describing the shape of the result (risk score vs. raw fields vs. verdict), which an agent deciding whether this output is actionable would benefit from knowing.

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 (target, chain enum with default 'base') are already fully documented in the schema. The description restates the '0x address OR https:// URL' duality without adding format, validation, or chain-selection nuance, 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?

States a specific verb ('Audits') and two clearly bounded resources (0x contracts/tokens, web URLs), and enumerates exactly what is checked for each (honeypot, buy/sell tax, mintable risk, liquidity; phishing, drainers, prompt injection). This is easily separable from siblings like package_audit (packages) and domain_intel (domains).

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?

'Pre-flight security and scam radar for AI agents' frames the context of use (run before trusting/interacting with a target), and the two target types imply which mode applies. However, it never names an alternative tool or states a when-not condition, so routing vs. package_audit/domain_intel/web_extract is left 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond them: no rate-limit blocks, no API keys required, and the return format (structured JSON and LLM-ready Markdown).

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 with zero waste. The core capability and source list are front-loaded, and the return-format/practical-constraint details follow immediately after.

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 3-parameter read tool with annotated safety profile, the description covers purpose, sources, and return format. With no output schema, it compensates by naming the return formats, though it doesn't describe result structure or pagination behavior.

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

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

Schema description coverage is 100%, so all three parameters (limit, query, platform) are already documented in the schema. The description adds no syntax, format, or semantic detail beyond what the schema provides, making the baseline 3 correct.

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 ('Search') and resource ('live social media discussions') and names source platforms (Reddit, HackerNews, tech forums), which implicitly distinguishes it from academic_search and web_extract. It stops short of explicitly routing the agent away from those siblings, so a 4 rather than a 5.

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

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

The phrase 'for any topic, product, or trend' gives implied usage context, but there is no explicit when-to-use vs. when-not, and no alternative tool is named. The agent must infer that academic queries belong to academic_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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that data is real-time and which metrics are computed, but says nothing about latency, rate limits, data freshness, or what a 'no results' case looks like. Useful context, but not rich behavioral disclosure.

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

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

Two sentences, front-loaded with the category ('Real-time crypto & DeFi order-flow intelligence') followed by the metric list. Dense but every clause maps to a real output dimension. Slightly list-heavy, hence not a 5.

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

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

For a read-only analytical tool whose safety profile is fully covered by annotations and whose two params are fully described in the schema, the description supplies the remaining 'what does it return' context. The absence of an output schema means the metric list is doing the explanatory work, and it does so 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%, so both the query formats ('AERO', 'PEPE', '0x...') and the chain enum are already documented in the schema. The description restates the ticker/contract-address input but adds no syntax or behavior beyond that. Baseline 3 applies when the schema carries the load.

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

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

The description pairs a specific verb ('Analyzes') with a well-scoped resource ('buy vs. sell transaction pressure, liquidity depth, volume velocity, FDV, and top DEX pools') for a specific input type ('any token ticker or contract address'). This clearly differentiates it from siblings like defi_yields (yield data) and wallet_profiler (wallet behavior).

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 context is implied by 'Real-time ... order-flow intelligence' and the listed metrics, but there is no explicit when-to-use vs. when-not guidance and no named alternatives among siblings. An agent can infer intent but must decide selection on its own.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds genuinely new behavioral facts: the call costs $0.10 USDC, it fans out to three named third-party providers, and it returns a letter grade rather than raw data. It does not discuss latency, failure modes when a provider is down, or what happens on an unknown token, so it stops short of 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 tightly packed sentences with the value proposition, cost, and the three component signals front-loaded and zero filler. Every clause conveys information an agent does not already have from structured fields.

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 no output schema, the description usefully hints at the return shape (composite A-F grade) and discloses the payment requirement, which an agent needs before calling. It does not describe the full payload (component scores, raw audit fields), leaving a minor 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 description coverage is 100%, so both 'query' and 'chain' are already documented in the schema, including the accepted token-symbol/contract-address formats and the default chain. The description adds nothing about parameter behavior, 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?

States a concrete verb+resource ('Token Due Diligence Report') and enumerates the three specific data sources it fuses: GoPlus honeypot/tax audit, DexScreener order flow and liquidity, and Reddit/HN sentiment. It does not explicitly contrast itself with overlapping siblings like security_audit or token_alpha, which is the only thing keeping it from a 5.

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

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

The description never says when to reach for this composite tool instead of the narrower security_audit or token_alpha siblings, nor does it give any precondition or exclusion. The only context offered is the price, which is not usage guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds one genuinely useful behavioral fact the annotations lack — the $0.008 USDC price — but says nothing about payment/auth mechanics, latency, or snapshot freshness for a live-data call.

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

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

Single sentence, front-loaded with the scope and price before the enumerated payload. The long list of indices is long but earns its place as a de facto return-value spec since no output schema exists.

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 no output schema, the description correctly compensates by enumerating the returned data points, and the single parameter is fully documented in the schema. The only gap is the absence of usage/alternative guidance, which is a usage rather than completeness concern.

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

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

Schema coverage is 100% with a self-explanatory enum (all/tradfi/crypto/defi) and a default documented in the schema. The description does not mention the focus parameter at all, so it adds nothing 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 names a distinct scope (global TradFi, macro, and DeFi capital-flow data) and enumerates the exact data points returned, so an agent can tell it apart from token_alpha or defi_yields at a glance. It is a 'what you get' description rather than a verb+resource statement, but the resource is unambiguous.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The scope phrasing implies 'use when you need macro market data,' but the agent must infer it, and the sibling list (prediction_markets, defi_yields, whale_alpha_radar) is never referenced.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so safety and idempotency are covered externally. The description adds genuine behavioural value by disclosing the live-data nature of the response and the four supported chains. It stops short of noting rate limits or freshness/caching behaviour.

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 with zero filler. The resource and chain scope lead, and the return payload follows immediately, so the most decision-relevant information is front-loaded.

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

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

With no output schema, the description carries the burden of explaining return values and does so exhaustively (balances, nonce, tier classification, contract detection). For a one-parameter, read-only tool of low complexity, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% for the single 'address' parameter, and the schema already specifies the 0x 40-hex EVM format. The description contributes no additional parameter meaning 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 specific verb and resource ('Multi-chain whale & wallet portfolio profiler') and enumerates the exact outputs: USDC/native balances, nonce, wallet tier, and EOA-vs-contract detection. No sibling tool (academic_search, defi_yields, etc.) overlaps this scope, so an agent can route here unambiguously.

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 stated outputs imply the use case (profiling a wallet address for balance and behavioural signals), but there is no explicit when-to-use, when-not-to-use, or named alternative. Chains covered are listed, which is helpful context, but selection guidance is left 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value by disclosing the output format (Markdown) and a non-obvious secondary behavior: automatic scanning for hidden prompt-injection traps. It stops short of saying what happens when a trap is found or whether scanning affects the returned content.

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?

A single front-loaded sentence that states the extraction target first and the security side-benefit second. No filler, no repetition of the tool name, and nothing that could be dropped 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?

With no output schema, the description must convey the return shape, and it does (Markdown, length-bounded by max_length). The one gap is the injection-scanning feature: it is announced but the description never explains how findings surface to the agent, leaving a promised behavior underspecified.

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 url and max_length are already documented with format and range by the schema. The description adds nothing about parameter behavior (e.g., truncation semantics for max_length), 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 gives a specific verb (Extract) and resource (clean, LLM-ready Markdown from any web URL), which is far more informative than a tautology. It does not explicitly distinguish itself from siblings like domain_intel or security_audit, but no sibling competes for generic page fetching, so the purpose is unambiguous.

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

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

Usage is implied by 'any web URL' but there is no explicit when-to-use, when-not-to-use, or alternative routing. An agent can infer this is the general-purpose fetch tool, but nothing tells it when domain_intel or security_audit should be preferred instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description still adds genuinely useful behavior beyond that: an explicit $0.10 USDC price, the exact chain coverage set, and a breakdown of the three processing stages. It omits latency, rate limits, and failure behavior, so not 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?

One compact sentence with a leading label, the paid-price marker front-loaded, and no redundant filler. Every clause adds a distinct fact (cost, scope, chain set, matching logic, output computation).

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 no output schema, the description must convey the deliverable, and it does name the three report components (portfolio profile, matched yield pools, projected annual yield) plus the price. It leaves edge cases unspecified, such as behavior on wallets with no idle stablecoin balance or unlisted chains, so it is strong but not exhaustive for a multi-chain DeFi 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% and the single address parameter is fully documented as a '0x... 40-hex EVM wallet address.' The description adds only that the wallet is profiled across four chains, which is scope rather than parameter semantics. With the schema carrying the load, baseline 3 is appropriate.

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

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

The description states a concrete verb and resource: it profiles a 0x wallet across four named EVM chains, matches idle USDC/ETH against DeFiLlama yield pools, and computes projected annual yield. That is far more specific than a title restatement. However, it never distinguishes itself from close siblings like wallet_profiler and defi_yields, which appear to cover overlapping ground, so it falls short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives. With siblings named wallet_profiler and defi_yields sitting right next to it, the description should say why an agent would pick this bundled report over those narrower tools, and it does not. Usage is only weakly implied by the capability list.

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

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

Annotations already declare the safe read-only, idempotent, open-world profile, so the bar is lower, and the description still adds material facts beyond them: the exact cost ($0.001 USDC), supported protocol versions (v2 and v1), and the target network (Base Mainnet). It stops short of stating wallet/auth prerequisites for paying the fee or what a failed settlement returns.

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?

A single front-loaded sentence that leads with the cost, the most decision-relevant fact, and packs versions, network, and capabilities without filler. Dense but not padded.

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

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

No output schema exists, so the description should say more about what a call returns (echo payload, settlement confirmation, latency figure) and whether the caller must supply an x402-funded wallet. Annotations cover the safety profile, but the payment mechanics needed to invoke it correctly are left implicit.

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 a single optional parameter with 100% schema description coverage, so the schema already defines it. The phrase 'round-trip echo endpoint' reinforces the message parameter's role but adds no format, length, or default guidance 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 names concrete verbs and resources: wallet verification, payment settlement test, latency check, and round-trip echo, on Base Mainnet. It is far more specific than a tautology, though bundling four capabilities into one phrase makes the primary purpose slightly diffuse. No sibling tool overlaps, so sibling differentiation is unnecessary.

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 mention of 'payment settlement test' and 'latency check' implies a diagnostic/verification use case, but there is no explicit statement of when to call it, when not to, or what alternatives exist for the sibling tasks. Usage is inferable rather than stated.

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