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

With no annotations, the description carries the full burden and does so: it discloses pricing ($0.015 USDC), p99 latency (20s), a partial-refund rule ('Not charged when the page cannot be loaded'), the automated-coverage limit (~a third of barriers), and a detailed picture of the returned grade, impact ordering, selectors and fix hints.

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, then tiers of detail. The long parenthetical rule list and the standards sentence are dense but each carries selection-relevant information; nothing is padding, though the description is on the verbose side.

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 and no annotations, the description fully picks up the slack: it explains what the audit returns, how results are graded and sorted, the coverage limitation, billing conditions and cost. An agent has everything needed to call it 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 description coverage is 100%, so both parameters are already documented in the schema. The description restates the mobile mode as a '390 px phone viewport', adding marginal colour beyond the schema's '390x844 vs 1280x800'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Automated web accessibility audit of a page in a real browser with axe-core') and grounds it in named standards (WCAG 2.2 AA, EN 301 549, EAA, BFSG, BaFG). This clearly distinguishes it from neighbours like seo_meta, site_audit, privacy_check and image_alt_text.

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?

Strong when-to-use framing ('For the EU Accessibility Act (EAA), the German BFSG ... and Austrian BaFG') and an explicit scope caveat ('a screening, not a certification and not legal advice'). It stops short of naming an alternative sibling or a when-not-to-use condition, so it is clear context without explicit 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?

With no annotations present, the description carries the full burden and does so richly: read marks messages read (a state-mutating side effect), peek is non-destructive, read can block up to 20s, webhook delivery is HMAC-SHA256 signed, plus limits (64 KB, 1000 unread), retention (1–365 days, 7 days for read), cost ($0.003/call) and p99 latency (25000ms).

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 identity and address/secret concept before behavioral rules, and almost every clause (limits, retention, cost, latency) carries operational value. It is dense enough that the op semantics are somewhat compressed, but nothing is truly 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?

For a 14-parameter, no-annotation, no-output-schema tool, the description covers the critical operational traits an agent needs to call it correctly. It stops short of describing the actual return payloads (e.g. what read/peek/create return), which an agent would need since no output schema exists.

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

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

Schema coverage is 79% (high), so the baseline is 3; the description adds genuine meaning beyond schema by explaining op semantics, the create/read/peek/send selection logic, and the inbox_/ibs_ identifier formats. It does not add detail on limit, ttl_days, or after beyond what the schema already states.

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

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

States a concrete resource (a mailbox for AI agents) and enumerates its operations (op send, read, peek, create, delete) with the resulting artifacts (inbox_... address, ibs_... secret). An agent can immediately distinguish this from siblings like agent_memory or agent_run 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 explicit use cases (hand results between agents, collect job results, let other agents reach yours) and explains the read-vs-peek distinction for shared-queue usage plus the op defaulting rule. It lacks an explicit when-not-to-use or a named alternative sibling, so it falls 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?

With no annotations, the description carries the full burden and largely succeeds: it discloses the store-secret model, no-account access, value/key/store size limits (64 KB, 1000 keys, 5 MB), TTL semantics (1–365 days, default 30, renewed on every write), pricing, and p99 latency. Gaps remain around error/concurrency-failure behavior and what delete permanently removes, but the operational profile is unusually rich.

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

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

Front-loaded with the core concept and store flow before the operation enumeration and limits, so the most important content comes first. It is dense and information-rich with almost no filler, though the separate 'One price per operation' and 'Cost: $0.002 USDC per call' sentences are mildly redundant.

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-parameter, zero-required tool with no output schema and no annotations, the description covers the operational model, per-op semantics, limits, TTL, cost, and latency well. It stops short of explaining return shapes for get/list/search, which is a real gap given no output schema exists.

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

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

Schema coverage is 63%, so some meaning must come from the description, and it adds real value: if_version for safe concurrent updates (0 = must not exist), append's oldest-items-drop behavior and max_items, incr as an atomic counter, and search matching words in keys and values. Several params (tag, prefix, limit, ttl_days, tags, with_values) get only list-level or no explicit meaning, keeping this below 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 resource ('Key-Value Store', 'Persistent memory for AI agents') and enumerates the concrete operations (set/get/get_many/delete/list/search/append/incr), so an agent knows exactly what the tool does. It is clearly distinguishable from siblings like agent_run and agent_inbox, which are unrelated capabilities.

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 intended usage flow well: store JSON under a key and read it back in a later run or share between agents, with the first-write-creates-store lifecycle spelled out. It tells the agent which op to pick for each need (e.g. append for a rolling log/task queue, incr for counters), but offers no explicit when-not-to-use or named alternative tool.

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

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

With no annotations, the description carries the full burden and does so well: it states read-only behavior ('cannot spend money or send anything'), the step cap (~12) and time budget (~90s), the output shape (Markdown with sources plus the list of tool calls made), cost ($0.5 USDC per call), and p99 latency (60000ms). These are exactly the operational traits an agent needs before committing a paid, slow 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?

It is a single dense paragraph, but it is front-loaded with what the tool does before diving into tool categories, examples, cost, and latency. Every clause is information-bearing, though the long parenthetical tool enumeration is slightly heavy.

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 slow, paid, multi-tool agent with no output schema and no annotations, the description covers purpose, safety profile, cost, latency, step limits, and return format. An agent has everything needed to decide whether to call it and what to expect back.

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

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

Schema coverage is 100%, so the schema already documents both parameters, setting the baseline at 3. The description mostly restates what the schema provides ('Up to 12 steps' maps to max_steps' 1–12 range) and adds no new syntax or format guidance for 'task' or 'max_steps' beyond the schema.

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

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

The description names a specific verb+resource: it hands off a whole research/lookup task to an agent that plans steps and calls many tools, returning a Markdown answer. The nature of the tool (a meta-agent spanning many single-purpose siblings) makes its function unmistakable. It doesn't explicitly contrast itself with close siblings like research_report or answer_with_sources, so it stops short of a 5.

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

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

Concrete examples clarify when to reach for it ('compare two DeFi protocols, check a company and its domain, or summarize what changed this week'). This gives clear usage context, but no explicit when-not conditions or named alternatives among the many single-purpose sibling tools.

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

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

With no annotations, the description carries the full burden and does well: it discloses read-only scope implicitly via "status", a per-call cost ($0.0045 USDC), p99 latency (1500ms), and the edge case that general-aviation-only closures are surfaced as notices rather than active disruptions. It does not mention error behavior for invalid or non-US codes, 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?

It is a dense but front-loaded single paragraph: purpose and outputs first, then parameter behavior, then scope, then cost/latency. Every clause carries information, though the parameter-recap sentence is mildly redundant with the schema and the run-on structure could be split for readability.

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

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

There is no output schema, and the description compensates by enumerating the returned data (ground stops, GDP delays, trend-bearing arrival/departure delays, closures, per-airport status values normal/delays/disrupted). Combined with scope, cost, and latency, 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 parameter is optional, so the baseline is already 3. The description adds meaning beyond the schema's bare "US airport codes" example by specifying that both IATA (JFK) and ICAO (KJFK) forms are accepted and that supplying the parameter changes the shape of the response from all-events to per-airport status.

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 opens with a specific verb+resource: live US airport disruptions sourced from the FAA National Airspace System, and enumerates the exact disruption types (ground stops, GDPs with average/max delay, arrival/departure delays, closures). No sibling tool in the list overlaps with airport status, so the function is unambiguous.

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

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

It clearly states the two operating modes: pass airport codes for a per-airport status, or omit them to return all current events. It also sets a hard scope boundary ("US airports only"). It stops short of naming alternatives or explaining what happens with an unknown/non-US code, so it is strong context rather than fully explicit when/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?

With no annotations, the description carries the full burden and does so well: it discloses the source scope, that only the top 3 pages are read, the answering model, the abstain behavior ('when the sources do not answer the question it says so'), the no-charge-on-abstain policy, cost ($0.008 USDC), and p99 latency.

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

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

Front-loaded with the core purpose and packed with high-value operational facts, so nearly every clause earns its place. It is one dense run-on block though, and the parenthetical asides make it slower to scan than it could 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?

For a 3-parameter tool with no annotations and no output schema, the description covers everything an agent needs: what comes back (answer plus citation list), when sources fail and what that costs, per-value behavior of the source selector, and cost/latency budgets for decision-making.

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% (question max 400 chars and language are documented; source only via enum/default). The description adds genuine meaning the enum cannot convey: what 'auto' actually resolves to and that 'news' vs 'web' map to news-first vs Wikipedia, plus confirmation that language is optional. Only the absence of explicit per-value notes for 'news'/'web' keeps it off 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 and output artifact: 'Ask a question, get a short answer with numbered citations [1], [2] and the source list.' It names the exact corpus (Wikipedia, GDELT, Hacker News last 7 days) and the reading strategy, which makes it trivially distinguishable from siblings like web_search, news_search, or search_read.

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 real routing guidance: 'source auto (current events go to news first), news or web (Wikipedia)' and a clear when-not: 'Not a general web index: niche or very new topics may have no sources.' It never names the sibling tool to use instead (e.g., web_search) for general queries, so routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does so well: it discloses data handling ('the audio is deleted after the call'), hard limits (10 minutes / 24 MB per call), pricing ($0.01 USDC per call), latency (p99 60000ms), and the default/speed model tradeoff. These are exactly the traits 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?

Front-loads the purpose and packs limits, cost, and return shape into a compact block. The opening 'Speech to Text (Whisper Transcription) — Speech to text for agents' restates the same idea twice, which is minor waste but the only real redundancy.

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

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

No output schema exists, and the description compensates by naming the return payload (text, detected language, duration, segments with start/end seconds). Combined with formats, limits, model options, cost and latency, 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 baseline is 3, but the description adds meaning beyond it: the language auto-detect behavior (~100 languages), the mutual-exclusivity framing of audio_url vs audio_base64, and the supported container formats (mp3, mp4, m4a, wav, ogg, webm, flac). It stops short of richer per-parameter detail, so not 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?

Opens with a specific verb+resource ('transcribe ... into text with timestamps') and names the concrete input types (voice note, meeting, podcast, call recording) and the engine (OpenAI Whisper). It is unmistakably distinct from siblings like tts (opposite direction) or language_detect.

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 use ('Speech to text for agents') and names an alternative access path (OpenAI-compatible POST /v1/audio/transcriptions). It does not, however, state when NOT to use it or route the agent to a sibling tool, 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?

With no annotations the description carries the full burden, and it delivers real operational context: output format (PNG base64), check-digit validation for EAN/UPC, cost ($0.0025 USDC per call) and p99 latency (300ms). It stops short of describing error behavior for invalid input or the maxLength constraint's failure mode.

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

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

A single dense, front-loaded paragraph: purpose first, then formats, then validation, use cases, params, cost and latency. No filler sentences, though the packed enumeration makes it read as a spec dump rather than prose.

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

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

With no output schema, the description correctly states the return form (base64 PNG) plus cost and latency, and it covers all four parameters, so an agent can invoke it correctly. Minor gaps remain around input-length limits and failure modes for invalid check digits.

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 documented in the schema), so the description must compensate and largely does: it names all four params, marks text as required, gives scale's range and default, and explains include_text as 'human-readable text under the bars' — semantics absent from the schema. It adds no format examples for type-specific inputs (e.g. EAN-13 length rules).

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 supported symbologies, so the agent knows exactly what comes back. It does not differentiate from the sibling 'qr_code' tool even though qr is listed as one of its types, leaving a small overlap ambiguity unresolved.

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

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

