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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantial extra context: 422 unknown_airport error semantics with 'not charged', latency (<0.1 s), an accuracy bound (~0.5% vs WGS-84), pricing, and a free-tier rate limit. This is well beyond what the annotations carry.

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

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

Purpose and the routing hint are front-loaded ahead of the auxiliary detail. It is dense and largely earns its space, though pricing, free-tier quota, and the docs URL are somewhat promotional for a selection-time description.

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

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

Return values, error behavior, accuracy caveats, data provenance, cost, and rate limits are all covered. An output schema exists, so return-shape explanation is not strictly required, making the coverage more than sufficient for a two-parameter distance tool.

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

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

Schema description coverage is 100% and the parameter descriptions already state 'Airport code (ICAO, IATA or ident) or {lat, lon}'. The description restates this format and notes the two arguments can be mixed, adding marginal value; baseline of 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Calculate the great-circle distance between two airports or points') and immediately distinguishes itself from the sibling lookup_airport, which handles airport details. An agent can select this over lookup_airport from the description alone.

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

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

Explicit routing ('For airport details use lookup_airport') plus a clear exclusion ('Informational only: not for flight planning or navigation'). Both a when-to-use and a when-not-to-use condition are stated, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world with nothing fetched), and the description reinforces that while adding substantial context beyond it: hard line/byte limits refused before payment, in-memory-only processing, no IP returned, a latency budget, and an explicit warning that classes are UA-derived and spoofable plus a prompt-injection caution on returned text.

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 pricing, size, latency and safety facts all earn their place for an agent budgeting a paid call. It loses a point for redundancy: 'In memory only, never stored and nothing fetched' is repeated by both 'The submitted text is never logged or stored' and the schema's own 'never stored' 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?

For a paid, single-parameter analysis tool with an output schema and full safety annotations, the description supplies everything an agent needs before invoking it: cost model and block limits, throughput, data-handling guarantees, and a trust caveat on returned data. Nothing material 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% and the single 'logs' parameter already documents accepted formats, the 1–100,000 line and 20 MB bounds, and the no-storage/no-IP guarantees. The description largely restates these rather than adding syntax or format detail the schema lacks, 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 (analyze) and resource (AI crawler, assistant, MCP and x402 buyer traffic in access logs), and explicitly carves out scope by naming the sibling tools identify_x402_client and parse_user_agent for the single-User-Agent case. An agent can distinguish this from its 18 siblings 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 provides explicit routing to alternatives ('For one User-Agent use identify_x402_client or parse_user_agent'), which is exactly the disambiguation an agent needs. It does not, however, state when-not to use it versus the bulk/index siblings or note prerequisites such as supplying correctly formatted logs.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description layers on genuinely additive traits: results cached up to an hour, a 100-result cap, upstream outage mapped to 503 upstream_unavailable with no charge, sub-second latency, price and free-tier limits, and an explicit non-endorsement disclaimer.

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 the sibling routing, followed by operational facts (caps, caching, errors, pricing). It is dense and close to a wall of text, but nearly every clause carries decision-relevant information for a paid, metered API call.

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 data provenance, freshness, result caps, failure semantics, cost, and latency, and even enumerates return fields despite an output schema existing. Nothing an agent needs to invoke this correctly or estimate cost 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% and both parameters already carry ranges, defaults, and even the au-to-lunar-distance conversion, so the description's restatement ('default 0.05 au, about 19.5 lunar distances') adds nothing new. Baseline 3 is appropriate when the schema does all parameter work.

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

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

States a specific verb and resource ('List asteroid and comet close approaches to Earth') with the scope (next 1-30 days, miss distance threshold). It explicitly names the sibling it is not ('For space weather use get_space_weather'), so an agent can disambiguate without opening either schema.

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

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

Provides an explicit alternative with its selecting condition (space weather -> get_space_weather) and a when-not caveat ('Not an impact-risk assessment'). An agent knows both when to reach for this tool and when to look elsewhere.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further with material context: 'Nothing is signed or sent,' error semantics (422 for bad input, 502 for failed read, neither charged), runtime (3-15 s), price (USD 0.005), a free tier (10 chain reads per IP per UTC day), and a docs link. This is rich disclosure beyond the structured annotations.

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

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

Front-loads the verb and the sibling routing, then layers return fields, risk tiers, errors, timing, and pricing. Dense but mostly load-bearing per sentence. It loses a point for enumerating return fields ('amount, `unlimited`, spender code... `revoke`') that the output schema already supplies.

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-parameter, Permit2-aware audit tool the description covers scope, candidate sources, risk semantics, staleness, errors, latency, cost, and safety. With an output schema present, the return values needn't be re-explained, and nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds behavior beyond the schema by explaining that the 6,000-block scan only surfaces recent candidates and that older approvals require `spenders` or Permit2, plus how risk tiers (High/Medium/Low) are assigned from unlimited/key-controlled vs contract-with-no-code distinctions.

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+scope: 'List a wallet's live token approvals and get revoke transactions,' naming ERC-20 and Permit2 coverage in the title. It explicitly distinguishes itself from two siblings, check_wallet_drain (already-drained tokens) and get_allowance (single allowance), so an agent can route 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 explicit when-to-use routing ('For tokens already pulled out use check_wallet_drain; for one allowance use get_allowance') and an edge-case condition ('Older approvals are found only via `spenders` or Permit2'). It also explains when the spenders/lookback_blocks path is the necessary choice.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world. The description adds substantial behavioral context: return semantics, 10-minute cache, 5 free calls per IP per day, USD 0.001 price, upstream outage as 503 upstream_unavailable (not charged), typical latency, NOAA SWPC provenance, and model limitations.

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

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

Front-loaded with the purpose and the get_space_weather alternative in the first two sentences. Later sentences are dense and mostly useful (returns, caveats, caching, pricing, docs), though the NOAA endorsement disclaimer is less critical for tool selection. Slightly long but not 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?

