agentsvc.io

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

Adds substantial behavior beyond the readOnly/openWorld annotations: billing model ($0.015 USDC via x402, payable in-call), the 'not charged when the page cannot be loaded' guarantee, output shape (A–F grade, impact-sorted violations, statement link), and viewpoint choice. These are exactly the operational traits annotations cannot express.

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 core capability, then layered with scope caveats, output shape, and pricing in a logical order. It is long but nearly every sentence carries distinct information for a paid tool; the enumerated rule list is slightly dense but earns its space.

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 properly describes return values (grade, impact-sorted violations with WCAG criteria, element counts, selectors, fix hints, accessibility-statement link), plus payment mechanics and limitations. An agent has everything needed to call and interpret 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% for both parameters, so the 3 baseline applies. The description restates the mobile viewport (390 px) which the schema already documents as 390x844, and adds only the free-sample example input; it adds marginal 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?

States a specific verb+resource+method: an automated accessibility audit with axe-core covering every WCAG 2.2 A/AA auto-testable rule. It enumerates concrete checks (alt text, labels, contrast, keyboard traps, ARIA, touch targets), which clearly separates it from neighboring tools like site_audit, seo_meta, and domain_compliance.

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 use context through the EAA/BFSG/BaFG regulatory framing and a free-sample invocation example, plus a when-not boundary ('about a third of barriers... a screening, not a certification and not legal advice'). It stops short of naming an explicit alternative tool, so the routing guidance is contextual rather than comparative.

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 annotations only marking it as non-read-only/destructive/open-world, the description carries the load: read mutates state (marks messages read), read retention is 7 days vs. inbox retention 1-365 days, quotas (64 KB, 1000 unread), webhook delivery is HMAC-SHA256 signed, and each call costs $0.003 USDC via x402 with named chains. These are exactly the behaviors annotations cannot express.

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 purpose and account-free framing are front-loaded, and the dense sentence about limits, retention, and pricing is information-rich rather than filler. It is long, but nearly every clause conveys a distinct operational fact, so the length is defensible.

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 14-parameter multi-operation tool with no output schema and no per-op annotations, the description covers operations, auth (secret), limits, webhook signing, and pricing. The only real gap is that it never sketches what read/peek actually return (message shape, pagination via 'after'), which an agent must infer from the 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 79%, so the schema documents most fields already, but the description adds cross-parameter semantics (op defaulting rules, secret from create as ibs_..., address as inbox_...) and a concrete sample input showing real parameter values. It adds value beyond the field-level descriptions rather than merely restating them.

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 resource (a mailbox for AI agents) and enumerates the exact operations (create, send, read, peek, delete) with their artifacts (inbox_... address plus secret). It is unmistakable against every sibling in the list, none of which deals with inter-agent messaging.

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

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

It gives explicit use cases ('hand results from one agent to another, collect job results, or let other agents reach yours') and per-operation guidance (read marks read for job-queue sharing, peek only looks). It does not, however, contrast itself with the nearest conceptual sibling, agent_memory, or state when messaging is the wrong choice.

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

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

Beyond the annotations (destructive, non-idempotent, openWorld), the description discloses pricing and payment mechanism ($0.002 USDC per call via x402, which chains), the store-secret lifecycle, TTL renewal on every write, storage quotas (64 KB/value, 1000 keys, 5 MB/store), and if_version for concurrency. This is far more than the annotations carry.

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?

Dense but front-loaded: purpose and store lifecycle come first, then the op list, then limits and pricing, then a concrete sample call. Every sentence carries information, though the single paragraph is long enough that structure could be tighter.

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 16-param mutation+read tool with no output schema, the description covers operational semantics, quotas, retention, auth/payment requirements, and a runnable example. An agent has everything needed to invoke it correctly on first 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?

With 63% schema coverage and 16 params, the description adds real meaning: it explains each op's behavior (append drops oldest items, incr is atomic, search matches words in keys and values), the set/append value semantics, and the if_version=0 convention. It does not clarify a few params (tag/tags/limit defaults) 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 states a specific verb+resource ('persistent memory for AI agents... store JSON under a key and read it back in a later run') and enumerates all eight operations by name. No sibling tool overlaps this capability, 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?

It gives clear when-to-use context (persist state across runs, share with other agents) and the first-write-creates-a-store workflow with the mem_ secret. It does not name any alternative tool or state when not to use this, but there is no obvious sibling to route against, so context is strong.

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/openWorld/non-destructive, and the description substantially extends them: 38 tools, 12-step and ~90s limits, explicit 'cannot spend money or send anything', 'AI-written, check the sources', and the x402 USDC pricing/payment mechanics with supported chains. This is rich behavioral context an agent cannot get from annotations alone.

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

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

Core purpose and capability list are front-loaded in the first sentence, so it is well-structured despite being long. Pricing, example, and free-sample details are useful but the passage is dense enough that the payment paragraph could be tighter.

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 complex, open-world orchestrator with no output schema, the description covers what it returns (Markdown answer with sources and the tool-call list), its limits, safety profile, cost, and payment path. Nothing an agent needs to invoke it correctly appears to be 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% and both parameters are fully described in the schema, so the baseline is 3. The description adds light framing (the 'Up to 12 steps' cap and the sample max_steps:4), but no syntax or semantic 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 specific verb+resource (hand off a whole research/lookup task) and enumerates the concrete capability envelope (planning, parallel tool calls, Markdown answer with sources). It is clearly distinguishable from the single-purpose siblings like web_search or research_report because it describes orchestrating up to 38 tools across many 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?