'Use for labels, shipping, inventory, tickets or invoices' gives concrete usage contexts rather than a bare restatement of the name. There is no exclusion or routing guidance, however, so the agent is not told when to prefer qr_code over this tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost ($0.003 USDC per call), latency (p99 3000ms), the scope restriction to Bitcoin mainnet, and the supported address types (bc1/SegWit/Taproot, 1, 3). It does not explicitly state read-only semantics or error behavior for an invalid/non-mainnet address, which keeps this from a 5.

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

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

The purpose and output inventory are front-loaded, followed by practical metadata (cost, latency). It reads as a dense run-on sentence, but nearly every clause (output fields, network scope, price, latency) carries real decision-relevant 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 no annotations, so the description must compensate — and it does by enumerating the returned fields in detail plus cost, latency, and network scope. Remaining gaps (failure modes for bad addresses, whether results are paginated beyond the limit param) are minor for a simple two-parameter 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 description coverage is 100%, so both parameters are already documented, including the limit range (0–25) and default. The description mentions 'the latest transactions' and the address types but adds no syntax, format, or constraints beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Bitcoin address lookup') and enumerates the exact outputs (confirmed/pending balance in BTC and USD, total received/sent, tx count, latest transactions with net amount, confirmations, fee). That resource-and-output framing cleanly separates it from siblings like btc_tx (a single transaction), btc_fees, btc_watch (monitoring) and evm_balance (different chain).

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

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

Gives concrete usage context: 'Use to check a payment, a treasury or a counterparty wallet.' That is clear when-to-use guidance, but it names no alternative or exclusion (e.g., use btc_watch instead for ongoing monitoring), so it stops short of a full when/when-not routing 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?

With no annotations, the description carries the full burden and does well: it discloses the cost ($0.002 USDC per call) and p99 latency (2000ms), which are behavioral facts not available anywhere else. It stops short of stating authentication requirements or rate limits, and read-only status is only implied rather than declared.

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 and the cost/latency facts are appended usefully. The opening 'Bitcoin Fee Estimate — Bitcoin fees right now' is slightly redundant, and the return-value list is a dense run-on sentence, but overall it is appropriately sized for a no-parameter data 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 compensates by enumerating the return fields explicitly, and it adds cost and latency metadata. For a zero-parameter, annotation-free data fetch, 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?

The tool takes zero parameters, so there is nothing for the description to clarify about inputs. Baseline 4 applies; no parameter-level gaps exist.

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+resource (Bitcoin fee estimate) and enumerates exactly what it returns: recommended sat/vB for next block, 30 min, 1 hour, economy, USD payment cost, mempool size, tip height, difficulty adjustment, and BTC price in USD/EUR. The explicit 'Bitcoin' scoping naturally separates it from the sibling gas_price (EVM). An agent can tell what this tool delivers 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?

It gives a clear when-to-use trigger: 'Call before sending a Bitcoin transaction.' That is actionable context. However, it names no when-not conditions and no alternatives (e.g., gas_price for EVM chains, crypto_prices for spot prices), so routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the privacy model ('only a salted hash leaves our server'), the asynchronous anchoring behavior ('within hours'), cost ($0.005 USDC per call), and p99 latency (5000ms). It also explains the return artifact (standard .ots proof) and that it is verifiable with the open-source ots 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?

A single dense but front-loaded paragraph: the core action and inputs come first, with cost and latency correctly deferred to the end. It is slightly packed with operational facts, but every clause (privacy, cost, latency, companion tool) earns its place.

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

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

With no output schema, the description must explain the return value, and it does (a base64 .ots proof, plus the block/proof via the verify tool). Cost, latency, privacy, and the verification workflow are all covered, so an agent has everything needed to call it and interpret the 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 coverage is 100% with all three parameters individually documented, so the schema already does the heavy lifting. The description restates the accepted input types (text, SHA-256 hash, URL) but adds no syntax, format, or precedence details beyond it, matching the baseline 3.

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

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

States a specific verb and resource ('Timestamp anything on Bitcoin with OpenTimestamps') and enumerates accepted inputs (text, SHA-256 hash, URL) plus the output artifact (.ots proof, base64). It also explicitly distinguishes itself from the sibling btc_timestamp_verify by describing that tool's role, so an agent can tell them apart.

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 cases (contracts, AI outputs, datasets, invoices, web evidence) and names the downstream companion tool (btc-timestamp-verify) for the verification step. It does not, however, state when to prefer a different notarization sibling such as iota_notarize, so exclusions are absent.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the upgrade-from-calendars side effect, the merkle-root attestation check against the real block, the returned statuses (confirmed/pending), and — unusually — cost ($0.003 USDC per call) and p99 latency (5000ms). These are exactly the operational facts an agent needs and cannot infer.

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

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

A single dense sentence that front-loads purpose and input source, then adds the upgrade/check behavior, return values, and cost/latency at the end. Every clause earns its place, though the run-on construction is heavier 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?

No output schema exists, and the description compensates by enumerating the return payload (status, block height/time, upgraded proof, match result). Combined with the disclosed cost and latency and full parameter coverage, nothing an agent needs to call this 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, and the description adds genuine meaning by explaining that text, hash, and url exist to check whether the caller's content 'matches' the timestamped proof. That ties the optional comparison params to their purpose rather than restating their 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 (verify) and resource (OpenTimestamps proof / Bitcoin attestation) and explicitly scopes the input source ('from btc-timestamp or any ots client'), which cleanly separates it from the sibling btc_timestamp that creates proofs. An agent can identify the tool 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 makes clear this is the verification counterpart to btc-timestamp and accepts any ots client's proof, giving strong context for when to reach for it. It stops short of explicit when-not guidance (e.g. what to do with an already-confirmed proof or non-ots input), so it is clear 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?

No annotations are supplied, so the description carries the full burden and does well: it discloses a per-call cost ($0.002 USDC) and p99 latency (3000ms), and enumerates the result contents including mempool vs confirmed status and RBF signal. It stops short of stating read-only/safety semantics explicitly, but a lookup verb plus billed read is unambiguous.

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 result fields, then use cases, then cost/latency in a compact block with no filler. The return-field enumeration is dense but each item earns its place since there is no output 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?

Covers purpose, when to use, return contents, pricing and latency for a single-parameter tool with no output schema. Missing only an explicit note on error behavior for unknown txids or mempool-only transactions, which is minor given the field list already implies those states.

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 documents txid as a 64-char hex string. The description only restates 'by txid', adding no format, validation, or edge-case guidance (e.g. what happens if the txid is unknown). 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 (Lookup) plus resource (Bitcoin transaction by txid) and lists the exact data returned. The 'Bitcoin' qualifier cleanly separates it from evm_tx, sui_tx, iota_tx and tron siblings in the tool list.

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

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

Gives two concrete triggers: confirming a payment arrived, and diagnosing a stuck transaction. It does not name the adjacent alternatives (e.g. btc_address for address-level balance), so an agent must still infer which sibling to pick, but the usage context is 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?

No annotations are provided, so the description carries the full burden, and it delivers well: cursor round-trip semantics, first-call behavior, returned fields, per-call cost, and p99 latency. It omits failure modes, rate limits, and any auth requirements, which keeps it from a 5.

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

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

Three tightly packed sentences with zero filler: purpose and return shape first, usage next, cost/latency last. Every clause carries information an 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 annotations and no output schema, the description must carry the entire burden, and it does: it names the returned fields, explains the streaming/cursor model, and quantifies cost and latency. 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 67% (address and cursor documented, limit has only a default). The description adds real meaning for cursor beyond the schema's one-liner by explaining the first-call/next-call handoff. The limit parameter remains unexplained in both places, so it is not a full 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), resource (Bitcoin address), and an unusual scope qualifier (loop, only new transactions since last call). This clearly distinguishes it from siblings like btc_address, btc_tx, and wallet_watch, which do not do incremental polling.

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 cases (deposit detection, treasury/whale watching) that tell the agent when this tool fits. It does not explicitly name a sibling alternative or state when not to use it (e.g., versus btc_address for a one-off balance check), so it falls 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?