An output schema exists, yet the description also explains return fields. It covers parameters, return semantics, model caveats, error behavior, pricing, caching, and documentation, leaving nothing needed for correct invocation 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% and both lat and lon are documented with ranges. The description adds only that the forecast is for a location/point, which does not go beyond the schema's syntax or constraints, so the baseline of 3 applies.

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

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

States a specific verb (forecast) and resource (chance of visible aurora at a location in the next 30-90 minutes). Directly distinguishes itself from the sibling get_space_weather by routing Kp and solar wind queries there.

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

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

Explicitly names get_space_weather as the alternative for Kp and solar wind. The caveat that the model assumes a dark, clear sky and ignores cloud, moonlight, and light pollution tells the agent when results may be misleading.

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

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

Annotations only cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description goes well beyond by disclosing data sources (CDP Bazaar, PayAI, keyword match, not hand-checked, own listings excluded), the failure contract (found=false when under 3 matches, 422 for an unusable query, 503 for unreadable data), which errors are charged, cost (USD 0.002), the free 10/IP/UTC-day tier, latency, and a prompt-injection caution about returned text.

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 sibling routing are front-loaded, and each sentence carries distinct information. The trailing recap of input, data sources, failure codes, pricing, and latency reads as a dense run-on block 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?

Despite being a read-only, single-primary-parameter tool, the definition covers cost, rate limits, error semantics, charging behavior, data provenance, and latency—everything an agent needs to call it correctly. Output detail (count, median, quartiles, rank) is given even though an output schema exists.

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

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

Schema description coverage is 100%, so the schema already documents query, network, and price_usd in detail. The description only restates the parameter roles ('query', optional 'price_usd' to rank, optional 'network') without adding format or matching rules beyond the schema, 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 and resource ('Benchmark an x402 endpoint price against listed prices for similar endpoints') and immediately distinguishes itself from two named siblings. An agent can tell it apart from check_x402_endpoint_before_paying and x402_listing_audit 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?