Gives concrete use examples (compare two DeFi protocols, check a company and its domain, summarize a week's changes) and a free sample input, which tells the agent when a multi-step task is worth one call. It does not, however, explicitly name the alternatives (e.g. web_search, answer_with_sources, research_report) or state when to prefer those instead, so routing against siblings 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, openWorld, non-destructive), so the bar is lower; the description adds non-obvious behavior beyond structure — the per-call price ($0.0045 USDC via x402 on Base/Solana/Polygon/Arbitrum), that x402 MCP clients auto-pay, and that general-aviation-only closures surface as notices rather than closures. Missing only rate-limit/refresh-cadence detail.

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

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

Front-loads what the tool does, then the parameter branching, then constraints. The pricing and free-sample sentences are useful but lengthen the block; everything still earns its place, though it is denser than strictly needed.

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 return-value burden and does so by naming the status values (normal, delays, disrupted) and event types. Payment and addressability are covered. Only minor gaps remain around freshness/pagination, which are not critical for a single-call status lookup.

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 single param is documented, but the description adds real semantics the schema lacks: codes may be IATA (JFK) or ICAO (KJFK), the list is optional, and omitting it changes the result set entirely rather than just narrowing it. That is meaningful value over the schema text.

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 ('Live US airport disruptions from the FAA National Airspace System status') and enumerates exactly what is returned: ground stops, GDP delays, arrival/departure trends, closures. No aviation sibling exists, so the scope is unambiguous and an agent can tell instantly what this tool covers.

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 branching condition: pass airports for per-airport status, omit them to get all current events, and notes the 'US airports only' constraint. It even supplies a concrete sample input, leaving nothing to inference about when to call and how.

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?

Adds substantial behavior beyond the annotations: exact pricing ($0.008 USDC via x402 on Base/Solana/Polygon/Arbitrum), the answering model (Claude Haiku 5.5), reading only the top 3 pages, a 7-day news window, refusal behavior when sources don't answer, and no-charge on empty results. This is exactly the operational detail annotations cannot convey.

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

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

Front-loads the core purpose and output format before payment and sample details. Although dense, every clause carries decision-relevant information (sources, model, cost, refusal behavior) 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?

With no output schema, the description fully covers the return shape (short answer, numbered [1][2] citations, source list) plus cost, source coverage, freshness window and failure mode. An agent has everything needed to decide and invoke 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 67%. The description enriches the source enum by explaining what each value routes to (auto prefers news for current events, web = Wikipedia), adding meaning beyond the raw enum. The question and language params are already documented in the schema, so it doesn't need to repeat them.

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 ('Ask a question, get a short answer with numbered citations and the source list') and names its exact search backends (Wikipedia, GDELT/HN, top 3 pages, Claude Haiku). The 'Not a general web index' clause distinguishes it from siblings like web_search and news_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?

Gives clear context for choosing a source mode (current events go to news first, web = Wikipedia) and a when-not caveat ('niche or very new topics may have no sources'). It never names an explicit alternative sibling (e.g. web_search) to route away to, so it falls short of a full when/when-not/alternatives 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 readOnly/openWorld/non-destructive, and the description adds substantial non-obvious behavior: audio is deleted after the call, 10-minute and 24 MB limits, default model choice, $0.01 USDC pricing paid in-call via x402 on four chains, and automatic payment by x402 MCP clients. This is exactly the extra operational context annotations cannot carry.

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 core purpose and then built as tight factual sentences covering cost, limits, formats and return shape. It is dense and slightly long, with the pricing/sample sentences leaning promotional, but every sentence carries usable 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?

There is no output schema, and the description compensates by naming the return fields (text, detected language, duration, segments with start/end seconds). Combined with formats, size/time limits, default model behavior and the payment flow, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond it: it enumerates the accepted container formats (mp3, mp4, m4a, wav, ogg, webm, flac) and clarifies the otherwise-unstated mutual exclusivity rule 'Send audio_url or audio_base64' — important because the schema marks zero required parameters.

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

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

States a specific verb and resource ('transcribe a voice note, meeting, podcast or call recording into text') plus concrete scope details (timestamps, ~100 languages, Whisper). It is immediately distinguishable from siblings like tts (opposite direction), ocr (image text) and language_detect (detection only) without opening any schema.

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

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

Gives clear when-to-use context (voice notes, meetings, podcasts, call recordings), the input alternatives (audio_url vs audio_base64, or the OpenAI-compatible HTTP endpoint), and even a runnable free-sample invocation. It never names a sibling tool or states when NOT to use this one, so it stops short of the top band.

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 only cover the safety profile (readOnly, non-destructive, open-world); the description adds genuinely new behavioral facts: the paid model ($0.0025 USDC per call, x402 on Base/Solana/Polygon/Arbitrum), the fact that x402 clients pay automatically, and a free sample input. It also discloses check-digit validation, which determines when a call fails.

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-loads the output format and format list, then use cases, then params, then payment — a sensible order with no filler sentences. It is dense (payment, sample input, and formats in one paragraph) 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?

With no output schema, the description still discloses the return format (PNG base64) and the human-readable-text option. Combined with the disclosed pricing/auth requirement and the complete parameter rundown, an agent has everything needed to call it successfully.

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 only 25% (only 'text' is described), so the description carries real weight: it marks text as required, restates the type default, explains scale's 1-8 range/default of 3, and clarifies include_text means human-readable text under the bars — the one semantic the schema omits entirely. The type list and scale bounds are largely redundant with the schema's enum and min/max.

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 — 'Generate a barcode as PNG (base64)' — and enumerates the 13 supported symbologies, so the agent knows exactly what comes back. It does not, however, distinguish itself from the sibling qr_code tool even though 'qr' is one of its own formats, leaving the agent to infer the 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?

Gives concrete usage context ('labels, shipping, inventory, tickets or invoices') and states that EAN/UPC check digits are validated before generation. It stops short of any exclusion or alternative guidance, so the barcode-vs-qr_code decision is left unstated.

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 readOnly/openWorld safety profile, and the description adds high-value context beyond them: the $0.003 USDC cost, the x402 payment rails (Base, Solana, Polygon, Arbitrum), that compliant clients pay automatically, and a free-sample path. Cost and payment behavior are exactly the operational traits an agent needs and are not derivable from annotations or 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?

Front-loaded with purpose and output fields, then support scope, then pricing, then example. Slightly dense and the pricing sentence could be trimmed, but every sentence carries operational information rather than 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?

With no output schema, the description does the full job: it enumerates return fields (balances, totals, tx count, recent transactions with net amount, confirmations, fee), address compatibility, cost, and a callable example. An agent has everything needed to decide and invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns above that by clarifying what 'Bitcoin address' actually accepts (bc1 SegWit/Taproot, 1, and 3 on mainnet) and demonstrating the params via a worked example with a concrete address and limit=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+resource ('Bitcoin address lookup for agents') and immediately enumerates the returned data (confirmed/pending balance in BTC and USD, total received/sent, tx count, latest transactions). The scope ('Bitcoin mainnet', bc1/1/3 address types) distinguishes it from siblings like btc_tx, evm_balance, or tron_address without the agent 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?

Gives concrete when-to-use cases ('check a payment, a treasury or a counterparty wallet'), which is more than most siblings offer. However, it never names an alternative (e.g., btc_tx for a single transaction or wallet_portfolio for multi-chain) or states when not to use it, so routing still requires 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?

Beyond the read-only/open-world annotations, it discloses the critical hidden behavior: this is a paid call at $0.002 USDC via x402 on four chains, that x402 MCP clients pay automatically, and that an empty input yields a free sample. Cost and payment mechanics are exactly the kind of context annotations cannot convey.

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

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

Front-loaded with the return contents, followed by the call trigger and then payment logistics. Every sentence carries information an agent needs, though the payment/x402 sentence is dense and could be trimmed slightly.

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, but the description compensates by enumerating the returned fields in detail. Combined with the payment disclosure and the free-sample path, an agent has everything needed to decide and invoke correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly signals this by pointing to the empty example input {} as the free sample invocation, leaving no ambiguity about required inputs.

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 the specific resource (Bitcoin fees right now) and enumerates the exact outputs: recommended sat/vB for next block/30min/1hr/economy, USD cost, mempool size, tip height, difficulty adjustment, and BTC price in USD/EUR. It is unmistakably distinct from sibling tools like gas_price (EVM), btc_tx, or crypto_prices.

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

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

Gives an explicit trigger: 'Call before sending a Bitcoin transaction.' It also tells the agent how to get a free sample via the empty example input. It does not name an alternative tool or state when-not to use it, so it stops short of a full 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?

Annotations only cover safety (readOnly/openWorld/non-destructive), and the description adds real behavioral context beyond them: only a salted hash leaves the server, anchoring takes hours, the exact proof format, and the $0.005 USDC x402 payment flow across four chains. This is the kind of detail an agent cannot infer from 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?

Front-loads the core action and price/verification details follow in a logical order; every clause carries information. It is on the long side, but the length is justified by pricing and chain information that the agent needs.

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 fully: it explains what is returned (base64 .ots proof), the verification path, the privacy model, cost and payment rails. Nothing needed 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 coverage is 100%, so the schema already documents all three parameters, and the description largely restates them (text, hash as alternative to text, URL bytes). The free-sample example input adds minor invocation guidance, but nothing materially beyond the schema earns more than 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?

Names a concrete verb (timestamp), the mechanism (OpenTimestamps on Bitcoin), the accepted inputs (text, SHA-256 hash, URL) and the returned artifact (base64 .ots proof). An agent can distinguish it from the verify sibling and from iota_notarize 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?

Explicitly routes the agent to btc-timestamp-verify for the block/proof and lists concrete use cases (contracts, AI outputs, datasets, invoices, web evidence). It lacks an explicit when-not-to-use note (e.g. versus the IOTA notary siblings), 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description goes well beyond them by disclosing that the call reaches out to the calendar servers to upgrade proofs, that it costs $0.003 USDC per call paid in-band via x402 across four chains, and that x402 MCP clients pay automatically. It does not cover failure modes (invalid proof, calendar timeout) or latency, 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?

Purpose, scope, pricing and payment are front-loaded well, but the single paragraph is overloaded and the inline free-sample input dumps roughly 1.5 KB of raw base64 mid-sentence, which dominates the description's length. The example has value as a zero-cost trial, yet its size hurts readability and would be better placed in a structured example field.

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 return-value burden and does so: status (confirmed, pending), block height and time, the upgraded proof, and whether the supplied text, hash or URL matches. Combined with full parameter coverage and the cost/payment disclosure, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds relational meaning the schema lacks: it explains that the optional text/hash/url inputs are used to test whether the caller's content matches the timestamped material, and it embeds a concrete sample input showing the ots_base64 plus text pairing. That clarifies how the optional comparison parameters are meant to be used together.

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 (verify) and resource (an OpenTimestamps proof, .ots as base64) and spells out exactly what the verification entails: upgrading pending proofs from the calendars and checking each Bitcoin attestation against the real block's merkle root. It also names the producing sibling (btc-timestamp) and any ots client, so an agent can place it in the workflow 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?

The description implies the workflow — proofs produced by btc-timestamp or another ots client are verified here — and that pending proofs get upgraded, which tells the agent when this step applies. However, it never states an explicit when-to-use rule, a when-not-to-use rule, or an alternative tool for the same job; the routing is left to inference from the sibling name.

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 readOnly and openWorld, but the description adds crucial behavioral context absent from annotations: pricing ($0.002 USDC per call via x402), automatic payment through supported MCP clients, and a free sample with example input. It doesn't describe rate limits or error cases, but the paid-call mechanics are a significant disclosure beyond structured fields.

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-loads return values and use cases, then pricing and example. It is efficient but slightly long due to the payment and sample details; still, every sentence carries distinct information needed to call the tool correctly.

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-only lookup with no output schema, the description covers what the tool does, what it returns in detail, when to use it, payment mechanics, and a sample input. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, and the schema already defines txid as a 64-hex string. The description only mentions the txid field implicitly through the example, not adding format or validation 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?

States a specific verb+resource (lookup a Bitcoin transaction by txid) and enumerates exactly what data is returned (confirmations, block, fee, RBF, inputs/outputs, USD value). Clearly distinguishes itself from sibling tools like btc_address, evm_tx, or token_simulate.

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 two concrete use cases: 'confirm a payment arrived' and 'check why a transaction is stuck.' It doesn't explicitly say when to use btc_watch (which likely monitors) vs this one, but the context is clear enough for an agent.

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

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), but the description adds substantial context they cannot: the cursor-based incremental-fetch model, what the first call returns, the per-call price, the payment rails (x402/USDC on Base, Solana, Polygon, Arbitrum), and how payment happens automatically.

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 behavior and output, then usage, then cost/payment. Every sentence is informative, though the x402/payment-method detail is verbose and slightly dilutes the core description.

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 return-value burden and does so (direction, net BTC, confirmations, time, balance). It also covers cursor state, pricing, and a free-sample call, leaving nothing essential missing for correct invocation.

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

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

Schema coverage is 67%, so the schema documents address and cursor partially. The description adds real meaning for cursor ('pass it back next time'), clarifying the stateful loop contract beyond the schema's terse 'Cursor from the previous call'. limit remains unexplained, keeping it from a 5.

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 (watch) and resource (a Bitcoin address), and precisely describes the incremental output: only new transactions since the last call, with direction, net BTC, confirmations, time, and balance. This distinguishes it from one-shot siblings like btc_tx and btc_address.

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 concrete intended uses ('deposit detection and treasury or whale watching') and explains the loop/cursor workflow that selects it. It does not explicitly name an alternative or a when-not condition, so it falls just short of 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?

Goes well beyond the readOnly/openWorld/destructive annotations by disclosing that rendering runs in headless Chromium, makes no external requests, returns image_base64 (PNG), and — critically — that it costs $0.009 USDC per call paid via x402 across specific chains. A paid operation with automatic client-side payment is exactly the kind of behavioral trait an agent must know before invoking.

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?

Dense but well front-loaded, leading with the verb/resource and supported types before parameters and payment. The parameter enumeration partly repeats schema data, but given the low schema coverage that repetition earns its place; the payment and sample sentences are pure 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?