With no annotations, the description carries the full burden and does so well: it discloses the rendering environment (headless Chromium), a security-relevant guarantee (no external requests), the return payload (image_base64 PNG), per-call cost ($0.009 USDC) and p99 latency (6000ms). These are exactly the traits an agent 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 the core action, then formats, then input modes, then params, then cost/latency — a sensible ordering with little waste. It is dense and mostly one long paragraph, but every clause (cost, latency, no external requests) earns its place.

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

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

For an 8-parameter tool with nested objects and no output schema, the description covers all inputs, the two usage modes, the return format, and the operational cost/latency profile. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is only 13%, so the description must compensate, and it does: it explains the config-vs-shortcut relationship and the datasets [{label, data}] shape that the schema leaves opaque. It partly repeats the width/height ranges and defaults already visible in the schema, keeping it from a top score.

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

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

States a precise verb+resource ('Render a chart to PNG from JSON') and enumerates the supported chart types, which immediately separates it from generic siblings like diagram_render or satellite_image. An agent knows exactly what it produces (a PNG chart) 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 invocation context by spelling out the two modes: a full Chart.js 'config' or the shortcut 'type + labels + datasets + title'. It does not, however, state when NOT to use it or name an alternative sibling (e.g. diagram_render), so it stops short of explicit 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?

With no annotations present, the description carries the full burden and does so: it discloses cost ($0.005 USDC per call), latency (p99 10000ms), upstream sources (Crossref, OpenAlex, DataCite), the retraction data source (Retraction Watch), and the full set of status outcomes returned. This is unusually rich disclosure for a read-only verification 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 and scope are front-loaded before the long em-dash run of return fields, so the essential information lands first. The middle section is dense and run-on, packing output statuses into a single sprawling sentence, but nearly all of it is load-bearing given the absence of an output 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 and no annotations, the description still explains what comes back per citation (matched record, corrected issues, APA reference, retraction flag with notice date), plus cost, latency and source provenance. Nothing an agent needs to decide to call it or interpret results 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%, so the description must add meaning, and it does: it clarifies the citations cap ('up to 10 citations per call'), the accepted input formats (reference strings in any style, DOIs, or {title, authors, year, doi}), and the alternative single-doi/single-title path. It adds concrete format semantics beyond the schema's type declarations.

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 opening clause states a specific verb and resource ('Citation Check ... Verify references'), and the parenthetical 'Hallucinated and Retracted References' scopes it tightly. This clearly distinguishes it from siblings like paper_search or answer_with_sources, which discover or cite sources rather than validate them.

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

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

It gives an explicit use condition ('before you publish or rely on them') and a target audience ('agents that write reports, papers or answers with sources'). It does not name a specific alternative sibling or state when NOT to use it, so it falls 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?

With no annotations at all, the description carries the full behavioral burden and does so unusually well: it discloses return structure (key_facts as plain sentences, every section in full, plus a checks map reporting ran/skipped/failed), billing ($0.03 USDC per call), the no-charge-on-empty-result rule, and p99 latency of 15s. Those are exactly the non-obvious traits an agent needs to decide whether to call and how to interpret partial results.

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 first clause identifies the tool and its one-call value immediately, and the source enumeration, audience, routing rationale, and cost/latency tail each carry information. It is dense and a bit long, but no sentence is filler; only the six-source list borders on over-enumeration given sections are described later.

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

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

No output schema exists, so the description must explain returns — and it does, describing key_facts, full sections, and the checks map. All six optional parameters are covered, the entry requirement is stated, and pricing/latency plus partial-failure semantics round out everything needed to call 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 per-parameter meaning is already handled, but the description still adds cross-parameter guidance the schema cannot express: at least one identifier is required, name+domain produces the fullest brief, and the VIES caveat about countries like DE returning no name explains why name should be sent alongside vat_number. That is genuine semantic value beyond the schema.

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

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

The description names a specific verb+resource (company check/KYB plus enrichment) and enumerates exactly what the brief contains — LEI legal entity data, VIES VAT, OFAC/EU/UN sanctions, RDAP/MX/SPF/DMARC, tech stack, news. It explicitly positions itself against six named siblings (company-lookup, vat-validate, sanctions-screen, domain-check, tech-stack, news-search), so an agent can tell what it aggregates 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?

It gives concrete use cases (supplier/customer onboarding, lead qualification, due diligence, sales research, European companies) and states the entry condition — at least one of name, vat_number, lei or domain, with name+domain giving the fullest brief. The cost-based routing note against single-purpose siblings is a clear alternative signal. It does not, however, distinguish itself from the closely related kyb_check and company_enrich siblings, which is the remaining gap.

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

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

With no annotations, the description carries the full burden and delivers: per-call cost ($0.01 USDC), p99 latency (20000ms), a billing exception (not charged when no imprint or company data found), live VIES and LEI/Global LEI Index checks with exact-name-match caveat, and a deliberate data omission (names of natural persons). This is unusually rich operational disclosure.

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

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

One dense paragraph with essentially every clause carrying information, and purpose is front-loaded. It would be easier to scan with light segmentation (returns, billing, constraints), but there is little true filler to cut.

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, yet the description enumerates the returned fields (legal name and form, address, phone, email, HRB/HRA with court, FN, UID, VAT ID, LEI status), so an agent knows what comes back. Cost, timing, scope, and data-handling caveats are all 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% and the single parameter already documents 'Company domain or website URL, e.g. zalando.de'. The description's 'Send domain, e.g. zalando.de' reinforces but adds no meaning beyond the schema, 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 (enrichment) and resource (company) with an explicit geographic scope (DE, AT, CH) and enumerates the exact returned fields. It reads the imprint/Impressum, which is a distinctive mechanism that separates it from generic siblings like company_lookup or company_brief.

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

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

Names concrete use cases (lead enrichment, CRM cleanup, supplier onboarding, KYB) and the geographic boundary acts as an implicit when-to-use constraint. However, it never routes the agent to siblings such as company_lookup (non-DACH), vat_validate, or kyb_check, so the alternative-selection guidance is incomplete.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost ($0.009 USDC per call), p99 latency (3000ms), the read-only lookup nature, and the mutual requirement of name/lei. It doesn't mention rate limits, auth/payment prerequisites, or pagination behavior, which keeps it out of the top tier.

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 action and data source, then search modes, then params, then cost/latency in a compact trailing clause. Every sentence carries actionable information and there is no filler.

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

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

For a 4-parameter tool with no annotations and no output schema, the description covers what it returns, how to invoke it, and the operational cost/latency profile. The main residual gap is that payment/auth mechanics for a paid endpoint ($0.009 USDC) aren't explained, but overall it is sufficient to call the tool correctly.

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

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

Schema coverage is 75%, and the description adds real value on top: it states 'name or lei (one required)' — a constraint the schema does not encode since zero parameters are marked required — and documents country as ISO2 and limit as 1–20 with default 5. It adds meaning beyond the raw schema rather than merely 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 (find/fetch) and resource (companies in the Global LEI Index), plus the exact fields returned (legal name, LEI, jurisdiction, register number, addresses, status, founding date). It's a highly concrete purpose, but it never names or contrasts with adjacent siblings like company_brief, company_enrich, or kyb_check, so sibling differentiation is left to the agent to infer from the 'LEI/GLEIF' framing.

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

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

It clearly explains the two operating modes — 'Search by name (optionally filtered by country) or fetch one LEI' — with the constraint that name or lei is required, which is genuinely useful routing info. However, it offers no explicit when-not-to-use or alternative-tool guidance, so it stops short of the 5 tier.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does well: it discloses the cost ($0.0025 USDC per call), p99 latency (3000ms), the ranking/merging logic, and the exact fields returned per article. It stops short of saying whether results are paginated or what happens on an empty match, but the pricing and latency disclosure is genuinely useful context.

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

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

Front-loaded with purpose, then output shape, then parameters, then cost/latency – a sensible ordering. It is dense but not padded, with the minor inefficiency of listing the source outlets twice (once in prose, once in the params line).

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 and no annotations, the description does the heavy lifting: it enumerates returned fields, filtering options, defaults, cost, and latency. Only minor gaps remain (pagination/empty-result behavior). Adequate for a 5-parameter, zero-required read tool.

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

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

Schema description coverage is only 40% (hours, limit, and sources carry no schema description), and the description compensates by naming all five parameters with example values (['BTC','ETH']), lookback range 1-168 default 48, limit 1-50 default 20, and the source list. It adds real meaning beyond the bare schema, though it largely restates the enum and bounds already present in structured fields.

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 ('Latest crypto news'), names the five upstream outlets, and explains the distinguishing feature: merged and ranked with duplicate stories grouped and boosted. An agent can tell this apart from news_search, news_sentiment, or rss_fetch 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?

The description says 'Filter by coins (tickers) or keywords,' which implies how to scope a call, but never states when to use this versus the many sibling news tools (news_search, rss_fetch, discussion_search, news_sentiment). Usage is inferable but there are no explicit alternatives or exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (DefiLlama), the cost ($0.002 USDC per call), and p99 latency (500ms), which are exactly the operational traits an agent needs before invoking. It omits failure behavior and whether a payment/auth precondition is required to spend USDC.

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 summary followed by a numbered mode list and a compact params/cost/latency line; nearly every clause carries information. It is dense and slightly repetitive ('Crypto Price Lookup — Crypto price and token price lookup') but not 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 or annotations exist, so the description must stand alone; it covers input modes, accepted identifier formats, target currencies, source, cost, and latency. The main omissions are response shape and error/empty-result behavior, plus the unresolved 50-vs-25 limit conflict.

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 all four parameters with examples and defaults; the description correctly recaps currencies default and the chain:address format. However it states 'up to 50' coins while the schema caps at 'Max 25 coins per call', a direct numeric conflict that could cause an agent to build an over-limit request, so no credit above the schema-driven baseline.

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

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