Explicitly routes: use check_x402_endpoint_before_paying for a pay/avoid verdict and x402_listing_audit for a full listing review, implicitly positioning this tool as the price-comparison case. The condition that selects each alternative is stated, not inferred.

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

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive), while the description adds substantial behavior: no network access and nothing persisted, deterministic derived uids, exact timezone serialization rules, all-day inclusive-end handling, and a 422-with-event-name error contract that is explicitly not charged. This is far beyond what the annotations convey (the openWorldHint=true annotation is arguably imprecise against 'pure computation', but it does not contradict the safety 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 purpose and the sibling alternative, then output shape, then edge-case serialization rules, with pricing/limits/docs trailing. Dense and mostly waste-free, though '1-50 events' is repeated three times (title, description, schema) and the billing snippet sits mid-paragraph.

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 multi-field, nested-input generator, the description covers what the agent must know before invoking: input shape, defaults, serialization semantics, failure mode, cost, and a docs link. An output schema exists, yet the description still usefully names the return artifacts (VCALENDAR text, base64, data: URI, uids), leaving nothing critical 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 100%, so the baseline would be 3, but the description adds genuine semantics the schema omits: how a zoned start becomes TZID=<IANA name> with no VTIMEZONE block, how an offset becomes UTC, how a plain local time stays floating, and that all-day `end` is inclusive. These interpretation rules are the main thing an agent could get wrong.

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 ('Build an iCalendar file from JSON events') and immediately names the sibling it is not ('To read an .ics file use parse_ics'), so the agent can distinguish it from parse_ics without opening either schema. Scope (1-50 events) and output format (RFC 5545 VCALENDAR text) are also pinned down.

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 routes the agent explicitly: build here, read with parse_ics. It supplies context an agent needs before calling (pure computation, no network, nothing stored, cost and free-tier limits, typical latency) but never states a positive when-to-use condition for this tool beyond the implied 'you have JSON events and need an .ics'.

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

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

With annotations provided (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) the bar is lower, yet the description still adds real context: no images, 100-slide/2,000-char/250,000-per-deck limits, 422 not charged, ~1 s latency, USD 0.005 with no free tier, and prompt-injection caution. Return shape (base64 in `file`, `slides`, `output_bytes`, or a 24 h url link) is also 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?

Front-loaded with purpose, then alternatives, then return format, then input, then limits/pricing. Dense but every sentence carries decision-relevant information; the untrusted-data warning is the only near-boilerplate 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?

An output schema exists so return values need not be explained, yet the description covers output modes, file naming, limits, error/charging behavior, and latency. Nothing needed 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 description coverage is 100%, so the baseline is 3; the description earns above that because it surfaces the per-deck 250,000-character cap and 'text only' constraint that are not in the schema, plus a compact summary of slide fields and layout values. Most field-level detail is still redundant with the schema.

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

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

States a specific verb+resource ('Generate a PowerPoint deck from JSON slides') and immediately names the sibling tools it is not (build_xlsx_workbook, fill_docx_template). An agent can route 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?

Explicitly routes to the right alternatives with the selecting condition: workbook → build_xlsx_workbook, Word file → fill_docx_template. Combined with 'Text only, no images' this gives clear when-to-use boundaries.

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

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

Annotations already flag it as a non-destructive, idempotent, open-world writer, and the description adds substantial extra context beyond them: hard limits (20 sheets, 50,000 cells, 32,767 chars/cell, 31-char sheet names excluding [ ] : * ? / \), the 422-without-charge behavior on over-limit, 'strings stored as text never as formulas', typical latency, and pricing. That is unusually rich behavioral disclosure with no contradictions.

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

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

Front-loaded with purpose and alternatives, then constraints, cost, and docs link. Some redundancy with the schema (repeating the full type list), but every sentence carries operational value such as limits, error semantics, and price.

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 an output schema present, return values need not be explained. The description covers limits, failure behavior, cost model, and alternatives, which is everything an agent needs to call this 3-param build 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 description coverage is 100%, so the schema already documents output, sheets, and filename. The description restates the rows-as-arrays-or-objects rule and the column type enum, adding little beyond what the schema provides; 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: 'Build a styled Excel workbook from JSON sheets, columns and rows.' It also names the sibling it is not ('To read a workbook back use convert_excel_to_json; for slides use build_pptx_deck'), so an agent can distinguish it from the other pdfpeek build/convert tools immediately.

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

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

Explicitly routes the agent to alternatives for the reverse direction (convert_excel_to_json) and adjacent output format (build_pptx_deck). No explicit 'when not to use' or prerequisite guidance, but the sibling routing gives clear selection 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?

Goes well beyond the readOnly/idempotent annotations: gzipped delivery, per-source row cap, 1-5 s latency, USD 2 price with no free tier and a per-IP daily cap, plus a prompt-injection safety warning about treating endpoint/URL/on-chain strings as untrusted. These are exactly the operational traits an agent needs before calling.

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

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

Front-loaded with the action and scope, then cost/timing/safety details, all of which earn their place. Minor redundancy: 'Returns every current-snapshot record' largely restates the opening 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?

An output schema exists, so return shape need not be explained. The description covers scope, fallback tool, cost, rate cap, latency, and data-trust caveats, leaving nothing material missing for a zero-required-param 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 100% and there is only one optional parameter already documented as 'Filter: exact source id.' The description restates this ('optional `source` to restrict to one source') without adding format or matching semantics, 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 ('download the full current snapshot of the index') with explicit scope (all sources, per-source row cap, gzipped). It names the contrasting sibling export_agent_index, so an agent can distinguish them without opening a schema.

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

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

Explicitly routes the agent: use this for the full snapshot, use export_agent_index for a filtered slice, and the `source` param restricts to one source. The when/when-else conditions are stated outright rather than left to inference.

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

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

Annotations only cover the read-only/idempotent safety profile; the description adds the real behavioral payload: the exact read performed (one token, last 2,000 blocks), the lookalike matching rule (first 4 and last 4 hex chars), the high/medium/low decision rules, error semantics (422 bad input, 502 failed read, neither charged), latency (0.5-4 s), price and a free-tier rate limit.

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, front-loaded with the purpose and the sibling routing before the mechanics. Nearly every clause carries information (risk rules, errors, price, quota), though the length and lack of sentence breaks make it harder to scan than it needs to be.

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

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

Output schema exists, so return values need not be explained, yet the description still summarizes the `risk` field and its reason/evidence shape. Combined with the error mode and rate-limit disclosure, an agent has everything needed to invoke and interpret this 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 description coverage is 100%, so the schema already documents all 7 parameters including defaults, ranges and the dust/lookback semantics — the baseline is 3. The description reinforces the read scope (one token, default USDC, ~2,000 blocks) but adds no syntax or constraint detail beyond the schema.

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

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

States a specific verb (check), resource (transfer recipient), and threat (address poisoning) and spells out the detection method — lookalikes in the sender's history. It explicitly names the sibling tools it is not (transfer_preflight, check_sanctions), so an agent can route 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?

Explicitly routes alternatives: 'For balance, gas and blacklist checks too use transfer_preflight; for OFAC use check_sanctions.' It also states scope limits ('Older history, other tokens and other lookalikes are not seen'), so the agent knows when results will be 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?

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds substantial operational context: ~40 requests, 25 s worst case, 8 MB, 422 (not charged) for private/malformed addresses, price USD 0.01 with no free tier, and a prompt-injection warning about returned page text and on-chain strings. That is well beyond what the annotations convey.

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

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

Front-loaded with purpose then routing then returned scores then limits/pricing. Dense and information-rich, every item earns place, but the timing is stated twice ('25 s' and 'at most about 25 s') and the returned-score enumeration is long enough to be slightly redundant given an output schema exists.

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

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

For a single-URL scoring tool, the definition covers scope, routing, resource limits, error semantics, pricing, and safety guidance. An output schema is present, so return values need not be detailed, and the description still summarizes the score structure without over-explaining.

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 description already explains that only the origin is used and that host-name-only/no-IP/port-443 apply. The description's 'https port 443, public addresses only' restates schema constraints rather than adding new parameter meaning, 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 ('Check a site's AI-agent readiness') and enumerates the exact dimensions assessed (llms.txt, robots, sitemap, schema.org, OpenAPI, MCP). It also explicitly disambiguates from siblings by naming check_robots_txt and check_mcp_server with the conditions that select 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?

Explicit routing rules: use check_robots_txt for a single URL's robots rule, use check_mcp_server for a live MCP server probe. It also gives exclusions (public addresses only, port 443, no IP host names) and notes a failing part is returned as an error rather than a failed call.

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

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

Annotations already establish the safe read-only, idempotent profile, and the description goes well beyond them: USD 0.005 pricing, free-tier quota (3 scans / 30 checks per IP per UTC day), p95 ~1 s and max ~4 s latency, 10-minute result caching, and the failure semantics ('if the chain cannot be read the call fails and is not charged'). The heuristic limitations and specific risk signals detected are unusual, valuable 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 purpose, then routing, then returns, then cost/limits/limitations in a logical order. It is long and packs in a pricing figure and docs URL that are useful but not strictly needed for invocation, keeping it just short of a clean 5.

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

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

Even though an output schema exists, the description summarizes the return shape (verdict enum, risk_score 0-100, plain-language reasons) with concrete examples. Combined with cost, latency, caching, and failure behavior, an agent has everything needed to decide whether and how to call it.

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

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

Schema coverage is 100% with a documented enum on chain, so the schema already carries both parameters. The description restates the supported chains and the address's role but adds no syntax or format detail beyond the schema, so the 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 and resource ('check an address for risk') and pins the exact moment of use ('right before you send a transaction to it, approve it, or buy its token'). It explicitly names two siblings it is not (scan_contract_address, check_token_honeypot), so an agent can route without opening either schema.

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

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