With no output schema, the description correctly states the return value (image_base64 PNG), and it covers the nested datasets structure, dimension constraints, background color, rendering environment, and cost model. For a nested-object, parameter-rich, paid tool this 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 only 13%, so the description carries most of the burden and largely succeeds: it clarifies the mutually-exclusive config-vs-shortcut inputs, gives the datasets shape [{label, data}], states the width/height range and defaults, and notes background takes a CSS color (a detail absent from the schema). It doesn't fully document every field, but it compensates substantially for the coverage gap.

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 (Render) and resource (chart to PNG from JSON) and enumerates the exact chart types supported (bar, line, pie, doughnut, scatter, radar, polarArea, bubble), which distinguishes it from siblings like diagram_render. An agent immediately knows what it produces and can compare against the sibling set 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?

Explains the two invocation modes clearly (full Chart.js config vs. the type + labels + datasets shortcut) and gives a concrete free-sample invocation. It does not, however, explicitly state when to prefer this over diagram_render or screenshot, so sibling routing 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 mark it read-only and open-world, but the description adds substantial context they cannot: the 10-citation cap, the price ($0.005 USDC per call via x402 on named chains), auto-payment behavior for x402 clients, and the upstream data sources (Crossref, OpenAlex, DataCite). It also discloses retraction flagging via Retraction Watch.

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?

Purpose and per-citation outputs are front-loaded before pricing, sources and the worked example. The multi-reference free-sample input is verbose relative to the rest, but each sentence carries operational information rather than 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?

With no output schema, the description fully carries the return-value burden, enumerating status, matched record fields (authors, year, venue, DOI, OA link), corrected issues, APA reference and retraction notice date. Nothing an agent needs to call or interpret the result 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 60%, and the description compensates meaningfully: it explains that citations may be reference strings 'in any style', bare DOIs, or {title, authors, year, doi} objects, which goes beyond the schema's terse typing. The single-DOI/title alternatives are only lightly tied to their parameters, keeping it from a 5.

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 ('Verify references') and resource (citations), and enumerates the exact per-citation outputs (status verified/mismatch/uncertain/not_found, matched record, retraction flag). This is clearly distinguished from siblings like paper_search or answer_with_sources, which retrieve or generate rather than validate.

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?

'Verify references before you publish or rely on them' plus 'Built for agents that write reports, papers or answers with sources' gives clear when-to-use context. It does not, however, explicitly name or exclude an alternative sibling tool, so it stops short of the 5-level 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 readOnlyHint/openWorldHint/destructiveHint=false, and the description adds substantial non-obvious behavior on top: a checks map reporting which sections ran, were skipped or failed; partial-success semantics; the $0.03 USDC x402 payment path with supported chains and auto-pay clients; and the 'not charged when nothing is found' rule. This is exactly the operational context an agent needs before invoking a paid multi-source 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?

Front-loaded with purpose, then sources, then use cases, then input rules, then pricing/sample. Dense but each block earns its place; the pricing and free-sample sentences are longer than strictly necessary but they carry decision-relevant information for a paid tool.

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 return-shape burden and does so: key_facts as plain sentences, every section in full, plus a checks map. Input requirements, billing behavior, and failure/no-result semantics are all covered, leaving no material gap for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine cross-parameter constraint absent from the schema: zero parameters are required, yet at least one of name/vat_number/lei/domain must be supplied, and name+domain yields the fullest brief. That routing/combination guidance is real added value beyond the per-field 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?

States a specific verb+resource ('Company check (KYB) and company enrichment in one call') and enumerates exactly what it aggregates: LEI legal entity, VIES VAT, OFAC/EU/UN sanctions, RDAP/email security, tech stack, news. It explicitly contrasts itself with the six sibling tools it replaces, so an agent can distinguish it 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?

Names concrete use cases (supplier/customer onboarding, lead qualification, due diligence, sales research, especially European companies) and explicitly routes against alternatives by noting it is cheaper than calling company-lookup, vat-validate, sanctions-screen, domain-check, tech-stack and news-search one by one. It also states the input precondition (at least one of name/vat_number/lei/domain; name+domain gives the fullest brief) and the no-result billing exception.

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?

Goes well beyond the annotations: discloses that VAT IDs are checked live in EU VIES, that LEI matching only occurs on an exact name match, that JS-rendered sites are handled, that natural-person names are deliberately excluded, and that no charge applies when no imprint is found. The x402 payment mechanics and price are also spelled out, which is essential behavior for a paid 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?

Front-loaded with the core purpose and return fields before moving to use cases and payment logistics. It is long, but nearly every sentence carries information an agent needs (data source, exclusions, pricing, free-sample path); only the domain example is mildly redundant with the schema.

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

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

With no output schema, the description compensates by enumerating the returned fields (legal name, legal form, address, phone, email, register numbers, VAT ID, LEI). Payment, error/charging behavior and coverage limits are all covered, leaving nothing an agent needs before invoking 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 coverage is 100% and the single parameter is fully documented in the schema, so the description's 'Send domain, e.g. zalando.de' largely restates it. The example JSON input adds a little usage clarity but no format or validation detail beyond the schema, matching the baseline for high-coverage schemas.

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 (enrichment) and resource (company from a domain) with a clear geographic scope (DE, AT, CH) and a concrete data source (the Impressum). It enumerates exactly what is returned, which cleanly separates it from siblings like company_lookup, company_brief and kyb_check.

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 explicit use cases (lead enrichment, CRM cleanup, supplier onboarding, KYB), a concrete invocation example, and an input format hint ('Send domain, e.g. zalando.de'). It does not, however, name or exclude the closest siblings (company_lookup, company_brief) or state when a different tool is preferable.

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, openWorld, non-destructive), and the description adds genuinely new behavioral context: a $0.009 USDC per-call price, the x402 payment mechanism, accepted chains, and automatic payment for x402 clients. It does not mention rate limits or latency, but the payment disclosure is substantial value beyond the annotations.

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

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

Front-loads the resource and returned fields, then the two access modes, then params, then payment/sample. Dense but efficient; the pricing and free-sample sentences are long but earn their place for an agent that must decide to pay.

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 by listing the returned fields, and it documents the parameter union ('one required'), covering the main gaps. The main omission is differentiation from lookalike siblings (company_enrich, kyb_check), which an agent choosing between them would want.

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 75%, and the description adds the critical constraint that 'name or lei (one required)' — something the schema does not express (required parameters count is 0). It also restates country (ISO2) and limit (1–20, default 5), though those duplicate the schema's min/max/default.

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 companies worldwide in the Global LEI Index') and enumerates the returned fields (legal name, LEI, jurisdiction, register number, etc.), which distinguishes it from siblings like company_brief, company_enrich, and kyb_check. The two access modes (search vs. fetch) further pin down its 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?

Explains the two usage modes clearly ('Search by name (optionally filtered by country) or fetch one LEI') so the agent knows how to invoke it in either case. However, it never names or contrasts an alternative sibling (e.g. company_enrich, kyb_check), so routing guidance is contextual rather than explicit.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description adds substantial non-obvious behavior: per-call cost ($0.0025 USDC), the x402 payment flow (USDC on Base/Solana/Polygon/Arbitrum, auto-paid by x402 MCP clients), a free sample call, and the exact fields returned per article. This is exactly the extra context annotations cannot carry.

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?

Purpose, ranking logic and output fields are front-loaded, and the pricing/sample details are pushed to the end where they belong. It is dense and every sentence carries information, though the param recap partially duplicates the schema constraints and the payment paragraph could be tighter.

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, and the description fully compensates by listing the return fields (title, source, URL, publish time, 300-char summary, tickers, covering outlets) along with ranking behavior, filtering options, defaults and the payment requirement. An agent has everything needed to call it correctly and understand the cost.

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 only 40% (only coins and query are documented), but the description compensates by enumerating all five params with examples and ranges: coins e.g. ['BTC','ETH'], hours as a 1-168 lookback defaulting to 48, limit 1-50 defaulting to 20, and sources. Much of this restates schema min/max/defaults, so it adds meaning but is not fully additive.

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

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

The description states a specific verb+resource (fetch latest crypto news) and adds real specificity: the named outlets (CoinDesk, Cointelegraph, Decrypt, The Block, Bitcoin Magazine) and the ranking methodology (grouped cross-outlet coverage ranks higher, newer ranks higher). It is clearly distinct from generic siblings like news_search in practice, but it never names or contrasts an alternative sibling explicitly.

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 for use: 'Filter by coins (tickers) or keywords', and supplies a concrete sample call {"coins":["BTC","ETH"],"limit":10} with a note that it is free. However it never states when to prefer this over news_search/news_sentiment or when the tool is not appropriate.

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, destructiveHint=false. The description adds critical non-obvious behavior: a per-call cost ($0.002 USDC) paid via x402 inside the call, which chains/networks are accepted, and that certain MCP clients auto-pay. This pricing/auth context is valuable beyond annotations; free sample call is a nice touch.

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?

Well front-loaded with purpose and modes, but the description is dense and includes a long pricing/payment paragraph and a prosy free-sample sentence. Every part is relevant, yet the pricing detail could be trimmed slightly without losing agent utility.

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, modes, parameter roles, cost model, and payment mechanism. No output schema exists, so the description would ideally describe return values (e.g., shape of price/24h change data), which it doesn't; but for an agent selecting and invoking the tool, the key decisions are covered.

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

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

Schema coverage is 100%, so the schema already documents all four parameters in detail. The description summarizes the params (coins, tokens, currencies default, at) but adds no new semantics beyond what the schema states. Note a minor inconsistency: description says 'up to 50' coins while schema says 'Max 25 coins'.

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 (price and token price lookup) with concrete scope: live spot price and 24h change for tickers, DEX tokens, and historical prices. Clearly distinguishes itself from siblings like defi_tvl, exchange_rates, and token_* tools by focusing on price 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?

Provides clear mode selection guidance (three enumerated modes with examples) so an agent knows how to formulate requests for coins vs tokens vs historical. Does not explicitly name when NOT to use or point to specific sibling alternatives, but the mode structure gives strong usage context.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description goes well beyond them: it discloses the $0.009 USDC per-call price, the x402 payment path and supported chains (Base, Solana, Polygon, Arbitrum), which clients pay automatically, and a free sample input. Cost and auth requirements are exactly the behavioral context an agent needs before invoking, and none of it is inferable from structured fields.

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?