Names a specific verb and resource ('crypto price and token price lookup', live spot price and 24h change) and enumerates the three input modes (coins, tokens, historical via `at`) with concrete examples. An agent can distinguish this from siblings like exchange_rates, crypto_news, or defi_tvl 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?

The three modes are clearly stated with the condition that selects each (coingecko IDs/tickers for coins, chain:address for any DEX-traded token, `at` for historical USD prices), which is strong routing guidance. It stops short of naming when NOT to use it (e.g. fx-rate conversion vs exchange_rates, or token safety vs token_security/token_verdict).

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

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

With no annotations, the description carries full behavioral burden and does well: it discloses data sources (NVD, OSV), the shape of returned fields (description, CVSS score/vector, CWE, CISA known-exploited flag; affected packages, fixed versions), plus cost ($0.009 USDC/call) and p99 latency (4000ms). It omits auth requirements and error/failure behavior, which for a paid external-API tool would be valuable.

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

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

Single dense paragraph that is front-loaded with the purpose and mode split, then parameters, then cost/latency. Nearly every clause earns its place; the parenthetical data-source inventory and ecosystem list are dense but informative rather than 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 appropriately explains returned data for both modes, and it covers the two most commonly missing metadata classes (cost and latency). Gaps remain around auth/quota requirements and exact error semantics for a paid third-party-backed call, but an agent has enough 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 only 40% (package and version are undocumented in the schema), so the description must compensate and largely does: it names all five parameters, defines the two usage modes, and adds the meaningful hint that version is 'recommended'. It does not clarify flag precedence or that limit applies only to the package-check mode, but it adds real value over 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 and clearly enumerates two distinct modes: lookup by CVE/GHSA id and package-version vulnerability check, naming data sources (NVD, OSV). However, it does nothing to differentiate from the sibling 'package_check', which appears to overlap with the package-vulnerability mode, leaving an agent to infer the boundary.

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 'cve_id, or package + ecosystem (+ version, recommended)' phrasing implies which parameter combination to use for each mode, which is useful. But it offers no explicit when-to-use vs when-not, no prerequisites, and no routing against the overlapping 'package_check' sibling.

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

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

With no annotations, the description carries the full burden and does disclose two high-value traits: per-call cost ($0.002 USDC) and p99 latency (4000ms), plus a rough sketch of what each mode returns. It omits error behavior, caching/rate limits, and result pagination shape.

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

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

One dense, front-loaded paragraph organized as mode: meaning, followed by a compact params and cost/latency line. Every sentence carries information; there is no filler.

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

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

For a 5-param read tool with no output schema or annotations, the description supplies mode semantics, defaults, cost and latency, which is close to self-sufficient. Return-value structure, error cases, and any per-mode limit behavior are 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 only 60%, and the description compensates by explaining every parameter, including the non-obvious conditional default ('default top, or protocol if protocol is given') that appears nowhere in the schema. Chain, category, protocol and limit constraints largely repeat what the schema already states, keeping this short of 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 the specific resource (DeFi TVL / DEX volume from DefiLlama) and decomposes it into four named modes with the exact metrics each returns. An agent can tell this apart from siblings like defi_yields or crypto_prices 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?

Each mode is paired with the question it answers (protocol breakdown, top rankings, chain rankings, DEX volume), and it documents the default-selection rule for mode. It stops short of naming alternatives (e.g. defi_yields for yield data) or stating when not to use it.

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

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

With no annotations, the description carries the full burden and does well: it discloses outlier exclusion behavior (DefiLlama flags or >500% APY), the include_outliers override, per-call cost ($0.0055 USDC), and p99 latency (4000ms). It stops short of stating read-only/non-destructive status, rate limits, or result ordering/pagination.

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

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

One dense paragraph, front-loaded with the purpose and data source before filters, defaults, and cost. Nearly every clause earns its place, though the run-on filter list is slightly hard to scan.

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

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

For an 8-param tool with no output schema and no annotations, the description is strong: it enumerates return fields (base/reward APY, 30-day mean, 7-day change, TVL, stablecoin flag, IL risk) and covers almost all inputs. Missing only limit behavior and result ordering, which an agent would need to predict result count.

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 38%, so the description must compensate, and it does for 7 of 8 params: chain, project, symbol examples, stablecoin_only, min_tvl_usd default, sort enum values, and include_outliers. The 'limit' parameter (default 10, max 50) is never mentioned, 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+resource ('Find DeFi yield pools') plus concrete scope (400+ protocols, 100+ chains, DefiLlama data), which cleanly separates it from neighbors like defi_tvl, token_liquidity, or crypto_prices. An agent can tell what it returns (APY split, TVL, IL risk) 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: available filters, sort default ('apy'), min_tvl_usd default (1,000,000), and outlier exclusion rules. However, it never names an alternative sibling or states when NOT to use this tool (e.g., vs defi_tvl for protocol-level TVL), 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?

With no annotations, the description carries the full burden and does so well: it discloses per-source isolation ('each source returns its own list'), graceful degradation ('a source that is rate limited reports an error without failing the call'), cost ($0.0045 USDC per call), and p99 latency (5000ms). These are exactly the traits an agent needs for planning and budgeting.

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 failure semantics, then params, then cost/latency. Dense but nearly every clause earns its place; only minor tightening of the source list prose would help.

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 no-output-schema, no-annotation aggregation tool, the description covers params, per-source result shape ('its own list'), failure behavior, cost, and latency. Return-field granularity is not described, but that is largely outside a description's remit here.

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%, so the description must compensate, and it fully does: it names query as required, enumerates the sources default set, and gives limit's range (1-20) and default (5). Every parameter's meaning and defaults are recoverable from the text alone.

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

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

States a specific verb (Search) and resource (developer sources) and enumerates exactly which sources are queried: Hacker News, GitHub, npm, PyPI, Stack Overflow. This clearly distinguishes it from generic siblings like web_search, news_search, and discussion_search without opening a schema.

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

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

The phrase 'in one call' implies the aggregation value over single-source tools, and the PyPI note explains a source-specific limitation, but the description never states when to choose this over siblings such as web_search, package_check, or discussion_search, nor when to exclude a source. Usage is implied, not prescribed.

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

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

With no annotations provided, the description carries the full disclosure burden and does well: it states the failure mode (HTTP 400 + Mermaid parse error), that failed calls are not charged, the cost ($0.01 USDC/call), and p99 latency (6000ms). What it omits — return payload shape, whether results expire or are hosted — 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?

Front-loaded with purpose in the first clause, then errors, params, and operational facts in terse colon-delimited fragments. No sentence is wasted and nothing redundant is included.

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 no-annotation, no-output-schema render tool, this covers the essentials an agent needs: supported input language, error semantics, cost, latency, and all meaningful parameters. The only real gap is the undocumented 'background' parameter and unspecified return/URL handling.

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%, so the description must compensate, and it largely does: code (required), format (svg default, png or both), theme (five named options), width (200–4000, default 1200) are all restated with meaning. Only 'background' is left unexplained in both schema and description, holding it back 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+resource ('Render Mermaid diagram code to SVG and/or PNG') immediately, and enumerates the concrete diagram types supported (flowchart, sequence, class, state, ER, gantt, pie, mindmap, timeline). This clearly distinguishes it from near-siblings like chart_render and html_to_pdf without the reader 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?

It gives useful operative guidance — invalid syntax returns HTTP 400 with the parse error and is not charged, so an agent can fix and retry — which shapes retry behavior. However, it never states when to choose this over chart_render or doc_convert, so the sibling routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does so: it discloses partial-failure semantics ('A source that is down reports an error without failing the call'), the exact return shape (title, snippet, linked URL, discussion URL, author, points, comment count, date, up to 5 top comments, plus an aggregate summary), the per-call cost ($0.006 USDC) and p99 latency (6000ms). These are the operationally relevant facts an agent needs and none are derivable 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?

The purpose, scope exclusions, return shape, parameters, cost and latency are all packed into one dense paragraph with the most important information front-loaded and zero filler sentences. It reads as a wall of text rather than being broken into scannable clauses, which costs it a point but nothing in it 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?

For a 7-parameter federated-search tool with no annotations and no output schema, the description covers everything an agent needs: what it searches, how to call it, the one-of requirement on query/url, per-source limits, failure behavior, and the fields returned including the aggregate summary. Nothing material is left to inference.

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% and the schema lists zero required parameters, yet the description supplies the missing semantics: it states that query or url is required (one of the two) — a constraint the schema does not express — and enumerates defaults and ranges for sources, sort, days (1–3650), limit (1–20, default 5) and comments (0–5, default 2). This is a genuine compensation for the coverage gap rather than a restatement.

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 opens with a specific verb+resource ('Find out what people say about a topic or a specific link') and immediately names the three sources it federates (HN, Bluesky, Lemmy) plus the two search modes (keywords or URL). It distinguishes itself from the many other search siblings (news_search, web_search, dev_search, search_read) by scoping to social-discussion sources and by explicitly excluding Reddit and X.

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 concrete use cases ('product launches, articles and competitors') and states the URL mode 'finds every thread that shared that link', which tells the agent when URL input beats keyword input. It also rules out Reddit and X, which prevents mis-selection. It stops short of naming an alternative sibling to use instead, so it is clear context without explicit 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?

With no annotations, the description carries the disclosure burden and does well: it states the return shape ('records object with array per type'), the default type, supported types, cost, and p99 latency. It omits auth requirements, broader rate-limit behavior, and failure modes, so it is not fully complete.

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 supported record types, then adds operational details—return shape, cost, latency—without filler. The few repeated schema details are useful for quick scanning and do not make it verbose.

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

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