Gives explicit when-to-use triggers plus named alternatives with the condition that selects each: full verified-source scan goes to scan_contract_address, sellability goes to check_token_honeypot. It also states the scope limits ('Heuristic, not an audit', 'a low verdict is not a clearance'), which is exclusions-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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description goes well beyond them: what the answer is derived from (RDAP 404 = no record, DNS NS), the caveat that premium/reserved names can look available, 422-on-invalid-name handling with no charge, latency (1-3 s, up to ~30 s for 50), pricing, daily free quota, and an untrusted-data warning. This is unusually rich behavioral disclosure.

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

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

Front-loaded with purpose and the sibling routing, followed by caveats, cost, and limits. Dense but every sentence carries information; the pricing/rate-limit block makes it longer than typical, though nothing is clearly wasted.

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

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

With an output schema present the description needn't explain return values, and for a billed, rate-limited, network-dependent availability check it supplies everything else an agent needs: cost, latency, error semantics, free quota, and the inference caveat.

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 both parameters are already documented there (including the xn-- conversion and 422 behavior). The description restates the `names`-or-`name` choice and per-name pricing but adds no syntax or format 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+resource (check domain name availability) and immediately distinguishes it from the sibling rdap_lookup, which serves registered-domain records. An agent can route between the two 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?

Names the alternative explicitly (rdap_lookup for a registered domain's record) and pins the condition that selects this tool. Both usage and the counter-case are covered.

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

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

Annotations already mark this read-only, idempotent, non-destructive and open-world, but the description goes well beyond them: one probe from Tanod's servers, no credentials, 15 s cap, 0.5-3 s typical, unresponsive server still charged, private/malformed address returns 422 uncharged, pricing and daily free quota, plus a prompt-injection warning about returned text.

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?

Information is front-loaded with the core purpose and alternatives first, then operational details. It is long and slightly repeats the title's field list, but nearly every clause (timeouts, charging, untrusted-data warning) carries decision-relevant content.

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

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

Despite an output schema existing, the description still tells the agent what the probe returns, how long it takes, what errors mean, what it costs, and what safety caveats apply to the returned data. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 100% and the single `url` property is already fully documented with format constraints (host name only, port 443, no user info). The description restates the same constraint ('the public https URL of the MCP server endpoint') without adding syntax or format details, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Check whether a remote MCP server is up and what it offers') and enumerates the concrete outputs (name, version, protocol, sign-in, tool count, latency, TLS expiry, status class). It also distinguishes itself from the two nearest siblings by naming scan_agent_package and preflight_mcp_listing directly.

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

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

Explicit routing guidance is given: 'It reads no code; to scan a package before installing use scan_agent_package; to check a repo against an awesome list use preflight_mcp_listing.' Constraints (public https, port 443, no credentials, no redirects) and the charged-vs-not rules further disambiguate when this tool should be used.

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?

Far exceeds the annotations (which only cover readOnly/idempotent/openWorld safety). It discloses the RFC 9309 matching rules, the 512 KiB fetch bound, redirect/port limits, 422-not-charged error conditions, latency range, pricing, free tier, and a prompt-injection caveat for returned text.

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 the alternative, then packs operational constraints densely. Every clause carries information, though the volume of pricing/limit detail makes it heavier than a typical description; it is justified but slightly over-stuffed.

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?

An output schema exists, so return values needn't be restated. Given the tool's SSRF surface and paid nature, the description supplies the missing operational, cost, and safety context, and points to docs — nothing an agent needs to call it correctly is 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 coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema: it explains how user_agent is interpreted (product token vs full UA, default '*' = any crawler) and how it feeds RFC 9309 matching, plus that a token-less UA yields 422.

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 (test whether robots.txt lets a crawler fetch a URL) and explicitly names the sibling it is not for ('For the URLs a site lists use parse_sitemap'). An agent can distinguish it from parse_sitemap and the other fetch/render tools 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?

Provides explicit routing: this tool for fetching-URL decisions, parse_sitemap for URL lists. It also documents the failure/precondition context (bad_user_agent 422, refused private targets) so the agent knows when invocation will and won't succeed.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds substantial context beyond that: the exact list and date basis, false-negative caveat, compliance limitations, verification link, latency, price, and free-tier limit. Nothing contradicts the annotations.

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

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

Front-loads the core purpose and alternatives, then packs caveats, limits, and pricing into a single dense paragraph. Every sentence carries operational information, though the result is long and could be more scannable.

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

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

Given the tool's screening complexity, single-address schema, existing output schema, and safety annotations, the description covers scope, alternatives, limitations, timing, cost, and verification guidance. It omits nothing material for correct selection or 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 covers the address parameter at 100% with a description and pattern. The description adds matching semantics: EVM/bech32 addresses match case-insensitively while base58 BTC, TRX, and other formats must be provided exactly as listed, useful for correct input formatting. It does not restate the schema's length/pattern constraints.

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: screen one crypto address against the US OFAC SDN digital-currency list. It explicitly names the sibling tools check_sanctions_batch and check_address_poisoning and distinguishes single-address vs lookalike use cases, so an agent can select it without opening schemas.

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

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

Explicitly routes to alternatives: use check_sanctions_batch for up to 1,000 addresses and check_address_poisoning for lookalikes. It also states scope (OFAC SDN digital-currency addresses only), that a non-match does not clear, and that this is not legal advice or full compliance.

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

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

Annotations already establish readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: per-address and per-call pricing with a minimum, error semantics (422 naming the offending index, not charged), latency (~0.5 s for 1,000), data-handling (submitted text never logged or stored), and honest limitations (non-match does not clear an address; not legal advice; verify at OFAC). That is exactly the kind of context structured fields cannot carry.

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

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

Front-loaded and dense with useful facts, but there is real repetition: sentence three ('Returns the OFAC sanctions screen of 1-1,000 crypto addresses in one call') restates sentence one, and the batch-size/pricing figures appear multiple times. Trimming the redundant return line and price restatement would sharpen it without losing information.

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

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

An output schema exists, so return values need not be explained. Given that, the description covers everything else an agent needs before calling: matching rules, batch limits, cost bounds, failure mode, latency, data retention, and legal caveats. Nothing material is missing for a one-parameter screening 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 would be 3, but the description goes further: it explains that EVM and bech32 entries match case-insensitively while other formats are matched exactly as listed, that pricing is per address, and that a single invalid item aborts the batch with a 422 identifying its index. That is meaning the schema's regex and min/max alone do not convey.

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

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

States a specific verb (screen), resource (crypto addresses), and scope (up to 1,000, against the OFAC SDN list) in the first sentence, then explicitly names the sibling it is not for: 'For one address use check_sanctions.' An agent can pick between the batch and single-address tools without opening either schema.

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

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

Names the alternative tool and the exact condition that selects it (single address → check_sanctions), and bounds the batch regime with concrete limits (1-1,000 per call, one invalid item fails the whole batch). This is explicit when-to-use/when-to-use-something-else guidance rather than implied context.

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

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

Annotations already cover the read-only/idempotent safety profile, yet the description layers on substantial behavioral detail: private/internal/IP-literal targets are refused with 422 and not charged, max 4 redirects, ports 80/443 only, latency 0.3-2 s, price, free tier, and a prompt-injection warning about treating page text as untrusted. This is well beyond what the structured fields convey.

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

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

Front-loaded with purpose and sibling routing, followed by scope caveat, mechanics, and pricing. Every sentence carries information, though the operational details (latency, price, free tier, docs URL) make it dense; nothing 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?

An output schema exists, so return values need not be spelled out, yet the description still names score/grade/deduction and the redirect chain. With the one required param, safety annotations, and full behavioral constraints all present, 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?

With one parameter at 100% schema coverage, the schema already documents the url field, so the baseline is 3. The description adds real meaning about what the URL may be: public http(s) only, ports 80/443, redirect handling, and refusal of private/internal targets.

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 (grade) and resource (a public page's HTTP security headers) and enumerates exactly which headers are evaluated. It explicitly names the sibling tools it is not (check_url_phishing for phishing lists, inspect_domain for DNS/TLS), so an agent can distinguish it 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 explicit routing: 'For a phishing-list check use check_url_phishing; for DNS and TLS use inspect_domain.' It also states scope limits ('grades one response's headers, not the site... not an audit'), which is when-not guidance of the highest value.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld), and the description adds substantial behavior beyond them: bounded reads (12 RPC calls), a `coverage` field, per-window counted/estimated/lower_bound semantics, the yield definition (USD paid / market cap now, not annualized), error handling (404 not_reward_token, 422 not charged), 5-minute caching, latency bounds, pricing, free-tier quota, and a prompt-injection warning about untrusted text.

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 core question and outputs are front-loaded in the first two sentences, followed by operational detail. It is dense but nearly every sentence carries actionable information; only a light overlap with the title keeps it from a 5.

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

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