Dense, single-paragraph and parenthetical-heavy, but front-loaded with the core purpose and every clause carries information (return fields, modes, parameters, price, example). The payment/sample details could be split out, but nothing is 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 5-parameter tool with no output schema, the description covers the two invocation modes, the return field groups from both upstream sources, the cost/auth mechanism, and a working example. The remaining gap is that with zero required parameters it does not state that at least one of cve_id or package is effectively mandatory.

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 only 40% (package and version have no schema descriptions at all), so the description has to compensate, and it largely does: it marks version as 'recommended', presents the cve_id-vs-package+ecosystem alternatives, and repeats the limit default. It does not explain the ecosystem value set fully beyond examples, and the listed ecosystems (e.g. Debian) do not exactly match the schema's enum-style list.

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 (look up a vulnerability by CVE/GHSA id, or check a package version) and even enumerates what each data source returns (NVD: CVSS/CWE/CISA flag; OSV: affected packages/fixed versions). It is clear and self-contained, but it never distinguishes itself from the sibling package_check, which plausibly overlaps with the package-version mode.

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 two usage modes and how to select between them (cve_id, or package + ecosystem with version recommended), which is useful implied guidance. But it never says when to prefer this tool over sibling alternatives such as package_check, nor any exclusions or prerequisites beyond the payment requirement.

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 readOnly/openWorld/non-destructive, but the description adds critical non-annotation behavior: a $0.002 USDC per-call cost, the x402 payment rails (Base, Solana, Polygon, Arbitrum), and that x402 MCP clients pay automatically. That payment disclosure is exactly the kind of context annotations cannot express. It stops at 4 because error/rate-limit behavior and failure modes are not addressed.

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 mode breakdown, then params, then pricing, and the free-sample call at the end is a practical touch. It is a dense single block rather than bulleted, which slightly hurts scannability, but every sentence 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?

With no output schema, the description correctly picks up the burden by describing what each mode returns (TVL plus 1d/7d change, category, market cap, chain breakdown; volume windows and top DEXes). Combined with full param coverage and payment details, an agent has enough to call it correctly.

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

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

With only 60% schema coverage, the description compensates well: it explains all four mode values, gives concrete examples for protocol ('aave, uniswap, lido'), category, and chain, restates the limit range, and clarifies the non-obvious default logic. It adds real meaning beyond the enum-only schema for mode.

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 ('DeFi data from DefiLlama') and enumerates the four distinct data products (protocol TVL, top protocols, chain rankings, DEX volume), so an agent knows exactly what it returns. It does not, however, name or contrast with the closest sibling defi_yields, 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?

Each mode is given a use case and example filters ('category (e.g. Lending, Dexs...)', 'optionally for one chain'), and the default-selection rule ('default top, or protocol if protocol is given') tells the agent how to invoke it without specifying mode. There is no explicit when-not-to-use or pointer to a sibling like defi_yields.

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?

Goes well beyond the annotations (readOnly/openWorld/destructive already covered) by disclosing the paid-call model: $0.0055 USDC per call via x402, accepted chains, and that compliant clients pay automatically. It also discloses outlier exclusion behavior and offers a free sample invocation. This is exactly the auth/payment and data-filtering context annotations cannot carry.

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 purpose and dense but largely non-wasteful, with each clause adding a filter, default, or behavioral rule. It is somewhat run-on across three long sentences, but the information density is justified by the payment model and eight parameters.

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 fully carries the return-value burden by enumerating the fields returned (APY split, 30-day mean, 7-day change, TVL, stablecoin flag, IL risk). Combined with filter/sort semantics, outlier handling, and payment info, an agent has everything needed to invoke and interpret the 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?

With schema coverage at only 38% across 8 params, the description compensates by illustrating chain, project, and symbol values and restating the min_tvl_usd and sort defaults. It adds interpretive meaning tbut much of the default/enum information is already present in the schema, so the marginal value is real but partly redundant; limit's ceiling is left to 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 specific verb and resource ('Find DeFi yield pools') with scope (400+ protocols, 100+ chains) and the data source (DefiLlama). An agent can immediately distinguish this from the sibling defi_tvl, which covers TVL rather than yield/APY data. The enumerated return fields (base/reward APY, 30-day mean, 7-day change, TVL, stablecoin flag, IL risk) further pin down what the tool produces.

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 practical context for use: which filters exist, their defaults (min_tvl_usd 1,000,000, sort 'apy'), and the outlier exclusion rule. However, it never names an alternative tool or states when NOT to use this one (e.g. the sibling defi_tvl for pure TVL queries), so routing guidance is implied rather than explicit.

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

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

Goes well beyond the readOnly/openWorld/non-destructive annotations by disclosing per-source result lists, partial-failure semantics (a rate-limited source reports an error without failing the whole call), and the payment model ($0.0045 USDC via x402 on specific chains). These are exactly the operational facts an agent needs before calling.

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-loads the core purpose, then behavior, params, and price in a logical order; each sentence adds real value. It is somewhat dense with payment and sample details, but nothing is clearly wasteful.

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

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

No output schema exists, so the description must convey returns, and it does so at a high level ('each source returns its own list'). Combined with the annotations and full parameter documentation, this is nearly complete, though the exact return fields per source remain unspecified.

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 0% schema description coverage, the description carries the full burden and does so: query is required, sources defaults to all five values (matching the enum), and limit is constrained to 1-20 with default 5. All three parameters are given meaning beyond their bare JSON 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?

States a specific verb and resource (search developer sources) and enumerates the five concrete sources with their distinct behaviors (GitHub by stars, npm with weekly downloads, PyPI exact lookup). This clearly distinguishes it from siblings like web_search, news_search, package_check and tech_stack.

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?

Frames the tool as a one-call aggregator across developer sources, which gives clear context for when to reach for it. It stops short of explicitly naming when NOT to use it or pointing to alternatives such as package_check for single-registry 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?

Annotations (readOnlyHint, destructiveHint=false, openWorldHint) cover the safety profile, and the description goes well beyond them by disclosing error behavior (HTTP 400, not charged on failure), pricing ($0.01 USDC), the x402 payment flow, accepted chains, and client behavior. This is rich behavioral context an agent needs before calling a paid, open-world 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?

Front-loads the core action and diagram types first, then error/payment/param details, and every sentence adds real value. It is somewhat dense with pricing and sample content, but nothing is gratuitous.

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

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

For a 5-param, no-output-schema tool with low schema coverage, the description supplies the missing parameter meaning, error semantics and cost model, so an agent has enough to invoke it correctly. Minor gaps are the unexplained 'background' param and the absence of an explicit return-shape statement beyond the sample's 'JSON result'.

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 only 20% (only 'code' is documented in-schema), so the description carries the burden and mostly succeeds: it explains code, format (svg/png/both), theme values, width range (200-4000, default 1200) and background. 'background' is listed but not explained, leaving a small gap.

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 ('Render Mermaid diagram code to SVG and/or PNG') and enumerates the supported diagram types, which clearly distinguishes it from the sibling chart_render. An agent can immediately tell what this produces 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?

Gives clear operational context: invalid syntax returns 400 with the parse error (not charged), so the agent can fix and retry, plus a free sample call. It doesn't name when to prefer an alternative sibling (e.g. chart_render) or exclusions, so it falls short of the 5 bar.

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?

Goes well beyond the readOnly/openWorld annotations: discloses output shape (title, snippet, linked URL, author, points, comments, up to 5 top comments), summary fields, failure semantics ('a source that is down reports an error without failing the call'), pricing ($0.006 USDC, x402, pay-automatic), and the free-sample path. With no output schema, this carries the full burden and does so thoroughly.

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-loads purpose then output shape, then a dense parenthetical of param defaults and pricing. Mostly earns its sentences, but the pricing/x402/sample block is long and could be tightened; the parenthetical param list duplicates schema defaults somewhat.

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-param, multi-source read tool with no output schema and an open-world, additional-payment profile, the description supplies output structure, partial-failure behavior, cost model, and a worked example. An agent can decide whether to call and invoke it correctly without opening the schema for most decisions.

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 only 43%, so description must compensate – and it does for most params (query-or-url requirement, sources default/list, sort default, days range 1-3650, limit 1-20 default 5, comments 0-5 default 2). It explicitly states query/url are 'one required.' Minor gap: sources values and enum semantics are left entirely to the schema, and the mutual-exclusivity of query vs url could be stated more firmly.

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 out what people say about a topic or link'), names the exact sources (HN, Bluesky, Lemmy), and explicitly distinguishes itself from absent siblings like news_search and web_search by naming what is NOT included (Reddit and X). The URL-based 'find every thread that shared that link' use case is concrete and agent-recognizable.

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

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

Explicit when-to-use guidance is embedded throughout – 'useful for product launches, articles and competitors' for the URL mode, plus a clear exclusion of Reddit and X. The free sample input is a practical usage pointer. The alternative-vs-sibling routing is implied by the source scoping rather than by naming a sibling, but it is unambiguous.

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, openWorld, non-destructive), yet the description adds substantial context they cannot: the per-call price, the x402 payment path (USDC on Base/Solana/Polygon/Arbitrum), and a free sample input. Payment/auth mechanics are exactly the kind of non-destructive behavioral detail that adds value; only edge behavior on payment failure or rate limits is unstated.

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-loads what the tool does and the supported types before the usage, pricing, and sample sections. Dense and mostly waste-free, though the payment and free-sample sentences make it longer than a purely functional definition would need to be.

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, and the description compensates by stating the return shape ('records object with array per type'). Combined with the default behavior and supported types, an agent has everything needed to call and interpret this 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 'domain' and 'types' are already fully documented, including the ["A"] default and supported enum values. The description largely restates these; the only marginal addition is the example object, which is illustrative rather than semantic. 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 ('Resolve DNS records for any domain') and enumerates the supported record types. This clearly separates it from neighbors like whois, domain_check, and ssl_check without needing to open 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?