For a low-complexity read tool with no output schema, the description supplies the key return shape, default behavior, supported types, cost, and latency. Exact response field structure and error behavior are not detailed, but the definition is sufficient for selection and 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%, and the schema already documents both 'domain' and 'types' with the enum and default. The description reinforces the default and supported types but adds no syntax or semantic detail beyond the schema, 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: 'Resolve DNS records for any domain.' It enumerates the supported DNS record types, making its domain-record focus distinct from adjacent tools like whois, ssl_check, and domain_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 positive triggers: verify mail server setup with MX, check domain ownership with TXT, and debug DNS propagation. It does not provide when-not-use guidance or name alternative sibling tools such as whois or domain_check.

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

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

With no annotations, the description carries the full burden and does so well: it discloses cost ($0.01 USDC/call), p99 latency (8000ms), a 10 MB size cap, the output representation (text as content, binary as file_base64), and a real limitation ('Local file includes and remote images are not loaded'). It stops short of describing auth/payment mechanics or failure modes, so it is strong but not exhaustive.

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

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

Dense but front-loaded: purpose and format list come first, then input modes, output behavior, limitations, params, and cost/latency. Every clause carries information, though the trailing 'Params:' enumeration partially restates the schema rather than only adding to it.

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

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

No output schema exists, and the description explains the return shape (content for text outputs, file_base64 for binary outputs), which is exactly the missing piece. Combined with cost, latency, size limits, and format coverage, an agent has what it needs to call this 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%, and the description compensates by listing to (required), the mutually exclusive input options (content OR file_base64 OR url), from, and title, and by clarifying which formats file_base64 accepts (docx, odt, epub, rtf) plus the 10 MB limit. The mutually-exclusive input pattern is documented in prose only, which adds genuine value over 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 ('Convert documents between formats with pandoc') and enumerates the supported formats and input modes. An agent can tell this apart from extraction siblings like doc_parse or pdf_extract, which take a document and return one form rather than converting between arbitrary formats.

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 on how to invoke it: choose text (content), binary file (file_base64), or url, and the input format is detected automatically or forced via from. It does not, however, name alternatives or state when NOT to use it (e.g. vs doc_parse or html_to_pdf), 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?

No annotations are provided, so the description carries the full burden and delivers well: it discloses cost ($0.009 USDC per call), p99 latency (6000ms), the 10 MB input cap, and the exact shape of the returned metadata and Markdown. It stops short of auth/permission requirements and error behavior, keeping it out of the top band.

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 action, then formats, return shape, alternatives, params, and cost/latency in a tight sequence. Dense but every clause — format list, exclusions, one-of constraint, pricing — earns its place.

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

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

With no output schema, the description correctly enumerates the return fields (title, author, date, language, word count, outline, table/image counts, Markdown). Combined with formats, limits, cost, and latency, 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?

Schema description coverage is only 20% (just the base64 10 MB note), so the description must compensate, and it does: it states that file_base64/url/content are mutually exclusive with one required, and gives max_chars bounds and default. The 'from' parameter is named but never explained, leaving a real 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 with metadata') and enumerates the exact formats accepted. It actively differentiates from siblings by naming pdf-extract as the PDF route and declaring PPTX/XLSX out of scope, so an agent can route correctly without opening another 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 PDFs to pdf-extract and rules out PPTX/XLSX, which is precisely the when-not-to-use guidance an agent needs among a large sibling set. Usage is unambiguous for the formats it does support.

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

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

With no annotations, the description carries the full burden and does add real operational context: explicit cost ($0.009 USDC per call), p99 latency (5000ms), and the DNS-fallback behavior for TLDs without RDAP. It does not touch auth, rate limits, or failure modes, but the cost/latency disclosure is substantive beyond the schema.

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

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

Everything fits in a tight, front-loaded block: purpose and scope first, then the parameter, then cost and latency. No filler sentences and each clause carries a distinct fact.

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 correctly describes the return surface (0–100 score, grade, findings) along with the input and the composite scope. For a one-parameter tool this is nearly complete, missing only explicit sibling routing.

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

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

Schema description coverage is 100% with a single required 'domain' parameter, so the schema already documents the input. The description only restates 'domain (required)' and adds no format or syntax detail beyond the schema's 'e.g. example.com'.

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 (check a domain) and enumerates the concrete sub-checks it aggregates: RDAP registration data, DNS records, and email security (SPF/DMARC/DKIM). This implicitly distinguishes it from single-purpose siblings like whois or dns_lookup by framing it as a one-call composite, though it never names those alternatives outright.

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

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

The phrase 'in one call' implies this is the preferred bundle over running individual lookups, but there is no explicit when-to-use/when-not guidance and no mention of alternatives (whois, dns_lookup, email_validate). Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses pricing ($0.06 USDC per call), worst-case latency (p99 40000ms), the geographic constraint that limits applicability, the non-billing behavior on a failed lookup ('Not charged'), and the shape of what comes back. An agent knows cost, risk, and outcome 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?

Four sentences, all front-loaded with the highest-value information first (what it does, then when to use it, then the failure/fallback path, then cost and latency). No filler, no restatement of the name or title.

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 must describe return values, and it does: grade A–F, verdict, reasons, sanctions, VAT, domain security. Combined with the documented precondition, error path, price, and latency, an agent has everything needed to call this correctly and interpret the 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 100% (the single 'domain' param is documented with an example, e.g. example.de). The description adds the implicit constraint that the domain must belong to a site with a DACH imprint, which is useful context, but no format or syntax detail 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?

Opens with a specific verb+resource (domain to company compliance check) and spells out the exact mechanism: read the imprint, resolve the legal entity, run a KYB check. It also names the distinct output artifacts (grade A–F, ALLOW/CAUTION/BLOCK, sanctions, VAT, domain security), which separates it from siblings like company_lookup 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?

Explicitly states the use case ('vet a counterparty from its website'), the precondition (imprint required, DACH only: Germany, Austria, Switzerland), the failure mode when that precondition is unmet ('errors with Not charged'), and the exact fallback ('then use kyb-check with the company name'). This is the full when/when-not/alternative triad.

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

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

With no annotations, the description carries the full burden and does disclose useful non-schema traits: the return contract (is_valid boolean plus granular checks), per-call cost ($0.0035 USDC), and p99 latency (400ms). It does not cover auth/payment mechanics for the paid call, rate limits, or error behavior, so it falls short of fully transparent.

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

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

Single dense paragraph, front-loaded with the purpose, then returns, then usage, then cost/latency — a sensible order. The leading 'Email Validation —' restates the tool name and is the only mildly wasted text.

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

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

No output schema exists, and the description correctly compensates by naming the return fields. Cost and latency round out the picture for a simple one-parameter tool. The main omission is disambiguation 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?

One parameter at 100% schema description coverage, so the schema already defines 'email' fully. The description adds no format, normalization, or edge-case guidance beyond what the schema states, matching the baseline of 3.

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

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

States a specific verb and resource and enumerates the four concrete checks performed (RFC 5322, MX lookup, disposable provider, role address) plus the return shape. However, it never addresses the near-identical sibling 'email_verify', so an agent cannot tell from the description alone which of the two to call.

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

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

Gives a clear use case ('before storing or sending to email addresses to prevent bounces'), which is genuine context. But with a sibling literally named email_verify in the toolset, the absence of any when-to-use-this-vs-that guidance is a material gap.

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

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

With no annotations, the description carries the full burden and does so: it states no email is sent (safety), that results are cached 6 hours, the exact cost ($0.0025 USDC) and p99 latency (15000ms). This is unusually rich behavioral disclosure that goes well beyond the 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 but well front-loaded: purpose first, then statuses, then use cases, then operational facts (cache/cost/latency). Every clause carries information the agent needs, with only mild redundancy in the title-like opening.

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 full return vocabulary (deliverable, undeliverable, catch_all, risky, unknown) with definitions for each. Cost, caching and latency round out everything an agent needs before calling.

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 single 'email' parameter is already documented as 'Email address to verify.' The description's 'Params: email (required)' repeats the schema without adding format or syntax detail; baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb+resource ('checks whether an email address really exists') and the mechanism (SMTP RCPT TO probe), so the agent knows exactly what the call does. It does not explicitly differentiate from the sibling email_validate, which is the main ambiguity for selection.

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 contexts: 'before sending outreach, to clean lead lists or to block fake sign-ups.' However it names no alternative or exclusion, and the sibling email_validate is never mentioned, so the choice between the two 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?

With no annotations, the description carries the full burden and does disclose cost ($0.0045 USDC per call), latency (p99 2000ms), and a real behavioral trait (verifies the target is a contract). It omits error/failure behavior when the address is not a contract, so it falls short of 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?

A single front-loaded block: purpose, then params, then cost/latency. Every clause carries information and nothing is redundant, though the embedded 'Params:' recital is somewhat schema-repetitive.

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 annotations and no output schema, the description compensates by enumerating the returned fields and covering all three parameters plus cost and latency. Only failure semantics and multi-chain caveats are 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 67% and the description mostly restates the schema (token required, chain default 'base', holder optional). It adds no format or semantics beyond the enum/default/pattern already present, so it sits at the baseline for a well-covered 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 ('Read an ERC20 token contract') and enumerates exactly what it returns (name, symbol, decimals, total supply, optional holder balance), which implicitly separates it from evm_balance or erc20_transfers. It never names a sibling tool, so it earns a 4 rather than a 5.

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

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

The description implies the reading-metadata use case and notes the address is contract-verified, but gives no explicit when-to-use/when-not guidance and does not route the agent away from overlapping siblings like evm_balance, erc20_transfers, or token_security. Usage 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?

With no annotations, the description carries the full burden and delivers unusually rich context: ordering (newest first), cap (up to 50), data window (last ~12000 blocks, fewer on busy tokens), cheap-but-partial caveat, cost ($0.004 USDC), and p99 latency (12000ms). These are exactly the operational facts an agent needs and none are available 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?