An output schema exists, so return-value explanation is not strictly needed, yet the description still characterizes the result states, windows, and yield basis. Combined with error codes, latency, caching, and quota, an agent has everything required 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 description coverage is 100% for the single `mint` parameter, so the schema already documents the base58 mint address and its constraints. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource – returns whether a Solana reward token still pays holders – and enumerates the concrete outputs (PAYING/STALE/NEVER, last payout, 7d/30d payouts and yield). It explicitly distinguishes itself from the closest sibling (check_solana_token_safety for rug risk), so an agent can route without opening either schema.

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

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

Names the alternative tool for a related but different question ('For rug risk use check_solana_token_safety'), which gives clear routing context. It implies when the tool applies (assessing whether a reward token still pays) but does not lay out explicit when-not conditions, 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?

Despite annotations already covering readOnly/idempotent/destructive, the description adds unusual depth: source-level degradation ('each part says unavailable when its source is down'), error semantics (422 for bad address or non-mint), billing behavior ('a failing RPC is never charged'), latency envelope (2-6 s typical, ~25 s max), price and free-tier quota, and an explicit prompt-injection warning about returned page text.

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 sibling routing are front-loaded, then operational caveats. It is long and dense, but nearly every clause carries distinct information (timing, pricing, degradation, untrusted-data warning); only the redundant title text and the doc-link tail are padding.

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

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

For a read-only heuristic scan with an output schema and full annotations, the description covers what an agent still needs to decide and act: inputs, latency budget, failure modes, partial-result behavior, cost, and quota. 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?

Both parameters are fully documented in the schema (100% coverage), including the 5%-of-supply cap and the `sell_route.amount_usd` echo. The description only gestures at the sell quote ('as a loss number') without adding format or syntax beyond the schema, so it sits at the baseline for high-coverage schemas.

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

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

States a specific verb and resource ('Check a Solana token for rug risk') and enumerates the concrete outputs: mint/freeze authority, Token-2022 risks, top-10 holder share, Jupiter sell quote, risk level with reasons. It explicitly routes away from the two nearest siblings: 'For authorities alone use get_solana_token_info; for ERC-20 tokens use check_token_safety.'

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 when-to-use plus two named alternatives with the selecting condition (authorities-only lookups; ERC-20 tokens). It also sets expectations about when results are not trustworthy ('Heuristic, not an audit; a snapshot of now') and what to do with the data (treat as untrusted).

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial context beyond them: indicative-not-oracle caveat, the USDC cross-check pricing method, the 30s pool read cadence, error handling (failed coin in `errors`, 502/422 outcomes), no-charge behavior for failures, latency, price, and free-tier rate limits. This is a genuinely rich behavioral disclosure.

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

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

Front-loaded with the core purpose and well organized, but the asset list is repeated across the title and both first sentences, and pricing/latency/limits are packed densely. Slightly redundant but every sentence carries operational value.

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

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

Complete for a zero-required-param read tool: purpose, alternative, error/status mapping, cost, and rate limits are all present, and an output schema exists to cover return values. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the schema already documents coins, case-insensitivity, omit-for-all default, and the 422 unknown-coin behavior. The description largely restates this, so the baseline 3 is appropriate — it adds no syntax or semantics beyond the schema.

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

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