Gives concrete when-to-use scenarios mapped to record types: MX for mail setup, TXT for ownership, general use for propagation debugging. It stops short of naming an alternative sibling tool or stating when NOT to use it, so it does not reach 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?

With annotations already covering the safety profile (readOnly/openWorld/non-destructive), the description still adds substantial behavioral context: 10 MB input limit, text outputs returned as content vs. binary outputs as file_base64, the explicit limitation that local includes and remote images are not loaded, and per-call pricing ($0.01 USDC via x402 on four chains).

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 core purpose and formats, then the input/output mechanics and constraints. The pricing sentence and inline sample add length but are genuinely useful; the run-on paragraph could be broken up but there is little pure 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 stateless conversion tool with no output schema, the description covers inputs, output encoding, detection behavior, limitations and billing — everything an agent needs to invoke it correctly and predict the response shape.

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 67%, and the description compensates by mapping each input channel (content text, file_base64 binary, url), restating 'to' as required, and clarifying auto-detection of 'from'. It also adds the 10 MB size cap for file_base64 that the schema does not state, though it does not explain the 'title' 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?

States a specific verb ('Convert documents between formats') and the exact resource, enumerating the supported formats (Markdown, HTML, DOCX, ODT, EPUB, RST, LaTeX, RTF, plain, PDF). This specificity makes it clearly distinguishable from siblings like doc_parse, pdf_extract and html_to_pdf.

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 explains the three input modes (content / file_base64 / url), that 'from' is auto-detected when omitted, and includes a concrete sample call. However, it never states when to pick doc_convert over close alternatives such as doc_parse, pdf_extract or html_to_pdf, so 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 already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: per-call pricing ($0.009 USDC), the x402 payment mechanism and supported chains, a 10 MB size cap, char-range limits, and which clients pay automatically. This is exactly the extra behavioral context annotations cannot carry.

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 purpose and format scope, then the routing rule, then params, pricing, and a sample. Dense but almost every clause carries decision-relevant information; the free-sample sentence is arguably promotional but does help an agent test the tool.

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 fully specifies the return shape (title, author, date, language, word count, heading outline, table/image counts, Markdown) and covers payment prerequisites. Only the undefined 'from' parameter keeps it from being complete.

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

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

Schema coverage is only 20%, so the description compensates by explaining the one-of constraint across file_base64/url/content ('one required'), marking 'from' optional, and restating max_chars bounds and default. The 'from' parameter's meaning is still left unexplained, which is the only gap.

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 ('turn a document into clean, agent-ready Markdown'), enumerates supported formats, and names the return payload. It actively differentiates from siblings by routing PDF to pdf-extract and declaring PPTX/XLSX unsupported.

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

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

Explicit when-not guidance ('For PDF use pdf-extract; PPTX and XLSX are not supported') plus a one-of input rule and a concrete example invocation. It stops short of mentioning the close sibling doc_convert, which an agent could confuse with parsing.

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 (readOnly, openWorld, non-destructive), and the description adds substantial context they don't carry: a per-call charge of $0.009 USDC via x402, which networks are supported, that x402 MCP clients pay automatically, a DNS fallback for TLDs lacking RDAP, and a free sample call. The payment requirement materially changes how the tool is invoked, which is exactly the disclosure that matters here.

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

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

The description is front-loaded with the scope of the check and then the payment logistics, and every clause carries information. The opening sentence is dense and long, but nothing is padding; the price and sample details earn their space for a paid tool.

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 does the work of explaining the returns (0-100 score, grade, findings), the inputs, the payment flow, and the RDAP fallback, which is close to complete. It stops short of detailing rate limits or what 'findings' contain, leaving minor gaps for a tool this rich.

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 'domain' parameter, which is already documented in the schema with an example. The description adds nothing beyond restating that domain is required, 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 (check) applied to a specific resource (a domain) and enumerates the exact scope: RDAP registration data, DNS records, and email security (SPF, DMARC, DKIM). The phrase 'in one call' signals it aggregates what siblings like dns_lookup, whois, and email_verify do separately, so an agent can distinguish it without opening schemas.

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 rather than stated: 'in one call' suggests this is the bundled alternative to the narrow dns_lookup/whois/email_verify siblings, but no explicit when-to-use or when-not-to-use guidance is given and no sibling is named. An agent must infer the routing itself.

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 only cover safety (readOnly, openWorld, non-destructive), so the description carries the rest and delivers: per-call price ($0.06 USDC via x402 across four chains), that payment happens inside the call, auto-payment behavior for x402 clients, and explicit failure semantics ('errors with Not charged'). That is unusually rich behavioral disclosure beyond structured fields.

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?

Purpose, return values, and the fallback path are front-loaded; pricing and the sample input follow at the end. It is dense but nearly every clause (DACH constraint, fallback, price, sample) earns its place. Slightly long with the x402 chain list 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?

With no output schema, the description still enumerates the return content (grade, verdict, reasons, sanctions, VAT, domain security), plus the error path, the fallback tool, the cost model, and a sample invocation. An agent has everything needed to decide and 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 coverage is 100% and the single 'domain' parameter is fully documented ('Website domain, e.g. example.de'), so the baseline is 3. The description adds a concrete worked example ({"domain":"sap.com"}) and ties the parameter to the geographic constraint (imprint must exist), giving it marginal value above 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 specific verb and resource chain: reads the imprint to find the legal entity, then runs a KYB check returning a grade (A-F), a verdict (ALLOW/CAUTION/BLOCK), plus reasons, sanctions, VAT and domain security. This clearly distinguishes it from the sibling kyb_check, which it explicitly routes to when no imprint exists.

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 an explicit when ('Use to vet a counterparty from its website'), a when-not condition (requires a DACH imprint, otherwise it errors with 'Not charged'), and the alternative to use instead (kyb-check with the company name). All three routing signals are present without 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/non-destructive, but the description adds context they cannot carry: the per-call price ($0.0035 USDC), the payment rails (x402 across Base/Solana/Polygon/Arbitrum), and that compliant MCP clients auto-pay. That is genuinely useful behavioral disclosure. It falls short of 5 only because rate limits and error/failure behavior are unaddressed.

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?

Well front-loaded: what it does, what it returns, then when to use it, then payment mechanics. Dense but every clause is informative; the free-sample tip is a reasonable affordance rather than 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?

Even without an output schema the description names the return shape (is_valid plus granular checks), the parameter is fully specified, safety is covered by annotations, and the billing model is disclosed. The only real omission is any differentiation from email_verify.

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, so the schema already documents it fully; description adds an example input but no semantics 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?

The description names a specific verb (validate) and resource (email address) and enumerates the actual checks performed (RFC 5322, MX lookup, disposable/role detection), so the agent knows exactly what it does. However it never differentiates from the near-identical sibling email_verify, leaving the agent unable to distinguish the two from this text alone.

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?

"Use before storing or sending to email addresses to prevent bounces" gives a clear when-to-use, but there are no exclusions and no routing to alternatives. With a sibling named email_verify present, the failure to state how this differs is a meaningful gap in selection 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?

Beyond the readOnly/openWorld/non-destructive annotations, it discloses that no email is sent (important trust signal), the 6-hour result cache, the per-call price and the x402 payment mechanics with supported chains. It also fully decodes the return statuses (deliverable, undeliverable, catch_all, risky, unknown) and notes the raw SMTP reply is included.

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?

Purpose, mechanism, and return values are front-loaded before pricing and payment detail, which is the right ordering. It is a single dense paragraph, and the x402/chain enumeration is verbose, but nearly every sentence carries operative information for an agent.

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 properly carries the return-value burden and enumerates all five statuses plus the raw SMTP reply. Combined with cache TTL, cost, and payment handling, an agent has everything needed to call and interpret this 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 param, so the schema already carries the type and format. The description restates that email is required and supplies a concrete usable example value, adding a small amount of practical value beyond the structured field.

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 ('checks whether an email address really exists') and goes further by naming the mechanism (SMTP RCPT TO probe, no email sent) plus the layers applied (syntax, MX, disposable, role checks). An agent can distinguish this from a plain syntax validator 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?

Gives concrete when-to-use conditions ('before sending outreach, to clean lead lists or to block fake sign-ups'), which is strong positive guidance. However, it never names the obvious sibling email_validate or states when a lighter/cheaper check is preferable, so the agent gets no exclusion or alternative routing.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds substantial value beyond them: it discloses the per-call price ($0.0045 USDC), the x402 payment rail and currencies, that compliant clients pay automatically, and that the address is verified to be a contract. Payment/auth requirements are exactly the kind of behavioral context annotations cannot express.

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 purpose, then params, then payment, then a runnable sample. It is slightly long, but the payment details and example input earn their place for an agent, so only minor trimming is possible.

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 carries the return-value burden by listing the fields returned (name, symbol, decimals, total supply, optional balance). Combined with payment, chain, and contract-verification info, it is nearly complete, with only the remaining edge-case behavior (e.g. failure when the address is not a contract) left unstated.

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 67% and the description restates the parameters (token required contract address, chain default base, holder optional address). It usefully fills the gap for the enum-only chain param by naming the default, but it adds little beyond the schema for token and holder, 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?

States a specific verb (Read) and resource (ERC20 token contract), and enumerates exactly what it returns: name, symbol, decimals, total supply, and optional holder balance. This clearly distinguishes it from siblings like evm_balance (native balance) and erc20_transfers (transfer history), which an agent can tell apart without opening schemas.

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

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