It is a single dense paragraph that front-loads the core purpose before scoping, cost, and latency. Every sentence carries information (range limitation, cost, p99), though the volume of trailing clauses is slightly heavy for one sentence.

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 compensates by naming the returned fields (tx, time, from, to, amount) and how the searched range is reported. All 4 params are documented and the read-only, range-limited nature is clear, making it essentially complete for a query tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: 'amount in token units' clarifies the value scale and the holder parameter is explained as filtering 'from or to one wallet'. That extra semantics on top of full schema coverage justifies the bump.

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 leads with a specific verb and resource ('ERC-20 Transfer History — Recent Transfer events of an ERC-20 token') and even enumerates the returned fields. It is unmistakably distinct from a metadata tool like erc20_info, but it never names a sibling to route the agent explicitly, so it stops short of a 5.

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

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

It offers implied usage context ('Use for quick wallet or token activity checks') and flags a limitation ('not a full history'), which helps scope the decision. However, it names no alternatives and gives no explicit when-not condition, leaving the agent to infer the boundary against tools like evm_tx or token_flows.

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

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

With no annotations, the description carries full disclosure and delivers: read-only access straight from chain, chain id 8453, per-call price ($0.002 USDC), and p99 latency (900ms). These cost/latency/authorization-relevant facts are exactly what 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?

One dense paragraph front-loads the resource and chain, then use cases, then param and cost/latency facts. Every clause earns its place; 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?

No output schema exists, and the description compensates by enumerating what is returned (ETH balance, USDC balance, transaction count, x402 call coverage). Combined with cost, latency, and chain context, 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 description coverage is 100% with a single required param whose pattern is already documented in the schema. The description repeats 'address (required, 0x...)' without adding format or semantic meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (read ETH/USDC balance of any address on Base mainnet, chain 8453) and expands scope to tx count and x402 call coverage. An agent can distinguish it from evm_tx, wallet_portfolio, or erc20_transfers 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 three concrete when-to-use scenarios (pre-paid-workflow self-check, counterparty payment verification, treasury monitoring), which is strong context. It stops short of naming an alternative tool or a when-not-to-use condition, so it does not reach 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?

With no annotations, the description carries the full behavioral burden and does much of it: it discloses the possible status values (success, failed, pending, not_found), the cost ($0.002 USDC per call), and p99 latency of 2500ms — all non-obvious operational traits. It omits auth requirements and error/quota behavior, but for a read-only chain lookup this is strong disclosure.

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

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

Front-loaded with the core action and scope, then return fields, then a compact 'Params:' and 'Cost:/Latency:' block — no filler sentences. The return-field enumeration is long but earns its place given there is no output 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 takes on the return contract by listing status, block, confirmations, timestamp, addresses, value, gas, fee, method id and decoded ERC20 transfers. Combined with parameter defaults and cost/latency, 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 50% (only 'hash' is documented in-schema; 'chain' has just an enum and default). The description compensates by restating that hash is a required 0x transaction hash and that chain defaults to 'base' with the two alternatives, adding meaning beyond the bare enum.

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 a transaction') plus the exact scope (Base, Ethereum, IOTA EVM mainnet), which cleanly separates it from the non-EVM chain siblings like btc_tx, tron_tx, sui_tx and iota_tx. It also enumerates the returned fields, so an agent knows precisely what question this tool answers.

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 usage context — 'Useful to confirm that a payment arrived' — which tells the agent when to reach for it. It stops short of naming alternatives (evm_balance, erc20_transfers, token_flows) or stating when not to use it, so it is clear context without exclusions.

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

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

With no annotations at all, the description carries the full burden and does well: it names the authoritative source (ECB), publication cadence (every working day ~16:00 CET), return shape, cost ($0.0045 USDC per call) and p99 latency (300ms). Those are exactly the traits an agent needs to decide whether to call it.

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?

Densely front-loaded with the identity and source first, then usage, then cost/latency — a sensible ordering. Minor redundancy in the opening ('Currency Exchange Rates — Currency exchange rates (forex)') that repeats the title.

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 describing the return as a rates object keyed by currency code relative to base. Cost, latency, cadence, and coverage are all present; only error/edge-case behavior (e.g. unsupported symbol) is unaddressed.

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 both parameters are already documented in the schema, including the 'empty = all' semantics. The description restates the symbols filtering and the concept of a base currency but adds no format, validation, or unsupported-currency behavior 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 resource (official ECB forex reference rates), scope (~30 currencies including USD/GBP/CHF/JPY/CNY) and capability (cross rates for any base). It does not explicitly distinguish itself from the nearby crypto_prices sibling, which the agent could plausibly confuse for currency conversion.

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 currency conversion in invoices, pricing, or financial calculations" gives concrete usage context, and it explains the symbols filter (empty = all supported). It lacks any when-not guidance or alternative routing, but the domain is narrow enough that this is a minor gap.

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

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

With no annotations, the description carries the full burden and does well: it discloses dedupe semantics, the baseline/cursor lifecycle, per-call cost ($0.003 USDC), and p99 latency (5000ms). It omits error/rate-limit behavior and auth expectations, so it stops short of a 5.

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

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

Front-loads the delta-only behavior in the first clause, then workflow, then feed types, then params, then cost/latency. The feed-type enumeration is slightly padded but each block earns its place for an agent deciding whether this tool fits.

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 and no annotations, so the description must cover return semantics, and it does: it tells the agent it gets only new items plus a cursor to persist. Error handling and what happens on cursor expiry are unaddressed, leaving a minor gap for a stateful 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 67% and the description documents all three params, adding meaning the schema lacks (e.g. 'limit = max NEW items returned' versus a plain integer, and cursor as 'from your previous call'). The range/default details it repeats are already in the schema, so this is additive but not exhaustive.

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 ('RSS/Atom Feed Monitor') and immediately scopes it as delta-only ('only new items... never the same item twice'). This distinguishes it from the rss_fetch sibling, which will not track state across calls. An agent can pick the right one 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?

Explains the when: monitoring for new items rather than one-shot retrieval, and gives concrete use cases (news, GitHub releases, YouTube, subreddits, podcasts, jobs). It also spells out the first-call-then-cursor workflow. It does not explicitly name an alternative sibling (e.g. rss_fetch) to contrast against, keeping it from a 5.

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

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

No annotations are provided, so the description carries the full burden, and it does so well by disclosing pricing ($0.002 USDC per call) and p99 latency (3000ms) upfront along with the exact data returned. It stops short of mentioning auth requirements or rate limits, keeping it from a 5.

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

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

Front-loaded with the purpose, then payload details, params, cost, and latency in a single dense but organized block. Every clause earns its place, though the run-on structure is slightly heavy.

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 and no annotations, the description fully shoulders the burden by enumerating the return fields, the cost, the latency, and the parameter default. 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 description coverage is 0%, so the description must compensate, and it does: it names 'chains' as optional with a default of all chains. The allowed chain values are already enumerated in the schema enum, so no further explanation is needed for a single well-covered 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?

Specific verb+resource: 'Current gas prices' across a named set of chains, plus a precise enumeration of the returned metrics (gas price, base fee, priority fees, native token USD, transfer cost estimates). An agent can distinguish this from crypto_prices or btc_fees immediately.

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

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

The word 'Current' implies fresh gas data and the default-all chains behavior is stated, giving implied usage. However, there is no explicit when-to-use/when-not guidance or routing to alternatives such as btc_fees or exchange_rates.

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

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

With no annotations, the description carries the burden and discloses data source, coverage size, cost per call, p99 latency, and the fact that non-geocodable parts are reported in ignored_parts. It omits auth requirements, rate limits, and error behavior, but otherwise provides rich operational context.

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

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

The description is front-loaded with purpose and scope, then moves to limitations, inputs, cost, and latency. It is slightly verbose with coverage statistics and duplication in the opening phrase, but each sentence contributes useful information.

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

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

For a utility geocoder with no annotations and no output schema, the description covers purpose, inputs, limitations, cost, and latency well enough to invoke correctly. It does not detail return fields beyond ignored_parts, but the absence of an output schema lowers the burden.

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 input schema already documents parameters with examples and the oneOf address vs lat+lon structure. The description adds example addresses but no meaningful semantics beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description clearly states forward and reverse geocoding from city/town/postal code to lat/lon and vice versa, with explicit scope and examples. It does not, however, name or differentiate against sibling tools such as postal_code, so it falls short of the full sibling-differentiation criterion.

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 usage conditions for the two modes (provide address for forward geocoding, or lat + lon for reverse geocoding) and an explicit exclusion: not street level, with house numbers and streets skipped. It does not name alternative tools to use when street-level or other needs arise.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost ($0.003 USDC per call), p99 latency (300ms), geographic coverage, and default values for year and include_observances. It omits auth requirements and return shape, 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?

Front-loaded with the core capability, then a compact parameter digest. The param list partly restates the schema, but the examples earn their place; nothing is padded.

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

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

For a 6-param read-only lookup with no output schema, the definition covers scope, modes, examples, cost and latency. The only gap is the shape of the returned holiday records, which the agent must discover empirically.

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 supplements it with concrete examples for country (DE, US, CH, JP), region (BY, CA, ZH), language (en) and date format (YYYY-MM-DD), plus explicit default semantics. It adds real value beyond the bare schema 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?

Names a specific resource (public/bank holidays) with scope (200+ countries and their regions, any year) and a secondary capability (check a date). No sibling in the list overlaps, so the agent can select it unambiguously.

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

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

The description makes the two usage modes explicit: bulk listing by country/region/year, and 'optionally check whether a given date is a holiday.' It doesn't state when NOT to use it or name alternatives, but the tool is unique among siblings so that omission costs little.

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

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

With no annotations, the description carries the burden well: it discloses return shape (pdf_base64 decoded to bytes, page_count), mutual exclusivity of inputs, cost ($0.0045 USDC/call), and p99 latency (3500ms). It omits auth requirements, error behavior, and rate limits, so not exhaustive, but strong behavioral context 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?