States a specific verb+resource ('Check stablecoin peg') and enumerates the exact assets covered (USDC, USDT, DAI, USDe, PYUSD) and the source (Ethereum Uniswap V3 pools). It explicitly names and routes away from the sibling get_stablecoin_supply, so an agent can distinguish the two without opening either schema.

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

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

Provides an explicit alternative with its selecting condition: 'For supply by chain use get_stablecoin_supply,' which contrasts against this peg-check scope. The purpose sentence itself makes the when-to-use obvious (checking peg status). This matches the high-bar pattern of naming the sibling to use instead.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds substantial extra context on top: the underlying data source (Atlassian Statuspage, incident.io, Instatus, Better Stack), latency (0.5-6 s), pricing and rate limits, and the security warning that returned page text and on-chain strings are untrusted data. Nothing about the operation's behavior is hidden.

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

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

Purpose and return shape are front-loaded, followed by source/error/latency/pricing/untrusted-data details. Each sentence earns its place, though the pricing and free-tier clauses make it denser than strictly needed for selection.

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

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

An output schema exists, yet the description goes further by naming the return fields (overall status values, components, incidents with impact and last update, scheduled maintenance) and covering error codes, latency, cost, and trust caveats. Complete for a single-parameter read tool.

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

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

Schema coverage is 100% and the single url parameter is fully documented, including the host-search behavior and supported providers. The description's parameter-related content (

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 an API status page: is a service up?'), enumerates what it returns (overall status, degraded components, open incidents), and explicitly sets itself apart from the sibling check_mcp_server. An agent can select it confidently 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 an explicit routing rule ('For whether an MCP server answers use check_mcp_server') and a clear negative boundary: it reads a vendor's public status page JSON rather than probing the service, so it is not a generic uptime check. Error conditions (404 status_page_not_found, 422 private host, neither charged) further define the usage envelope.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial beyond-schema context: classifier limitations ('can miss new attacks and flag harmless text'), latency figures, first-call cold start, price and free tier, privacy guarantees ('never logged or stored'), and an explicit trust boundary ('data, never instructions'). This is exactly the extra disclosure that earns a high score.

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 the sibling alternative come first, then output shape, limitations, errors, cost. Some sentences are terse to the point of being compressed, but virtually every clause carries operational information rather than filler.

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

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

For a single-parameter screening tool with an output schema, the description covers everything an agent needs: what is screened, the verdict/score/chunks semantics and threshold, limits, error behavior, latency, cost, and how to treat the returned excerpts. 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 100% and there is only one parameter, so the schema already defines the argument; baseline would be 3. The description goes further by restating the 20,000-character ceiling as an enforced error condition and adding 'English-first' as a practical constraint on what text is worth submitting.

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 text for prompt injection before an agent acts on it') and explicitly routes a related concern to a different tool (text_unicode_inspect for hidden Unicode). An agent can distinguish this from the embedding, classification, and extraction siblings without opening the schema.

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

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

Explicitly states the triggering condition ('before an agent acts on it') and names the alternative tool for the adjacent case of hidden Unicode. It also defines the failure surface (422 over budget, 503 unavailable) so the agent knows when not to rely on a successful call.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-obvious behavior: the secret itself is never returned, redaction shows only a vendor prefix plus up to 4 chars per end, seed phrases reveal only word count, pattern matching means a clean result is not proof, blank input returns 422 uncharged, latency under 0.5s, price, daily free tier, and no logging/storage.

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 sibling routing are front-loaded, and the long vendor enumeration is dense rather than padded. It is slightly verbose because the privacy guarantee and no-secret-returned promise are restated from the schema, and the trailing docs URL is minor clutter.

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

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

Even though an output schema exists (so return values need not be explained), the description fully specifies the returned per-match fields and the redaction format. Combined with pricing, limits, and failure behavior, an agent has everything needed to call and interpret this 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?

Only one parameter and schema coverage is 100%, so the schema already documents type, length bounds, and the privacy guarantee. The description restates the 200,000-character limit and the never-logged property but adds no syntax or format detail beyond the schema, 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 and resource ('Scan text for leaked secrets') and enumerates exactly what it detects. It explicitly distinguishes itself from the two nearest siblings, redact_pii and check_text_for_prompt_injection, so an agent can route 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 explicit alternatives with selecting conditions: personal data goes to redact_pii, injected instructions to check_text_for_prompt_injection, and the 'before it is posted' framing supplies the use context. Nothing is left to inference.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description goes well beyond them: expected latency (3-15 s, 3 searches at a time), pricing (USD 0.08, no free tier), failure semantics (422 for short sentences, 503/504 uncharged), index coverage limits (Mojeek sample), authorship disclaimer, and an untrusted-data warning. This is a rich behavioral disclosure that an agent cannot get from structured fields.

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

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

Front-loaded with the core purpose and overall well-packed, though the many parenthetical clauses and the trailing pricing/error notes make it denser than a single crisp statement. Nearly every sentence carries operational information, so little is wasted.

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

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

With an output schema present the description needn't explain returns, yet it still sketches the result shape (share_found, sources ranked by sentences held) and covers cost, timing, error codes, and data-handling/privacy. 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 description coverage is 100%, so the schema already documents all three parameters including max_sentences range and exclude_domains semantics. The description reinforces these ('up to 10 of a text's most distinctive sentences', 'exact-phrase search', 'up to 5 each') but adds no syntax or format 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?

The description names a specific verb and resource — check a text for copied sentences by finding web pages containing them word for word. This is unmistakably distinct from the sibling text utilities (text_stats, text_spellcheck, redact_pii), none of which perform external-source matching.

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

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

It states the intended use case and routes general queries to web_search, and it adds an important interpretation caveat (not found is no proof of originality; a match may have copied the text). It does not, however, describe when this tool should not be used versus siblings beyond that single alternative.

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

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