The description gives context (which chains are supported, the optional holder lookup, and the free sample) but never states when to use this tool versus alternatives such as evm_balance or erc20_transfers. Usage is implied rather than routed, so it lands at the minimum-viable level.

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

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses the RPC block-window limit (up to 12000 blocks, fewer on busy tokens), that the response reports the searched range, and the x402 payment requirement with supported chains. This is rich behavioral context an agent needs before calling.

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-loads return format and ordering before limitations, pricing, and sample. Dense but every sentence earns its place; the inline example JSON is slightly verbose but useful for first-call correctness.

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 still enumerates return fields and notes the response reports the searched block range. Combined with payment details and scope limits, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description adds genuine meaning by clarifying the holder filter matches transfers 'from or to one wallet' and that results are capped at 50 and ordered newest-first, which the schema does not spell out.

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+resource: 'Recent Transfer events of an ERC-20 token', and enumerates the returned fields (tx, time, from, to, amount). This distinguishes it from metadata tools like erc20_info and native-transfer tools like evm_tx without naming them explicitly.

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?

'Use for quick wallet or token activity checks' gives clear context, and the block-range caveat ('cheap but not a full history') signals when the tool is insufficient. It stops short of naming an alternative for full history, so it is not 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?

Annotations already declare the read-only, non-destructive, open-world safety profile, and the description adds substantial context beyond them: a pay-per-call cost ($0.002 USDC), the x402 in-band payment mechanism and the chains accepted, plus a free sample invocation. Billing and payment behavior is exactly the kind of trait an agent needs and cannot infer from 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?

Front-loaded with purpose, then use cases, params, price/payment, and a sample input; every sentence carries information. It is dense rather than padded, though the payment and sample sentences make it longer than strictly necessary.

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 return-value burden and does name the returned fields (ETH/USDC balance, transaction count, x402 call coverage). It omits response shape/formatting details, but for a single-address read tool this is close to 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% and the address pattern plus description are already documented in the schema. The description only restates 'address (required, 0x...)' without adding format or semantic detail, 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 and resource (read ETH and USDC balance of any address), pins the exact scope (Base mainnet, chain 8453), and enumerates the extra returns (transaction count, x402 call coverage). The explicit chain restriction naturally separates it from broader siblings like wallet_portfolio and evm_tx.

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 three concrete scenarios: checking your own agent wallet before a paid workflow, verifying a counterparty was paid, and monitoring treasury addresses. It does not name a when-not condition or an explicit alternative tool, so it stops short of 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds genuinely non-obvious operational context: $0.002 USDC per call, paid in-band via x402, accepted payment chains, and that x402 MCP clients auto-pay. That cost/auth disclosure is exactly the kind of behavior an agent must know before invoking; only the lack of error/rate-limit behavior keeps it from 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?

Front-loads purpose and outputs, then params, then pricing — a sensible order. The pricing/sample sentences are long but each carries invocation-critical information (payment requirement, runnable example), so little is wasted.

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 fully enumerates the return surface (status states including not_found, block, confirmations, value, gas, fee, method id, decoded ERC20 transfers) and covers the payment prerequisite and a copy-pasteable example, so 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 coverage is 50% (only 'hash' is described in the schema; 'chain' has just an enum and default), but the description compensates by restating hash as a required 0x transaction hash and documenting chain as 'base' default with 'ethereum' or 'iota-evm' alternatives, including a full example 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?

Opens with a specific verb+resource ('Look up a transaction') and enumerates the returnable fields (status, block, confirmations, hash fields, decoded ERC20 transfers), so the agent knows exactly what it gets. It also names the supported chains, which differentiates it from siblings like btc_tx, sui_tx, tron_tx and iota_tx.

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 a concrete use case ('confirm that a payment arrived') and states which chains apply, plus how to get a free sample. It does not explicitly exclude or point to alternative sibling tools (e.g., iota_tx vs this with chain='iota-evm'), so routing guidance is present but not exhaustive.

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 (readOnly, openWorld, non-destructive), and the description adds substantial context beyond them: publication schedule (~16:00 CET on working days), source authority (ECB), a paid x402 flow with per-call price and accepted chains, and a free sample invocation. This is exactly the behavioral detail an agent needs to decide and pay.

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 what the tool is and its scope, then payment mechanics. Slightly dense and the payment/sample sentences lengthen it, but each sentence carries actionable information for the caller.

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 still explains the return shape (rates object mapping codes to rates relative to base), the data source and freshness, and the payment/auth requirement. 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 coverage is 100% so the baseline is 3, but the description goes further by clarifying cross-rate semantics for 'base' and giving a worked example ({'base':'EUR','symbols':['USD','CHF','GBP']}) plus the empty-symbols behavior. It adds modest value over the schema rather than just restating it.

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 (official ECB currency exchange rates), names the source, the ~30-currency scope with examples, and the cross-rate capability. An agent can distinguish it from siblings like crypto_prices or macro_data 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?

Explicitly names use cases ('currency conversion in invoices, pricing, or financial calculations') and gives a concrete example input, but does not name a sibling alternative or state when NOT to use it. 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 already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint true), and the description goes well beyond them by disclosing the dedupe guarantee, cursor lifecycle, and the paid x402 model ($0.003 USDC per call, accepted chains, auto-pay clients, free sample). That payment/auth context is exactly the non-obvious behavior an agent needs before invoking.

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 core behavior and then the call flow, params, and pricing in a logical order. It is dense and slightly crowded in the final sentences, but each element (cursor, price, sample) is actionable rather than 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-param tool with no output schema, the description covers invocation flow, return semantics (new items only, cursor), and cost. It does not describe the item shape or error behavior, but the essential calling information is present.

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 67%, and the description supplies the meaning the schema omits for 'limit' ('max new items returned'), while cursor usage is explained in prose. The '1 to 50, default 20' detail largely repeats the schema's min/max/default, so it adds only modest value on top.

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 (RSS/Atom feed monitoring) plus the distinguishing behavior — 'returns only the items that are new since your last call, never the same item twice' — which separates it from a plain fetch such as the sibling rss_fetch. An agent can identify the tool's role 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?

Explains the two-call flow clearly ('First call saves a baseline and returns a cursor; pass it on the next call') and enumerates supported feed types. It stops short of an explicit exclusion or naming of rss_fetch for one-off fetches, so it is clear context without full alternative routing.

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

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

Beyond the annotations (readOnly/openWorld/non-destructive), the description discloses the paid nature: $0.002 USDC per call, billed inside the call via x402 on Base/Solana/Polygon/Arbitrum, that x402 MCP clients auto-pay, and a free sample call. This cost/payment disclosure is critical context an agent needs before invoking.

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 what it does and returns, followed by params, then pricing and a sample. Every sentence is functional, though the pricing/payment detail makes it denser than a pure read-tool blurb.

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 enumerates the returned fields, and it covers the one parameter's default behavior plus the payment prerequisite. For a single-param read tool with annotations covering safety, nothing an agent needs to call 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 0% with one parameter, so the description carries the burden. It states chains is optional, defaults to all, and enumerates the supported networks in prose, compensating well for the undocumented schema, though it doesn't restate the accepted enum strings as a clean list.

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

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

The description states a specific verb+resource (current gas prices) plus the exact chains covered and the full set of returned metrics (gas price, base fee, priority fees, USD cost estimates). An agent can immediately tell this is a multi-chain EVM gas estimator, distinct from siblings like btc_fees or crypto_prices.

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

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

Usage is implied rather than stated: it explains that chains is optional and defaults to all, and provides a sample input, but never says when to prefer this over btc_fees, crypto_prices, or other fee/pricing tools, nor any exclusions. Adequate but leaves selection 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 safety (readOnlyHint, openWorldHint, destructiveHint=false), but the description adds substantial behavioral context they cannot: pay-per-call cost ($0.003 USDC), the x402 payment mechanism and supported chains, automatic payment by clients like @x402/mcp, millisecond latency from an own database, and how out-of-scope input surfaces via ignored_parts. That is uncommon depth for a paid 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?

Purpose is front-loaded in the first clause, followed by coverage, limitations, payment, and a free-sample hint, each in its own sentence. Dense but every sentence carries a distinct fact; the pricing and sample details are long but justified for a paid tool.

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 still discloses a return-field name (ignored_parts), coverage scope, latency, and payment requirements, so an agent knows what to expect and what it costs. It stops short of describing the general response shape (e.g. place name, country, postal code fields), leaving a small gap for 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% and the schema itself carries examples, the oneOf constraint, and limit semantics, so the description has little left to add. The description does reinforce the address-vs-lat/lon choice and gives its own example strings ('Paris, Texas', '10115 Berlin'), but adds no format or constraint detail the schema lacks. 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 and resource (geocoding / reverse geocoding) and describes both directions of the transform: 'city, town or postal code to lat/lon, and lat/lon to the nearest place and postal code.' An agent can immediately tell this apart from siblings like postal_code or timezone, which do not convert between coordinates and addresses.

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 two input modes: 'Provide address (e.g. ...) or lat + lon', matching the schema's oneOf. It also states the scope limitation ('Not street level: house numbers and streets are skipped'), which tells the agent when results will be partial. It does not name sibling alternatives (e.g. postal_code), so it stops short of full when/when-not routing.

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

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

Annotations cover the safety profile (readOnly, non-destructive, openWorld), and the description adds high-value behavior beyond them: a $0.003 USDC per-call price, the x402 in-band payment mechanism, supported chains (Base, Solana, Polygon, Arbitrum), which clients auto-pay, and a free sample call. This is exactly the kind of non-schema context an agent needs before invoking a paid 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?

Front-loaded with purpose, then a compact parameter recap, then pricing and a sample. The parameter list partly duplicates the schema, and the payment sentence is slightly verbose, but nothing is wasted given a paid API needs disclosure.

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 six-parameter paid tool with no output schema, the description covers purpose, params, payment, and example invocation. It stops short of describing the return shape (e.g., whether a date check returns a boolean and what fields each holiday carries), which is the only notable 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 67%, and the description compensates by enumerating all six parameters with concrete examples (DE/US/CH/JP, BY/CA/ZH), the ISO 3166-1 alpha-2 convention, the YYYY-MM-DD format, and defaults for year and include_observances. It adds meaning over the bare schema for the fields lacking descriptions (year, include_observances).

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 ('Public and bank holidays for 200+ countries and their regions') with scope (any year, with local names) and a secondary mode ('check whether a given date is a holiday'). No sibling in the list overlaps, so the tool is unambiguously identifiable.

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?