Front-loaded with purpose and return shape, then constraints, parameters, use cases, and operational cost/latency. Dense but every clause carries information; minor redundancy with the schema's parameter docs.

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 usefully explains return values (pdf_base64, page_count). Between this and the 100%-covered input schema, an agent has enough to invoke correctly; only ambient concerns like auth and failure modes are absent.

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 enum, landscape, and margin units. The description largely restates these; it adds no syntax or edge-case guidance 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 ('Render a URL or raw HTML string to PDF') and immediately scopes what it accepts. It is easily distinguished from sibling rendering/conversion tools like screenshot, doc_convert, chart_render, and pdf_extract.

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, or printable document generation') and an explicit constraint ('Provide url OR html, never both'). It does not name which sibling to prefer for adjacent tasks (doc_convert, screenshot), so it stops short of full when/when-not routing, but the context is solid.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses cost ($0.0045 USDC per call), p99 latency (1500ms), and the default-return behavior when coins is omitted. It stops short of stating rate limits, retry/failure behavior, or whether unknown tickers are silently dropped.

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 and dense with no filler sentences; every clause carries information. The opening repeats itself slightly ('Hyperliquid Perps Data — Hyperliquid perpetual futures market data'), a minor redundancy.

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

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

With no output schema and no annotations, the description steps in by enumerating returned fields and stating cost/latency, which is the right allocation of effort for a read-only market-data tool. It does not explain the response shape (per-coin array, ordering, units) or behavior on invalid tickers, so it is not fully complete.

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

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

Schema coverage is 50% — only 'coins' is documented in the schema — but the description compensates by covering both params and, crucially, the interaction rule that limit is 'used without coins', which the schema does not express. Valid ranges (max 50; 1–50, default 10) are restated, which is redundant but harmless.

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?

It names a specific resource and scope ('Hyperliquid perpetual futures market data') and enumerates the exact fields returned — mark/oracle price, 24h change, funding rate and APR, open interest, volume, max leverage. It is distinguishable from generic siblings like crypto_prices, though it never explicitly positions itself against perp_funding, which overlaps on funding-rate 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?

It gives conditional usage for the parameters ('Pass coins ... or omit them to get the top markets by open interest'), which is genuinely helpful. However there is no tool-level when-to-use guidance telling the agent when to reach for this instead of perp_funding or crypto_prices, 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?

With no annotations, the description carries the full burden and does so well: it discloses what is computed, which countries get enrichment (DE, AT, CH, NL, BE, LU, LI), and gives cost ($0.0025 USDC/call) and p99 latency (1500ms) — useful operational context rarely stated elsewhere. It stops short of describing failure behavior for an invalid IBAN or any auth/rate-limit details, so it is strong but not exhaustive.

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

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

A single dense sentence front-loads the validation scope before the enrichment clauses, and the trailing cost/latency note is compact and actionable. Nothing is redundant, though the sentence is long enough that the enrichment detail slightly crowds the core purpose.

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

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

With no output schema and no annotations, the description compensates by naming the returned fields (bank code, branch, account number, SEPA flag, bank name/BIC/city for supported countries), which is exactly what an agent needs to call it correctly. Error/edge-case behavior is the one notable omission.

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

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

The schema already documents the single parameter at 100% coverage ("IBAN, spaces allowed"), and the description merely restates it as "iban (required, spaces allowed)" with no format examples, country-length constraints, or normalization rules added. Baseline 3 is appropriate when the schema does all the work.

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

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

States a specific verb (validate) and resource (IBAN) and enumerates exactly what validation covers: checksum, country length, structure, split into bank code/branch/account, SEPA membership, plus country-specific enrichment for seven countries. An agent can distinguish this from the many other *_validate siblings (vat_validate, email_validate, phone_validate) purely from the text.

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 resource name — use it when you have an IBAN to check — but there is no explicit when-to-use/when-not-to-use statement and no routing to or away from sibling validators. Adequate but leaves the agent to infer the calling context.

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

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

With no annotations the description carries the full burden, and it delivers: it discloses cost ($0.005 USDC/call), latency (p99 10000ms), the internal pipeline (scaled to 800x800, described by Claude Haiku 5.5), and output-shaping behavior (under 125 chars, decorative handling). It stops short of auth requirements or error/failure behavior.

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

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

Front-loads the purpose and the output contract before the operational details, and every clause is informative. It is a dense single block, but no sentence is pure filler, so it earns its length.

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 describe returns, and it does thoroughly (short alt text, longer complex-image description, decorative flag, readable text, ready alt="..." attribute). Combined with cost, latency, and processing notes, 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 the schema already documents all four parameters, making 3 the baseline. The description adds only marginal value ('send image_url or image_base64' hints at alternation; 'optional language (e.g. German)'), without new format, size, or constraint details beyond what the schema states.

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 (generate alt text for images) and immediately scopes the purpose (WCAG 1.1.1, BFSG, EAA, SEO). It also distinguishes itself from siblings by naming accessibility-check as its complement, so an agent can tell it apart from ocr, image_resize, or accessibility_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 clear context for when to reach for it (web accessibility/SEO, and explicitly 'pairs with accessibility-check, which finds images without alt text'), which is a strong routing signal. However, it offers no explicit when-not-to-use guidance against near neighbors like ocr or image_resize.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: EXIF auto-rotation, the 4096px ceiling, per-call cost ($0.0045 USDC) and p99 latency. It omits whether the tool persists files or returns inline data, and no auth/rate-limit info is given, so it is strong but not complete.

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, then a compact parameter digest, then cost/latency. Every clause earns its place and there is 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?