Annotations already establish read-only, non-destructive, idempotent, open-world behavior, but the description adds substantial operational detail: return fields, tax measured from real balances, 422 on bad address or non-contract and not charged, caching, latency, price, free quota, and untrusted-data handling. No annotation contradiction is present.

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

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

The description is front-loaded with purpose and then dense with useful limits, errors, pricing, and security context. It is longer than typical but mostly earns its length; some pricing and documentation details are less central to immediate invocation.

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

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

Given the tool's complexity, an output schema, and full parameter schema coverage, the description is complete enough for correct invocation. It covers scope, alternatives, failure modes, latency, caching, billing, and security caveats without needing to duplicate every return value.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions the simulated buy/sell context and supported chains, but it does not add parameter-level detail beyond what the input schema already documents for token, chain, and amount_usd.

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

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

The description states a specific verb and resource: detect whether an ERC-20 token can be sold via simulated buy and sell-back with tax on Base or Ethereum. It explicitly distinguishes itself from the sibling check_token_safety, which adds contract flags rather than a tradability verdict.

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 names the alternative check_token_safety and the condition that selects it, and adds important usage caveats: heuristic not audit, no-pool tokens return unknown, delayed or wallet-gated sell blocks may pass, and the call is cached for 60 seconds. This gives clear when-to-use and when-to-trust 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?

Far exceeds the annotations (readOnly/idempotent/openWorld): it discloses the mechanism (simulated buy and sell-back measuring honeypot, buy/sell/transfer tax, pool, revert reason; contract flags for upgrade, mint, blacklist, fee setters, pause, verification), the heuristic-vs-audit caveat, error semantics (422 non-contract, 5xx failing RPC and not charged), latency, price, free tier, and an untrusted-data warning.

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 use case and alternatives, and nearly every sentence carries operational value (errors, pricing, latency, safety caveat). However it is a single dense paragraph with several crammed clauses, so it is not maximally scannable.

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

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

For a 2-param read-only tool with an output schema, the description covers everything an agent needs: when to call it, what the verdict contains, its heuristic limits, failure modes, cost, rate limits, and a prompt-injection caution. Nothing material 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% and the two parameters (chain enum, address pattern) are fully self-documented, so baseline 3 applies. The description restates the Base/Ethereum scope and ERC-20 address notion but adds no format or syntax detail beyond the schema.

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

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

States a specific verb+resource+scope: deciding whether an ERC-20 token on Base or Ethereum is safe to buy or interact with. It explicitly differentiates from sibling tools by name (token_verdict for a written summary/share card, check_solana_token_safety for Solana), so an agent can route 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?

Gives an explicit when-to-use trigger ('when an agent must decide whether an ERC-20 token ... is safe to buy or interact with') and names concrete alternatives with the condition that selects them. The distinction from token_verdict and the Solana tool is unambiguous.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, and the description adds substantial context beyond them: the two named source lists and their refresh cadence, the fact the URL is never fetched, the 422 invalid_input behavior (not charged), latency, $0.001 price, 10 free reads per IP per UTC day, and a no-logging privacy guarantee.

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 and sibling routing, then moves through mechanics, caveats, and commercial terms in a logical order. Every sentence carries information, though the run-on middle paragraph about lists, return fields, and latency is denser than it needs to be.

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

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

Output schema exists, so return values need no explanation, yet the description still names the key fields and, more importantly, warns that absence from the lists is not a clearance. For a screening tool whose failure mode is false reassurance, that caveat is the essential missing piece and it is present.

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

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

Schema description coverage is 100%, so the 3 baseline applies and the description exceeds it: it clarifies that the input is only parsed and never fetched, that host and parent domains are matched, and that the two parameters are alternatives rather than complements. These details go beyond the schema text without fully specifying precedence when both are 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 and resource ('Check if a URL or domain is phishing or a scam') and immediately differentiates itself from siblings by naming check_urls_phishing_batch for volume and check_security_headers for headers. An agent can select this tool 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?

Explicit routing: batches of up to 1,000 URLs go to check_urls_phishing_batch, header checks to check_security_headers, and the remaining single-URL/single-domain case is implicitly this tool. It also sets expectations about what negative results mean ('an unlisted host is not cleared'), which is usage guidance in the truest sense.

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

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

Goes well beyond the annotations: discloses that the URL is never fetched, names the two lists (PhishDestroy, Phishing.Database) and their refresh cadence, warns that an unlisted host is not cleared due to staleness, and specifies a 422 whole-batch failure naming the offending index (uncharged). Performance, pricing and privacy ('never logged or stored') are also 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?

Front-loads purpose and the sibling routing, then layers cost, error and caveat details. Dense but nearly every sentence carries distinct decision-relevant information; slightly long, which keeps it off a 5.

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

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

With an output schema present, return formatting need not be explained, and the description nonetheless covers pricing, failure semantics, performance, privacy and the staleness caveat. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% and the single 'items' param already documents the 1-1,000 range, 2,048-char limit, and per-item pricing. The description reinforces the same facts but adds no syntax or format 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 ('Check up to 1,000 URLs or domains for phishing or scams in one batch') and explicitly distinguishes itself from the single-URL sibling check_url_phishing. An agent can select it 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?

Explicitly routes single-URL callers to check_url_phishing and scopes itself to batch use ('1-1,000 URLs in one call'). The when-to-use decision is unambiguous, including the boundary at one item.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: verdict semantics (drained/review/clean) with the exact rules that trigger each, the 2,000-block scope, the four transfer classifications, error behaviour (422 bad input, 502 failed read, neither charged), latency (2-10 s), pricing and a free daily quota. This is unusually rich behavioural disclosure for a read-only tool.

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

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