Clearly frames the two usage modes (list holidays vs. date check) and gives defaults (year = current, include_observances = false), plus a free-sample invocation. There are no sibling alternatives to disambiguate against, so it lacks explicit when-not guidance, 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?

Annotations give the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds real context beyond them: the return shape, a per-call price, the x402 payment rails, and a free sample invocation. It stops short of rate limits or the public-accessibility constraint on the URL input.

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 purpose and return values, then constraints, then pricing. Every sentence is functional, though the pricing and free-sample sentences make it longer than strictly necessary for tool selection.

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

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

With no output schema, the description correctly compensates by naming the return fields (pdf_base64, page_count) and explains the payment requirement. An agent has everything needed to invoke it correctly, including a runnable sample.

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 url/html, format, landscape, and margin. The description largely restates these (A4/Letter/Legal, CSS units) and only reinforces the oneOf constraint, adding no new parameter meaning.

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: render a URL or raw HTML to PDF. It is immediately distinguishable from siblings like doc_convert, pdf_extract, and screenshot, and the returned artifacts (pdf_base64, page_count) are named up front.

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 use cases (invoices, reports, printable documents) and the critical input-exclusivity rule ('Provide url OR html, never both'). It does not name a sibling alternative such as doc_convert for other conversion paths, so no explicit when-not 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 cover readOnly/destructive/openWorld, but the description adds critical info annotations cannot express: the paid-per-call model ($0.0045 USDC), the x402 payment rails, the automatic-payment behaviour of x402 clients, and a free sample call. These are exactly the operational facts an agent needs before deciding to spend. It stops short of latency or error/refund behaviour, keeping it out of the 5 range.

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 resource and fields, then usage modes, then params, then pricing and sample. Every sentence carries information an agent needs. Slightly dense but no filler; a 5 is reserved for tighter structures.

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 data tool with no output schema, it covers inputs, filtering modes, cost, payment mechanics and a free-try path. The only gap is an explicit statement of return shape (e.g. a list of per-coin objects), which is partially addressed by the field enumeration. Adequate and well-rounded.

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 50% (coins documented, limit not). The description compensates by restating both params with constraints: coins optional max 50 with a usage example, limit 1–50 default 10 and the crucial rule that it applies only when coins is omitted. That last sentence adds meaning the schema does not express, lifting it above 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 first sentence names the specific resource (Hyperliquid perpetual futures market data) and enumerates exactly what fields are returned: mark/oracle price, 24h change, funding rate and APR, open interest, 24h volume, max leverage. This is a precise verb-and-resource statement that an agent can match to intent 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?

It states the two modes clearly: pass coins for specific markets, omit them to get top markets by open interest, plus a worked example. It does not explicitly say when to prefer this over the sibling `perp_funding`, though the field list makes the distinction inferable. Strong but missing an explicit alternative-tool pointer.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint=false, which already signal a safe read), the description discloses the key behavioral trait an agent cannot infer elsewhere: a $0.0025 USDC per-call charge paid in-band via x402 across four chains, auto-pay clients like @x402/mcp, and a free sample path. It also describes the return payload country-by-country, which matters because there is no output 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?

Front-loaded with capability, then the parameter, then payment mechanics, then a copy-pasteable sample. Dense but every element (validation scope, cost, x402 chain list, example input) earns its place; only the parenthetical repeats the schema slightly.

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 enumerates the returned fields (bank code, branch, account, SEPA flag, plus bank name/BIC/city for DE/AT/CH/NL/BE/LU/LI). The payment requirement, the one parameter, and the sample input cover everything needed to invoke and interpret the 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% for the single parameter, so the schema already documents 'iban' including that spaces are allowed. The description repeats 'iban (required, spaces allowed)' and only marginally adds a concrete spaced example format. 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 precise verb+resource (validate an IBAN) and enumerates exactly what is validated (checksum, country length, structure), then lists the derived outputs (bank code, branch, account, SEPA status, and BIC/bank/city for specific countries). This clearly separates it from the many sibling *_validate tools (vat_validate, email_validate, phone_validate) by naming the exact artifact it operates on.

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 purpose (validate an IBAN before relying on it) and the example input shows how to test, but there is no explicit when-to-use / when-not-to-use and no alternative named among the sibling validators. The free-sample hint is the only practical 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?

Beyond the read-only annotations, it discloses the return shape (short alt under 125 chars, long description, decorative flag, in-image text, ready attribute), that the image is scaled to 800x800, the model used, and the cost/payment mechanism. This is unusually rich behavioral context for an agent deciding whether and how to 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?

Front-loaded with purpose and outputs, and the size is justified by genuinely call-relevant detail (cost, payment, free sample). It is dense and crams the payment mechanics and a full example payload into a single paragraph, but no sentence is wasted.

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 returns and does so fully, along with inputs, processing, pricing, and workflow. Nothing an agent needs to invoke 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 coverage is 100%, so the baseline is 3. The description adds only marginal meaning — the image_url-or-image_base64 either/or, and an example for language ('German') — both of which the schema largely already conveys.

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 — generate alt text for images — and names the accessibility/SEO use case. It also distinguishes itself from the sibling accessibility_check, which 'finds images without alt text', so an agent can route between the two 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?

Gives clear context (web accessibility per WCAG 1.1.1/BFSG/EAA, and SEO) and an explicit workflow relationship with accessibility_check. It lacks a direct when-not-to-use or alternative-selection statement, but the routing context is strong.

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 and non-destructive, and the description adds substantial behavioral context beyond them: per-call price ($0.0045 USDC), payment mechanism (x402 on Base/Solana/Polygon/Arbitrum), automatic payment by x402 clients, EXIF auto-rotation, and a free sample call. The paid, in-call settlement requirement is a critical trait an agent must know before invoking.

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?

Purpose is front-loaded, then use cases, params, pricing, and a sample call. The pricing/payment sentence is lengthy but earns its place given the pay-per-call model. Slightly dense overall but 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?

Covers formats, dimensions caps, use cases, and the payment model well for a tool with no output schema. The one gap is the return format (base64 vs URL, single vs batch), which an agent would want to know, though it's a minor omission given the otherwise thorough coverage.

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 only 29%, so the description must compensate, and it does: it summarizes every parameter with defaults and bounds and critically states that image_base64 or image_url is 'one required' — important since the schema marks zero required params. It doesn't explain the semantics of the fit modes (cover/contain/fill), which keeps it from a 5.

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 specific verbs and resource: 'Resize, crop-fit and convert images', enumerating input formats (PNG, JPEG, WebP, AVIF, GIF, TIFF, SVG) and output targets (webp, png, jpeg, avif). This clearly distinguishes it from siblings like image_alt_text, screenshot, and ocr, which have different jobs.

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: shrink screenshots before sending to a vision model, create thumbnails, or convert formats. This gives strong context for when to reach for the tool, though it names no alternative tool or when-not-to-use condition.

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 confirm readOnly, openWorld, and non-destructive behavior, and the description adds substantial operational context: exact XML parsing versus Claude Haiku for PDF/photo, VIES VAT ID and IBAN/BIC validation, EN 16931 detection, 15 MB size limit, and the $0.02 USDC per-call x402 payment mechanism.

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

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

The description is front-loaded with purpose and then adds operational details in a dense but mostly useful single paragraph. Every sentence is relevant, though the payment and sample details could be slightly more 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 no output schema, the description compensates by listing the extracted JSON fields, validation checks, and e-invoice authenticity signal. It also covers input limits, pricing, and a free sample, leaving no major gap for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a meaningful input constraint (up to 15 MB), identifies supported input formats, and provides a concrete example invocation using pdf_url, which helps an agent understand parameter usage beyond the schema text.

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

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

The description states a specific verb and resource: invoice data extraction from PDFs, photos, and EU e-invoice XML into structured JSON. It identifies the exact document domain (accounting invoices) and distinguishes its behavior from generic OCR or PDF extraction by explaining that e-invoices are read from embedded XML without AI.

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

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

The description gives clear context for when to use it: accounting agents processing PDF, photo, XRechnung, ZUGFeRD, or Factur-X invoice inputs. It does not explicitly name sibling alternatives such as pdf_extract or ocr, but its format-specific processing notes provide practical 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 readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds material behavioral context the annotations do not: a per-call price ($0.002 USDC), the x402 payment rail (USDC on Base/Solana/Polygon/Arbitrum), and that x402 MCP clients auto-pay. It omits rate limits or failure/refund behavior, so it falls 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?

Purpose is front-loaded in the first sentence, followed by payment terms and a free-sample hint. The opening sentence is dense with a comma-heavy payload list, but each remaining sentence carries necessary information (pricing, payment mechanism, sample call), so there is little waste.

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 carries the return-value burden by enumerating balance, coins, staking/rewards, USD value, resolved name, and outgoing transactions. Combined with the payment disclosure and a runnable sample input, an agent has everything needed to call and interpret 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 coverage is 100% and the single 'address' parameter is fully documented in the schema with both accepted forms. The description adds an example input address, which is marginally useful, but nothing about syntax or edge cases beyond what the schema already states, 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 ('Everything about an IOTA mainnet address or IOTA name') and enumerates the concrete payload: balance, all coins with symbols, staked IOTA per validator with estimated rewards, USD value, name resolution, and latest outgoing transactions. It is easy to distinguish from iota_network, but it does not explicitly differentiate itself from iota_tx or iota_watch, whose territory ('outgoing transactions', 'watch') partly overlaps.

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 'Everything about...' and the resolution note ('Resolves names to addresses and back'), so an agent can infer this is the general lookup tool. However, there is no explicit when-to-use vs. iota_tx/iota_watch guidance and no exclusions, leaving routing 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 readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description goes substantially beyond them by disclosing the commercial model: $0.002 USDC per call, charged inside the call via x402, payment rails accepted (Base, Solana, Polygon, Arbitrum), automatic settlement for x402-aware clients, and a free sample via empty input. Cost and payment requirements are exactly the kind of behavioral trait annotations cannot express.

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 sentence is long but front-loads the highest-value information (what you get) before usage and pricing, and every clause earns its place since there is no output schema to carry the field list. It is 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?