Given 7 parameters, 0% annotation coverage, no output schema, and thin schema descriptions, the definition supplies most of what an agent needs. The remaining gap is the return shape (base64 vs. URL vs. file reference) and the semantics of the fit modes, neither of which is recoverable elsewhere.

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 29%, so the description must compensate, and it largely does: it declares that exactly one of image_base64/image_url is required (the schema's required list is empty, so this is genuinely new information), plus defaults and ranges for width, height, fit, format, and quality. It stops short of explaining what inside/cover/contain/fill actually do.

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 triad (resize, crop-fit, convert) and resource (images), plus the exact supported input and output formats. An agent can distinguish this from image_alt_text, satellite_image, or screenshot 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 concrete motivating scenarios: shrink screenshots before sending to a vision model, create thumbnails, or convert formats. That is clear when-to-use guidance, but it names no alternatives or exclusions (e.g., when to prefer screenshot or image_alt_text instead).

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

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

With no annotations, the description carries the full burden and does so well: it discloses the two processing paths (deterministic XML parsing vs. Claude Haiku for PDFs/photos), the validation performed (totals, EU VIES VAT ID, IBAN/BIC), the EN 16931 authenticity check, the 15 MB size limit, the $0.02 USDC per-call cost, and p99 latency of 8000ms. This is unusually rich behavioral context.

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

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

Purpose and supported formats are front-loaded, followed by method, validation, limits, and cost — a logical order. It is dense and slightly run-on with em-dash chains, but nearly every clause (output fields, processing method, cost, latency) earns its place.

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

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

No output schema exists, so the description must describe returns — and it does, enumerating number, dates, seller/buyer with VAT ID, line items, tax per rate, totals, IBAN, and payment terms. Combined with size, cost, latency, and validation disclosures, 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 description coverage is 100%, so every parameter is already documented in the schema, establishing the baseline of 3. The description corroborates the input formats and the validate behavior but adds no syntax, precedence, or mutual-exclusion detail beyond what the schema provides.

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

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

States a specific verb and resource — 'Invoice data extraction' — plus the exact input formats (PDF, photo, XRechnung/ZUGFeRD/Factur-X XML) and the JSON fields returned. It is clearly distinguishable from generic siblings like pdf_extract, ocr, and doc_parse because it is scoped to structured invoice data with accounting-specific output.

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

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

Gives clear context for when it applies: EU e-invoices, PDFs, and photos are all supported, and it explains that e-invoices are parsed deterministically while plain PDFs/photos go through a model. However, it never names an alternative sibling (e.g. ocr or pdf_extract) or states when NOT to use it, so routing is left 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?

With no annotations, the description carries the full behavioral burden, and it does disclose two genuinely useful operating traits: cost ($0.002 USDC per call) and latency (p99 2000ms). It also clarifies the aggregation scope (balance, staking, USD, names, outgoing txs). It stops short of stating auth requirements or rate limits, but the cost/latency disclosure is valuable context an agent cannot get elsewhere.

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?

Effectively one dense sentence front-loading the resource, followed by a short resolution clause and cost/latency tail. Every element (data inventory, cost, latency) earns its place, though the enumeration is heavy enough to border on clustering.

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 must convey return contents — and it thoroughly enumerates the fields (balance, all coins with symbol, staked IOTA per validator with rewards, USD value, pointed name, latest outgoing transactions). Combined with cost/latency and the accepted address forms, an agent has enough to invoke it correctly, though nothing is said about output shape or pagination.

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 single 'address' parameter is already documented with its 0x+64-hex format and name form. The description largely echoes this ('alice.iota', name resolution), adding only modest context ('resolves names to addresses and back') beyond the schema. Baseline 3 is appropriate.

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

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

The description names the exact resource (IOTA mainnet address or IOTA name) and enumerates the specific data returned — IOTA balance, other coins, staked IOTA per validator, USD value, name pointers, and latest outgoing transactions. This scope is clearly distinguishable from siblings like iota_tx, iota_network, and iota_watch.

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 enumeration of what the tool returns and by 'Resolves names to addresses and back', which signals the name-lookup use case. However, no explicit when-to-use, when-not, or named alternative sibling is provided, so an agent must infer routing from the content list.

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

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

With no annotations, the description carries the burden and does disclose the two traits that matter most for an agent: explicit cost ($0.002 USDC per call) and p99 latency (2000ms). Read-only, no-argument behavior is implied by the payload it returns. It does not mention auth prerequisites, rate limits, or failure modes, keeping it below 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-loaded with the tool subject, then the payload, then usage, then cost/latency — a sensible priority order. The middle sentence is a dense run-on list of returned fields, but every item earns its place given there is no output schema to carry that 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 and no annotations, the description compensates by enumerating the returned fields, price, and call economics, which is what an agent needs to decide and call. It is nearly complete for a zero-parameter snapshot tool; only auth/rate-limit and error behavior are unaddressed.

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 by rule. The description correctly frames it as a single no-argument call ('mainnet in one call'), leaving nothing for the agent to supply or misconfigure.

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

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

The description states a concrete verb+resource ('IOTA mainnet in one call') and then enumerates the exact payload: epoch, checkpoint, gas price and transfer fee, supply, price/market cap, and per-validator staking data sorted by APY. This clearly separates it from sibling snapshot tools like sui_network and gas_price, and from transactional IOTA siblings (iota_tx, iota_notarize) by being a read-only aggregate.

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?

Two concrete use cases are named ('Use to pick a validator or to show network health'), which gives an agent clear context for selection. It stops short of naming alternatives or exclusions (e.g. when to prefer gas_price, crypto_prices, or iota_watch instead), so it is not 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?

With no annotations, the description carries the full burden and does so richly: it discloses that only the SHA-256 is stored (never the content), that the notarization is locked, non-transferable, and undeletable until 2106, the exact return payload (object id, transaction digest, ledger time, explorer links), that network fees are included, the $0.01 USDC cost, and a p99 latency of 12000ms. These are exactly the behavioral traits an agent needs before committing an irreversible write.

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

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

A single dense paragraph that is well front-loaded: purpose first, then storage semantics, return values, use cases, verification path, and finally cost/latency. Every clause carries information, though the em-dash-heavy sentence is long enough that splitting cost/latency into its own line would improve scannability.

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, yet the description enumerates the return fields, and it covers immutability, storage guarantees, pricing, and latency for what is an irreversible mainnet write. Nothing an agent needs to decide whether and how to call this tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, setting a baseline of 3. The description adds a little by framing the three input modes as mutually exclusive alternatives ('send text, a SHA-256 hash or a URL'), a relationship the schema only partially states (only hash is labeled 'alternative to text'). It does not add syntax or format detail beyond the schema, so it stays near the baseline.

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

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

States a specific verb and resource ('IOTA Notarization (Proof of Existence) ... on the IOTA mainnet') and distinguishes itself from the verify sibling by describing the create-side operation ('send text, a SHA-256 hash or a URL and get a tamper-proof timestamp'). An agent can tell it apart from iota_verify or btc_timestamp 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 concrete usage contexts ('contracts, invoices, AI outputs, datasets, web page evidence or audit logs') and routes the agent to the follow-up alternative ('Check later with iota-verify'), which is explicit alternative naming. It does not, however, state any when-not condition or explain why this chain is preferable to btc_timestamp, so it falls short of full 5-level guidance.

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

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

With no annotations, the description carries the full burden and does disclose two behavioral facts an agent can act on: a $0.002 USDC per-call cost and p99 latency of 2000ms. It also implies a read-only single-record fetch. It omits auth requirements and what happens on an unknown digest, which keeps it below 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?

Front-loads purpose, then return contents, then cost and latency — a sensible ordering. The return-field enumeration is long but justified because no output schema exists. It reads as one dense run-on rather than cleanly separated clauses, which is a minor structural weakness.

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

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

For a one-parameter lookup with no output schema and no annotations, the description does real work: it itemizes the response contents and discloses cost and latency. Missing only error/empty-result behavior and any auth or rate-limit framing, which prevents a 5.

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

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

The single parameter is already 100% described in the schema ('Transaction digest (base58)'), which sets the baseline at 3. The description reinforces that lookup is 'by digest' and pinned to IOTA mainnet, but adds no format or validation detail beyond what the schema states.

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 an IOTA mainnet transaction by digest') and even scopes it to the chain and network. It enumerates exactly what comes back (status, checkpoint, sender, Move calls, gas fee, balance changes, objects, events), which cleanly separates it from sibling lookups like evm_tx, btc_tx, sui_tx and from iota_watch/iota_verify.

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

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

Offers a clear triggering context: 'Use to confirm a payment or contract call on IOTA.' That tells the agent when this tool is the right choice. It stops short of naming alternatives or exclusions (e.g., use iota_watch for live monitoring, iota_verify for notarized proofs), so it lacks the explicit when-not guidance 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?

With no annotations, the description carries the full burden and does so: read-only, no wallet needed, $0.003 USDC per call, p99 latency 3000ms, plus what is returned (stored hash/data, ledger creation time, lock status indicating mutability, owner, and a matches boolean). Cost, latency, safety profile and mutability semantics are all disclosed.

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

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

A single tight paragraph: purpose and inputs first, then return values, then read-only/cost/latency. No sentence is filler and the most decision-relevant facts are front-loaded.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it covers the cost/latency/safety envelope. The remaining gap is failure behavior: all five parameters are optional, yet the description never says what happens if neither object_id nor transaction is given, nor what a not-found result looks like.

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 frames object_id and transaction as mutually alternative identifiers for the same target, and clarifies that text/SHA-256/URL are the content-to-compare options. That said, it doesn't state whether a content parameter is optional or what 'matches' resolves to when none is supplied.

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 IOTA notarization), and immediately scopes it to any notarization on IOTA mainnet, official package, ours or anyone's. This clearly separates it from the sibling iota_notarize (the write counterpart) without the agent needing to open 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?

Explains the invocation condition well: supply an object id OR a transaction digest, and optionally content to compare. It does not explicitly name the alternative (e.g. 'to create a notarization use iota_notarize') or state when verification is unnecessary, 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?

With no annotations, the description carries the disclosure burden and does well: cursor-based incremental returns, response fields (direction, amount, status, time, explorer link, balance), cost ($0.002 USDC per call) and p99 latency (2000ms). It omits auth/permission requirements and rate-limit or error behavior, keeping it out of the top band.

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 action and scope before the pagination mechanics, then cost/latency. Dense but every clause carries useful information; the only slight excess is the stacked return-field list, which could be trimmed.

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 describing the return fields and the balance, and it covers the stateful cursor workflow plus cost/latency. Nothing critical to correct invocation is missing, though auth and failure modes are unaddressed.

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 earns more by explaining cursor semantics beyond the schema's terse "Cursor from the previous call" — clarifying the first call returns a cursor and that only new transactions arrive on subsequent calls. The limit param 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?

Specific verb+resource ("Watch an IOTA mainnet address or IOTA name") with the polling semantics stated. It clearly distinguishes a continuous watcher from one-shot siblings like iota_tx or iota_address, and enumerates the exact return payload. An agent can route correctly 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?

States intended use cases explicitly ("For deposit detection, treasury and whale watching") and explains the incremental-call workflow (first call returns recent tx + cursor, pass cursor back). It stops short of naming when NOT to use it (e.g. one-off lookups should use iota_tx) or an explicit alternative, so it isn't 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?

With no annotations, the description carries the full burden and does so well: it discloses the data source (local DB-IP database, no third-party call), latency (p99 150ms), rejection behavior for invalid/private/reserved addresses, pricing, licensing, and the caller-IP default. This is unusually rich behavioral context for a lookup 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 operation and its scope, then the returned fields, then use cases, then operational metadata in a compact colon-delimited list. Dense but every clause is substantive; only the license/cost/latency footer is arguably padding, though it is genuinely useful for cost-aware 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?

There is no output schema and no annotations, yet the description enumerates the returned fields (country, city, lat/lon, timezone, is_eu, ASN/isp/org), sources, latency, and rejection rules, so an agent has everything needed to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the single parameter is fully documented in the schema, which sets the baseline at 3. The description adds one piece of context ('defaults to the caller's IP'), but this mildly conflicts with the schema marking 'ip' as required, so it does not clearly add reliable value.

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

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

States a specific verb and resource ('resolve any public IPv4 or IPv6 address to location and network data from a local database') and enumerates the exact fields returned. This clearly distinguishes it from sibling lookups like dns_lookup, whois, and geocode without needing to open 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?

Provides concrete use cases ('fraud and bot checks, geo-routing, analytics, or tagging traffic') and notes invalid/private/reserved addresses are rejected, which gives the agent a clear sense of valid context. It stops short of naming which sibling to prefer for related lookups (dns_lookup, whois), so there is 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?

With no annotations, the description carries the full load and does well: it discloses cost ($0.12 USDC per call), p99 latency (30000ms), the full output shape (grade, score, verdict, reasons, confidence, sections), and caveats about it not being legal advice and sanctions matches needing manual verification. It omits auth/error behavior, but that is a minor gap relative to the disclosure provided.

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 tool identity and verdict scale, then ordered contents, return values, input rule, usage, caveats, and cost/latency. It is dense but nearly every clause carries information; the em-dash run-on in the opening sentence pushes it just below maximal.

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 high-complexity aggregation tool with no output schema and no annotations, the description explains return values, cost, latency, and the key input precondition, which is close to what an agent needs. It lacks detail on failure handling or how partial sections are reported, which keeps it from a 5.

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

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

Schema coverage is 67% and the schema lists zero required params, so the description's constraint 'Pass name and at least one of vat_number, lei, domain' adds genuinely necessary semantics the schema lacks. It also flags IBAN as optional, though it adds no format guidance for LEI/VAT beyond what the schema shows.

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 (KYB company check) and enumerates exactly what is aggregated: LEI entity status, VAT/VIES, sanctions, domain age, email security, website, optional IBAN. This clearly positions it against granular siblings like vat_validate, sanctions_screen, company_lookup and domain_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 a concrete usage context ('Use for onboarding and payment checks') plus the input precondition ('Pass name and at least one of vat_number, lei, domain'). It does not explicitly name the sibling alternatives it replaces, so an agent must infer that it supersedes single-purpose checks, 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.