The purpose is correctly front-loaded, but the body is a dense multi-clause run-on that packs verdict rules, classifications, pricing, error codes and quotas into a single paragraph. Much of it earns its place, yet the wall-of-text format makes it harder to scan than a structured list would 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 paid, rate-limited security read, the description covers scope, verdict logic, edge cases (gasless orders look like pulls, smart-account/EIP-7702 wallets), failure modes, timing, cost and docs. An output schema exists, so return values need not be detailed, and 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 all four parameters are already documented, and the description largely restates them (default 2,000 blocks, USDC/USDT or up to 5 tokens). It adds no format or syntax detail the schema lacks, so the 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 and resource ('check a wallet for a drain: find tokens pulled out without its signature') and explicitly routes the related case to a named sibling (audit_token_approvals). An agent can distinguish this from the other wallet/contract checkers without opening a schema.

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

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

Names the alternative tool and the condition that selects it ('For live approvals with revoke transactions use audit_token_approvals'), which is exactly the routing an agent needs. It does not cover other near-neighbours (get_wallet_counterparties, check_address_poisoning) or state when a drain check is unnecessary, so it stops short of the full when/when-not pattern.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description goes well beyond them: it documents the return shape (ratio plus AA/AAA pass-fail for normal, large, and UI text), a concrete unrounded example, 422 behavior on invalid colors with the key note that no charge occurs, translucent-color compositing semantics, typical latency, and price/free-tier terms.

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 layered details. It is on the longer side (pricing, free tier, docs link, example) but each sentence carries operational value; the 'unrounded: #777 on white is 4.48:1' example notably earns its place.

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

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

For a two-param utility with an output schema, the description covers everything an agent needs: purpose, sibling routing, error semantics, billing, compositing behavior, and latency. Nothing material is left unspecified.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: it clarifies the foreground is the text/UI color, and that a translucent color is composited over the background before computation, which affects how inputs are interpreted.

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: checking WCAG contrast between a text/foreground color and a background color. It also explicitly names the sibling convert_color_check_contrast as the tool for format conversion, so an agent can distinguish the two without opening a schema.

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

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

Provides an explicit routing hint ('To convert colour formats too use convert_color_check_contrast'), which covers the main adjacent use case. It does not state when this tool should not be used or other alternatives, but the context is clear for a single-purpose utility.

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

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

Annotations give readOnlyHint/idempotentHint/destructiveHint=false, but the description adds substantial behavior beyond that: which failures are charged vs. not (422/503 uncharged, non-responding endpoint charged), timing (0.5-3 s typical, ~12 s slow), price and a free-tier quota, and a security warning to treat returned text as untrusted. This is exactly the context annotations cannot carry.

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

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

Front-loaded with the purpose and verdict vocabulary, then organized into routing, output, mechanics, errors, timing, and price. It is dense and several clauses are compressed into single sentences, but nearly every clause carries operational value, so waste is low.

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?

An output schema exists, so return values need not be explained, and the description still covers error codes, charging semantics, latency, pricing, quota, and the data-safety caveat. For a two-parameter preflight tool with rich annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both `url` and `policy` are fully documented in the schema, including formats, request behavior, and the policy clauses. The description restates `policy` as adding a pass/fail result 'judged on what was already read', which the schema already conveys, so baseline 3 is appropriate.

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

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

States a specific verb+resource ('Check an x402 endpoint before paying it') and the exact output ('pay, caution or avoid, with reasons'). It explicitly routes away from two siblings by name, so an agent can distinguish it from x402_seller_report and benchmark_x402_price without opening either schema.

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

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

Names the two alternatives explicitly with the condition selecting each ('for a seller checking their own listing', 'for listed prices alone'). It also defines scope boundaries ('Nothing is paid', 'automated and heuristic, not an audit') so the agent knows what this tool is not for.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context: model identity and license, English-only limit, score semantics (softmax vs per-label), the caveat that scores are not calibrated probabilities, latency, hash-pinned local execution, 503 behavior, pricing, free tier, and a no-logging privacy guarantee. This far exceeds 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 front-loaded: the core action leads, then routing, then behavior, runtime, and pricing. Every sentence carries operational weight, though the pricing/free-tier/model detail makes it slightly heavy for a single paragraph.

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 an output schema present, the description need not restate return format, and it still explains scoring semantics, latency, failure mode (503, not charged), cost, and privacy. 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 description coverage is 100%, so the schema already documents all four parameters, setting the baseline at 3. The description clarifies multi_label behavior (scoring each label independently) and the meaning of the returned scores, but leaves hypothesis_template unexplained beyond the schema, so no lift above 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 (classify a text into your own labels) with the zero-shot framing, and explicitly distinguishes itself from the sibling extract_entities for named entities. An agent can tell what it does and what it is not.

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?

Routes the agent away toward extract_entities when the task is named-entity recognition, giving a clear conditional alternative. It does not contrast with adjacent siblings like text_sentiment or embed_texts, so exclusions are partial rather than exhaustive.

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

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

Annotations already cover readOnly/idempotent/open-world, yet the description adds substantial operational context: error semantics (404 unknown board, 503 outage 'not charged', 422 for URL/IP), latency (1-3s, up to ~30s for an uncached large Lever board), price (USD 0.005) and free-tier quota, plus an untrusted-data warning. This is well beyond what the annotations disclose.

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 the sibling routing are front-loaded in the first two sentences, and the dense details (fields, errors, timing, price, security) follow. Every sentence is substantive, though the single long paragraph packs a lot together rather than grouping the operational facts.

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

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

Even with an output schema present, the description covers the return scope ('No job description text'), error codes, cost/quota, latency, and the domain-to-token resolution rule. An agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the description largely restates the token/domain rule and the ATS fallback that the schema already carries. It adds little parameter-level syntax beyond what structured data 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 and resource ('List a company's open jobs from its Greenhouse, Lever or Ashby job board') and immediately names the sibling it must not be confused with ('For the company's profile use company_profile'). An agent can distinguish it from company_profile and from generic search tools 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?

Explicitly routes to company_profile when the profile is wanted, and explains the default vs. explicit ATS behavior ('the token is tried on all three at once'). It gives clear context for use but does not state when this tool is inappropriate beyond the profile redirect.

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