With no output schema, the description carries the full burden of describing the return payload, and it does so field-by-field. Combined with the payment disclosure and usage context, an agent has everything needed to decide whether and how to call it.

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

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

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description reinforces this by noting the free sample is 'call with the example input {}', confirming no inputs are required, but there is no parameter meaning to add.

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 the resource (IOTA mainnet) and enumerates the exact data returned: epoch, latest checkpoint, reference gas price, transfer fee, total/circulating supply, price and market cap, total stake, and every active validator with APY, commission and stake. That level of specificity makes it trivially distinguishable from the other iota_* siblings (iota_tx, iota_address, iota_watch), which operate on transactions/addresses rather than network state.

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 two explicit use cases — 'pick a validator' and 'show network health' — which is clearer than mere implied usage. It stops short of naming an alternative or an exclusion (e.g., pointing transaction lookups to iota_tx), so it earns a 4 rather than 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?

Annotations declare readOnlyHint=true, but the description states the tool writes a locked, immutable notarization to the public IOTA ledger ('cannot be changed or transferred and its deletion is locked until 2106') and charges $0.01 USDC per call. Creating irreversible on-chain state and spending funds is not a read-only operation, so an agent told this tool is side-effect-free could invoke it without the confirmation a paid, permanent write warrants. This is a direct annotation contradiction.

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

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

Well front-loaded: purpose and privacy guarantee come first, then returns, then use cases, then cost and sample. It is long (~130 words) and carries payment/onboarding detail an agent may not need on every call, but each sentence does carry actionable information, so the length is mostly earned.

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 fully carries the burden: it enumerates the return payload (object id, transaction digest, ledger time, explorer links), the storage model (hash only, immutable, deletion locked), the cost and payment rail (x402 USDC on four chains), and the sibling to use for later verification. Nothing material is left for the agent to guess.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema: it tells the agent that only the SHA-256 digest is persisted and 'never your content', which changes how an agent reasons about sending sensitive text or URLs. The three input modes (text, hash, url) are restated at a level that confirms the schema's intent rather than merely repeating it.

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?

Opens with a concrete verb+resource+network: 'Proof of existence on the IOTA mainnet: send text, a SHA-256 hash or a URL and get a tamper-proof timestamp.' It explicitly distinguishes itself from its nearest sibling by stating 'Check later with iota-verify', so an agent can route between notarize and verify without opening either 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?

Gives concrete when-to-use triggers ('contracts, invoices, AI outputs, datasets, web page evidence or audit logs'), names the alternative for the follow-up action (iota-verify), and provides a runnable example input as a free sample. There is no ambiguity about when this tool, rather than a verification or hashing sibling, is the right call.

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

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

Annotations already declare readOnly/openWorld/non-destructive, and the description layers on genuinely non-redundant behavior: a per-call price ($0.002 USDC), the x402 payment rail and accepted chains (Base, Solana, Polygon, Arbitrum), automatic payment by @x402/mcp clients, and a free sample invocation. This is exactly the auth/cost context an agent needs and cannot get from 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?

Purpose and return fields are front-loaded, then usage, then payment mechanics. The long enumeration of returned fields is dense but earns its place given there is no output schema; the structure is logical and free of filler, though the field list is slightly run-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?

With no output schema, the description must carry the return contract, and it does so explicitly (status/error, time, checkpoint, sender, calls, gas, balance changes, object deltas, events). Combining that with the payment and usage context, an agent has everything needed to call and interpret this 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 the single 'digest' parameter is fully documented as base58, so the schema carries the burden. The worked example input reinforces the format but does not add semantic meaning beyond what the schema already states, 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 and resource ('Look up an IOTA mainnet transaction by digest') and immediately enumerates the returned fields (status, checkpoint, sender, Move calls, gas fee, balance changes, objects, events). This cleanly distinguishes it from sibling read tools like evm_tx, btc_tx, and sui_tx, which target different chains.

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

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

Provides clear context ('Use to confirm a payment or contract call on IOTA'), so the agent knows the triggering scenario. However, it names no alternatives and sets no exclusions (e.g. iota_verify for notarization checks or iota_watch for monitoring), leaving the routing decision partly 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?

Goes well beyond the annotations: discloses the full return payload (stored hash/data, ledger creation time, lock status, owner, match boolean), states read-only/no-wallet, and — critically — discloses that the call is paid ($0.003 USDC via x402 on Base/Solana/Polygon/Arbitrum) with automatic payment by x402 clients. Payment requirements and return contents are exactly the traits annotations cannot convey.

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

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

Dense and front-loaded: verification purpose, inputs, outputs, then read-only/pricing/example. Every element earns its place, though the x402 payment paragraph and inline JSON example make it longer than strictly necessary for selection.

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

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

With no output schema, the description fully carries the return-value burden and also covers payment, safety profile, and a worked example. An agent has everything needed to decide, pay, 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%, so baseline is 3, but the description adds real meaning: it frames object_id/transaction as the identifying input and text/hash/url as the optional 'content to check' that produces the matches true/false result, and its example shows how the fields combine — something the flat schema does not express.

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+resource ('Verify an IOTA notarization') with explicit scope: any notarization on IOTA mainnet, ours or anyone's, official package. It clearly distinguishes itself from the sibling iota_notarize (create) by being the check-side operation.

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

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

Tells the agent what input is needed ('give the object id or transaction digest... and optionally the text, SHA-256 or URL to check') and provides a concrete callable example. It lacks an explicit when-not or a named alternative (e.g., pointing at iota_notarize for the write side), so it stops short of full 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?

Goes well beyond the readOnly/openWorld annotations by disclosing the cost model ($0.002 USDC per call), the payment rail (x402, USDC on Base/Solana/Polygon/Arbitrum), which clients pay automatically, and the cursor-based stateful behavior across calls. This is exactly the auth/pricing/rate context an agent needs and cannot get from 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?

Front-loaded with purpose, return fields, then workflow and pricing, with no wasted sentences. The inline sample-input JSON is long but earns its place by showing a free-call path; slightly heavy 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?

With no output schema, the description fully enumerates the return payload (direction, amount, status, time, explorer link, balance) plus the cursor contract and payment requirement. An agent has everything needed to call and continue the watch loop correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains cursor provenance ('first call returns recent transactions and a cursor; pass the cursor back') and demonstrates limit usage in the sample input. It does not restate the 1-50 range, which the schema already covers.

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 (watch), resource (IOTA mainnet address or IOTA name), and enumerates exactly what is returned: direction, amount, status, time, explorer link, balance. This distinguishes it from siblings like iota_address, iota_tx, and iota_verify without opening any schema.

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

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

Names concrete scenarios (deposit detection, treasury and whale watching) and explains the polling workflow: first call returns a cursor, pass it back for only new transactions. It does not explicitly contrast with alternatives such as iota_tx for a one-off lookup, so it stops short of the top score.

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?

Goes well past the readOnly/openWorld annotations by disclosing the local-database source (no third-party call), millisecond latency, address-class rejection behavior, the $0.0055 USDC per-call price with the x402 payment rails, and a free sample input. An agent knows exactly what it will cost and how payment is handled before invoking.

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 purpose and return fields, and the pricing/licensing detail is genuinely decision-relevant for an agent paying per call. It is a single dense paragraph with heavy parenthetical stacking (payment rails, attribution), which costs it a point versus a cleanly segmented version.

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 by enumerating the returned fields (country, region, city, lat/lon, timezone, ASN/org, is_eu). Payment mechanics, latency, and validation behavior are all covered, so nothing needed 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 coverage is already 100%, so the schema documents the ip format. The description nonetheless adds meaning beyond it: the parameter defaults to the caller's IP, and invalid/private/reserved values are rejected rather than returning nulls. Minor tension with the schema marking ip required, but the added semantics are real.

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?

Opens with a specific verb+resource ("IP lookup and geolocation: resolve any public IPv4 or IPv6 address to location and network data") and enumerates the returned fields. This clearly separates it from address-oriented siblings like geocode or postal_code and from dns_lookup.

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

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

Explicit use cases are given: fraud and bot checks, geo-routing, analytics, tagging traffic, plus the boundary rule that invalid/private/reserved addresses are rejected. It lacks an explicit "use X instead" comparison to the nearest sibling (geocode), so it stops short of a 5.

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

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

Beyond the annotations (readOnlyHint=true, openWorldHint=true), the description discloses the paid-call model, price ($0.12 USDC), the x402 payment mechanism and chains, auto-pay clients, and a caveat that a sanctions match requires manual verification. That is significant behavioral context an agent cannot get from structured fields.

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 core capability and outputs before prerequisites, pricing, and the sample call. The dense multi-topic run-on sentences are efficient but slightly packing-heavy, keeping it just below maximum.

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 fully compensates by describing return shape (grade, score, verdict, reasons, confidence, sections). It also covers cost, payment, prerequisites, caveats, and provides a concrete example input, leaving nothing an agent needs to invoke it correctly.

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

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

Schema requires no fields, but the description supplies the actual invocation rule: 'Pass name and at least one of vat_number, lei, domain.' That corrects the empty required list and adds meaning beyond the 67%-covered schema. It could add format details for country/domain, hence a 4 rather than 5.

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 ('Full EU company check') and enumerates the concrete checks bundled (LEI status, VIES VAT, sanctions, domain age, email security, IBAN). It returns specific outputs (grade A-F, score 0-100, ALLOW/CAUTION/BLOCK), so an agent can distinguish it from siblings like company_lookup, vat_validate, or sanctions_screen.

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 states the usage context ('Use for onboarding and payment checks') and explicitly frames the sanctions result as a hint to verify manually, which is real usage guidance. It doesn't name sibling tools as alternatives, so it stops short of explicit when-not/alternative routing.

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