Tanod MCP Server (Deprecated)

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well past them: per-page pricing (USD 0.05, no free tier, empty poll free), typical latency, 410/422 error semantics with the 'not charged' guarantee, cursor expiry on snapshot changes, suppressed sampled removals, and a 4096-char ID exclusion. It also flags listed endpoint data as untrusted input that must not be treated as instructions.

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 almost every clause carries operational value (cost, ordering, error codes). The telegraphic, semicolon-chained style compresses well but reads as a dense block, making the cursor workflow rules slightly harder to scan than they could be.

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

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

For a paid, cursor-paginated, mutating-cursor-state tool, the description covers cost model, pagination lifecycle, error handling, latency, and trust caveats. An output schema exists, so the absence of return-shape details is not a gap.

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

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

Schema coverage is 100%, and the description still adds meaning beyond it by tying each cursor name to its producer (next_cursor, refresh_cursor, bulk delta_cursor) and clarifying that a null baseline means bulk-unfiltered. It does not add anything for limit or source beyond the schema, so it is strong but not exhaustive relative to the schema 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 — 'refresh a local x402/MCP index' — and immediately bounds scope to 'net additions, removals and price changes.' It also distinguishes itself from the sibling bulk_agent_index by naming it as the snapshot prerequisite, so an agent can route correctly 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?

Explicit sequencing rules: 'For a starting snapshot use bulk_agent_index, then pass its delta_cursor as cursor,' 'Give since OR cursor,' 'follow next_cursor, then save refresh_cursor,' and the exclusion 'After bulk, use its delta_cursor, not since.' It also names the alternative summary endpoint for latest dates. This is a full when/when-not/alternative map.

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 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?

Goes far beyond the readOnly/idempotent/non-destructive annotations: states in-memory processing, no storage or logging, no IP return, refusal before payment at the 100,000-line/20 MB cap, per-block pricing, and typical latency with a concrete benchmark. It also warns that user-agent classification can be faked and that returned page text and on-chain strings are untrusted data.

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

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

Front-loaded with purpose and the sibling routing, then limits, privacy, pricing, latency and safety in a logical order. It is dense and slightly run-on, but nearly every clause carries decision-relevant information, so little could be cut without loss.

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, capped, stateless analysis tool with an output schema already defined, the description supplies everything an agent needs before calling: input formats accepted, size and line limits, cost range, latency, privacy posture and the optional robots.txt enrichment.

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

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

Schema coverage is 100%, so the schema already documents the three parameters well. The description still adds genuine meaning: pricing and billing are tied to 10,000-line blocks of logs, and robots_txt is framed as the alternative to site with a named output gain (robots_compliance) at the same price.

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 a precisely scoped resource: AI crawler, assistant, MCP client and x402 buyer traffic parsed from access logs. The opening line plus the parenthetical list of emitted client classes makes it immediately distinguishable from generic log or user-agent tools.

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-User-Agent questions to identify_x402_client or parse_user_agent, which is exactly the kind of alternative-naming that helps selection. It also positions site vs robots_txt as mutually exclusive options. It does not, however, address the very similar sibling audit_web_logs, leaving ambiguity for log-analysis requests.

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/openWorld annotations: states the 100-approach cap, one-hour cache, sub-second latency, 503 upstream_unavailable behavior with no charge, pricing and free-tier limits, and explicitly disclaims impact-risk assessment. This is exactly the operational context annotations can't 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?

The purpose and sibling routing are front-loaded, and the remaining clauses (cache, cap, error, price, docs) are each operationally distinct. It is dense but every sentence carries information, though the legal attribution clause is slightly heavy.

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

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

Even though an output schema exists, the description names the returned fields (designation, approach time, 3-sigma distance, velocity, magnitude, diameter) and clarifies the diameter may be a rough range. For a low-parameter paid API tool, nothing an agent needs before calling 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 parameter defaults and the 0.05 au ≈ 19.5 lunar-distance conversion already appear in the schema, so the description largely restates them. It adds only the framing of 'upcoming' window semantics; 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 ('List asteroid and comet close approaches to Earth') with scope (1-30 days, max miss distance), and explicitly distinguishes itself from the sibling get_space_weather. An agent can identify this tool without opening the schema.

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

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

Names the alternative for a neighboring domain ('For space weather use get_space_weather') and bounds the use case by window and distance. It lacks explicit when-not-to-use guidance beyond that single routing pointer, so it falls short of a full 5.

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

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

Annotations only declare readOnly/idempotent/openWorld/non-destructive, and the description adds substantial operational context on top: up to four tools/list pages, no tool calls or redirects, a failed probe or index is not charged, no-match returns count 0 at the route price and is not proof of absence, the endpoint host is disclosed to Smithery's public search, and returned page text is untrusted data. Latency bounds (1-8 s typical, ~25 s max) and pricing (USD 0.01, no free allowance) are stated explicitly.

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 then pricing, limits, safety and privacy in a compact telegraphic style with essentially no filler. The only waste is the redundant "agentscan:" prefix that duplicates the title, and the clipped sentences cost a little readability.

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

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

With an output schema present, return-value explanation is unnecessary, and the description still covers the cost model, free-allowance absence, page cap, timeout ceiling, probe-failure billing, null semantics, and prompt-injection caution. Nothing material for correct invocation or interpretation of results is missing.

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

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

Schema coverage is 100% and the schema already spells out the https streamable-HTTP/legacy-SSE constraint, port 443 and no user info, so the baseline is 3. The description nevertheless adds meaning beyond the schema by stating the public-endpoint/no-credentials requirement and disclosing that the endpoint host is forwarded to Smithery's public search, which is a privacy behavior the parameter itself cannot express.

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

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

"Review MCP Registry and Smithery listings" plus "Returns official MCP Registry and bounded Smithery listings versus live tools, transport and repositories" gives a specific verb-and-resource with the comparison target named. It is clear what comes back (directory data compared against a live probe), but it never contrasts itself with the many near-neighbours in the sibling list (check_mcp_server, preflight_mcp_listing, x402_listing_audit), so differentiation is left to inference.

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

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

Usage is implied by the phrasing (compare listings to a live server) and there are useful scoping constraints such as "port 443, no credentials" and "query URLs skip it". However there is no explicit when-to-use statement, no when-not, and no pointer to check_mcp_server or preflight_mcp_listing as the lighter alternative for a plain liveness check.

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

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

Beyond the annotations, it discloses concrete operational behavior: per-route unpaid requests, caps of 25 operations / 3 MCP pages / 18 s, a 30 s per-origin rate limit, 422 and 504 error conditions, no charge on failure, no seller payments, and a USD 0.02 price with no free tier. It also repeatedly flags that seller text and on-chain strings must be treated as untrusted data.

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

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

The purpose and main constraints are front-loaded, and most clauses are dense with useful operational detail. It is telegraphic and somewhat repetitive — the 18 s cap appears twice and the untrusted-text warning appears in two forms — but it avoids filler.

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

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

Given an output schema and annotations, the description still supplies the missing decision-critical context: cost, no free tier, rate limit, runtime cap, failure semantics, partial coverage, directory-claim behavior, and untrusted-data handling. An agent has enough to call it safely and interpret its limits.

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 already high. The description nevertheless adds cross-parameter meaning: origin scope is expanded only by fetch_directory_claims, listing_claims are caller-supplied and not verified at the listing, URLs are never fetched, and there is a cap of 10 listing claims.

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 an x402 seller's price consistency and return a comparison of unpaid 402 amounts against OpenAPI, MCP descriptions, and llms.txt. This is clear enough to distinguish it from generic x402 checks, though it does not explicitly name or contrast sibling tools such as benchmark_x402_price or x402_listing_audit.

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

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

It gives useful boundaries — partial coverage, origin-only unless fetch_directory_claims, no seller payments, one unpaid request per route — which implicitly frame appropriate use. However, it never explicitly says when to choose this tool over adjacent x402 audit, benchmark, or listing tools, leaving alternative selection to inference.

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

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

Beyond the read-only/non-destructive annotations it discloses that nothing is signed or sent, the 3-15 s latency, pricing (USD 0.005), free quota (10 reads/IP/day), error semantics (422 bad input, 502 failed read, neither charged), and the risk-tier logic (high/medium/low). These are precisely the operational traits annotations cannot carry.

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

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

Front-loaded with purpose and alternatives, and the pricing/error/latency facts each earn their space. The mid-paragraph risk-tier enumeration is telegraphic and dense, slowing comprehension slightly, but no sentence is filler.

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

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

For a 6-parameter, paid, open-world read with an output schema, everything an agent needs is present: scope, default behavior, coverage limits, failure codes, cost, latency, and a docs link. Return-value shape is correctly left to the output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning on top: it explains what the default scan actually covers (approval events in the latest 6,000 blocks plus Permit2 and `spenders`) and frames `spenders` as the full-coverage path for known spenders, which clarifies intent beyond the field text.

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

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

The opening sentence gives a specific verb and resource ('List a wallet's live token approvals and get revoke transactions') and immediately names the two siblings it is not: check_wallet_drain and get_allowance. An agent can distinguish it from neighbors 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?

Explicit routing is given: check_wallet_drain for tokens already pulled, get_allowance for a single allowance. It also states a coverage boundary ('Older approvals are found only via `spenders` or Permit2'), which tells the agent when this tool will miss things and how to compensate.

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/closed-world, yet the description still adds substantial context beyond them: hard limits (100,000 lines, 20 MB, 64 KiB per line), per-block pricing with no free tier, ~1 s latency, and a privacy guarantee that submitted text is never logged or stored. It also flags a prompt-injection trust boundary for returned page text and on-chain strings. The only gap is that it doesn't describe the shape of the burst/cohort results, which is partly covered by the output schema.

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

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

Front-loaded with purpose and the sibling routing rule, then limits, price, and trust notes in a compact telegraphic style. It is dense but somewhat cluttered with fragments and repeats the line/size limits already present in the schema.

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

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

Given a paid, rate-limited analysis tool with an output schema, the description covers everything an agent needs before calling: input format and size caps, cost model, latency, privacy, and the untrusted-data warning. Return-value details are correctly left to the output schema.

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

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

Schema description coverage is 100%, so both `logs` and `origin` are already fully documented in the schema, including that `origin` drives self-referrals and asset links and is never fetched. The description restates rather than extends that information, 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 ('Review supplied web logs') and enumerates the outputs: referrer cohorts, self-referrals, asset links and bursts. It explicitly distinguishes itself from the sibling analyze_agent_traffic by domain (AI client classes and robots rules), 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 and the exact condition that selects it ('For AI client classes and robots rules use analyze_agent_traffic'), which is the key routing decision among these siblings. Also implies the input precondition (logs must be supplied, no fetching) that gates use.

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?

Beyond the annotations (destructive=false, idempotent=true, openWorld=true), it discloses hard limits (100 slides, 2,000 chars per text, 250,000 per deck), the 422 error behavior and that failures aren't charged, price USD 0.005 with no free tier, sub-1s latency, and an untrusted-content warning. That is unusually rich behavioral context an agent cannot infer 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 purpose and sibling routing, then packs limits, output format, pricing, and safety into a compact block. It is dense but nearly every sentence carries operational value; only the docs URL and some schema restatement are slightly redundant.

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

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

Covers limits, error behavior, pricing, latency, output shape, and a prompt-injection caveat, and an output schema exists so return values need no further explanation. An agent has everything required to call it correctly and set expectations.

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 still adds value by restating the meaningful constraints (20-bullet cap, layout choices, theme font/accent_color) and clarifying that output=url yields a 24 h link. It mostly mirrors schema detail rather than adding new semantics, so it sits just 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 ('Generate a PowerPoint deck from JSON slides') and immediately scopes the inputs (titles, bullets, speaker notes). It explicitly distinguishes itself from build_xlsx_workbook and fill_docx_template, so an agent can route correctly among the output-format siblings.

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 alternative tools by name and the condition that selects them (workbook -> build_xlsx_workbook, Word file -> fill_docx_template), and clarifies the tool is text-only with no images. The remaining ambiguities are minor because the sibling routing is explicit.

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

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

Annotations only give the safety profile (readOnly=false, destructive=false, idempotent=true); the description adds the operationally important facts: hard limits (20 sheets, 50,000 cells, 32,767 chars/cell, 31-char sheet names without [ ] : * ? / \), that exceeding them is a 422 and not charged, that strings are never interpreted as formulas, expected latency under 1 s, and a price of USD 0.005 with no free tier.

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

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

The core action and sibling routing are front-loaded, then limits, error behavior, latency and price in a compact run of sentences. Dense but every clause carries information an agent needs; only the docs URL feels like appended boilerplate.

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-call generation tool with a full output schema, the description covers what remains unaddressed elsewhere: quotas, failure mode and its billing implication, latency, cost, string-as-text semantics, and a docs link. 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 description coverage is 100%, so the baseline is 3; the description still adds value by spelling out the column `type` enum and clarifying that a type sets the cell number format. It repeats rather than extends most other parameter detail, so it does not push to a 5.

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

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

Specific verb + resource (build a styled Excel workbook from JSON sheets, columns and rows), and it explicitly names the inverse tool (convert_excel_to_json) and the sibling for slides (build_pptx_deck). An agent can tell this apart from every other build/convert tool in the family without opening a schema.

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

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

It routes the agent explicitly: read-back goes to convert_excel_to_json, slides go to build_pptx_deck, and it documents format/limit constraints that determine whether it can be used at all. It stops short of stating when-not-to-use conditions beyond those alternatives, so it lands just under a 5.

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

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

Goes well past the annotations by disclosing price (USD 2, no free tier), per-IP daily caps, latency (1-5 s), row caps (5,000 rows/source), capped/complete flags, and a prompt-injection safety note about treating endpoint names/URLs as untrusted data. The mid-sentence aside about how delta_cursor behaves for agent_index_delta is confusing and partly belongs to the sibling tool, which costs it the top 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?

Front-loads the name and price, and most sentences carry real information, but the whole thing is a semicolon-chained blob with no paragraphing. The delta_cursor/null-return digression about agent_index_delta dilutes focus on this tool, and query_agent_index appears late after other alternatives were already enumerated.

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?

Because an output schema exists, return values need no explanation, yet the description still covers price, auth, caps, latency, and a security caveat — enough to call correctly. The phrase "authorize client per-call and remaining daily caps to cover the price" is awkward and leaves the exact payment/auth flow slightly ambiguous.

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 optional parameter is already documented as "Filter: exact source id." The description only echoes this with "optional source filter," adding no format, matching, or omission semantics 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 ("Download the current snapshot (gzipped)") with scope qualifiers (full snapshot, optional source filter). It explicitly distinguishes itself from three siblings — export_agent_index for filtered slices, agent_index_delta for refreshes, query_agent_index for narrower queries — 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/when-not routing: "For a filtered slice use export_agent_index; to refresh an existing copy use agent_index_delta" and "for a narrower query use query_agent_index." Prerequisites (paid, no free tier, per-call authorization, daily cap) are stated up front.

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?

Substantially exceeds the annotations: it discloses cache/ID semantics ('IDs require identical bytes, extractor version and config'), partial-result behavior ('Missing spans listed'), latency ('Up to 70 s'), cost ('USD 0.02 per started 10-page block... No free tier'), retention ('kept only with output url (24 h)'), and an explicit prompt-injection warning about returned page text. These are exactly the operational facts annotations cannot carry.

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

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

Purpose is front-loaded, but the body is a run-on of terse fragments ('output=url links JSON 24 hours; manifest inline..') with a stray double period and duplicated size limits that the schema already states. Most content earns its place, yet the packaging makes it harder to parse than necessary.

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

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

For a paid, open-world, non-read-only tool this covers everything an agent needs before calling: input alternatives, page-selection legality, size caps, determinism/ID requirements, latency, price range, retention and data-handling policy. An output schema exists, so return-value explanation is correctly omitted.

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

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

Schema description coverage is 100%, so the schema already documents url, pages, output, chunk_chars, file_base64 and reading_order, including the enum meanings. The description mostly restates these ('required closed numeric pages', '20 MB URL/10 MB inline') rather than adding syntax or edge-case semantics, 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: 'Bundle PDF chunks with page citations,' and the 'No OCR or embeddings' clause narrows what kind of extraction this is. It does not name any PDF sibling (extract_pdf, pdf_extract_pages, paper_digest) to route an agent between them, so differentiation is left partly to inference.

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

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

It gives input-source guidance ('url or file_base64') and the hard constraint that pages is a required closed numeric selection within 1-100, which implies usage. But there is no explicit when-to-use/when-not or named alternative among the many PDF tools, so an agent must infer the 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 only cover safety hints; the description adds cost (USD 0.02, no free tier), latency (5-20 s, max ~75 s), charging rules (failures not charged), private-target rejection as 422, per-file page loads, 24-hour link expiry, 12 MB base64 cap, and the signing key. That is meaningful behavior beyond the structured fields.

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

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

Front-loaded with purpose then routing, followed by return details, limits and pricing. Dense but mostly earns its place; the trailing prompt-injection warning is useful for this tool but slightly dilutes an already long block.

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 still summarizes the manifest, hashes and files accurately, and covers cost, timing, failure modes and privacy restrictions. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds value by explaining the 24-hour url vs inline base64 tradeoff, the 12 MB limit, and the five files returned. It stops short of anything the schema doesn't already touch, so not a 5.

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

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

States a specific verb and resource ('Capture a web page as evidence: screenshot, PDF, text, SHA-256 hashes, signed manifest') and explicitly contrasts itself with three narrower siblings. An agent can distinguish it from take_website_screenshot, render_page and html_to_pdf without opening any schema.

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

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

Names all three alternatives and the exact condition that selects each ('For one image alone use take_website_screenshot; for the text alone use render_page; for a PDF alone use html_to_pdf'). This is precisely the when-to-use/when-not-to guidance the dimension rewards.

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 the tool as read-only and non-destructive, but the description adds substantial context beyond them: fixed public RPCs, no archive/trace guarantee, history pruning, body/params/reply size limits, per-attempt and whole-call timeouts, slot concurrency, method-specific constraints for logs and feeHistory, error charging policy, price (USD 0.001, no free tier), and an untrusted-data warning. These details are critical for correct invocation and set clear expectations.

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 key limits, but it is a dense, fragmented block of many short sentences. It includes redundant constraints already present in the schema and could be better organized (e.g., separate operational limits from security notes). Not excessively long for the complexity, but not as crisp as it could be.

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

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

Given the complexity, rich schema, output schema, and annotations, the description covers most operational aspects an agent needs: supported chains, method allowlist, size/time limits, pricing, and safety warnings. The main gap is the lack of routing guidance versus sibling tools, but that is more of a usage-guideline issue. Overall, the description is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so the schema already fully documents all parameters. The description lists the input fields and repeats some constraints (e.g., params limits, logs/feeHistory rules), but adds little beyond what the schema provides. Baseline 3 is appropriate when the schema carries the primary explanatory load.

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

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

The description states a specific verb and resource: 'Read one allowlisted, read-only EVM JSON-RPC method.' It also lists supported chains and input fields. However, it does not differentiate from sibling tools like eth_call, get_block, or get_balance, leaving the agent to infer when to use this generic passthrough rather than a dedicated tool.

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

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

There is no explicit guidance on when to use this tool versus the many dedicated blockchain sibling tools (e.g., eth_call, estimate_gas, get_block). The description lists exclusions ('No batches/writes/signing/filters/overrides') but does not name alternatives or conditions that select this tool over others.

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 already declare read-only, idempotent, open-world, non-destructive, so the bar is lower, yet the description adds substantial behavior: one pass, request/time/size budgets (60 requests, 25 s, 8 MB), a failing part reported as an error rather than a failed call, 422 not charged, typical 3-10 s latency, price USD 0.01 with no free tier, and a prompt-injection warning on returned text. Only return-shape detail is ceded to the output schema.

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

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

Front-loads purpose, returns, and sibling routing before the operational constraints; every clause carries distinct information (limits, pricing, failure semantics). Dense and clause-heavy rather than padded, but slightly hard to scan as one long run-on 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?

For a single-parameter, read-only, output-schema-backed tool, the description covers cost, latency, scope limits, failure modes, address restrictions, and a security caveat. Nothing an agent needs to decide-and-call correctly is missing.

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

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

Schema coverage is 100% and the schema already explains the origin-only semantics, https/443, no IP, no user info. The description adds nothing beyond repeating 'one URL', 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 output form ('returns 0-100 scores') plus the exact dimensions scored: llms.txt, robots for 16 AI agents, sitemap, schema.org, OpenAPI, .well-known, MCP endpoint, sign-up-free access, pay-per-call. It explicitly distinguishes itself from siblings check_robots_txt, check_mcp_server, and generate_agent_ready_files.

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: use check_robots_txt for a single URL's robots rule, check_mcp_server for a live MCP probe, generate_agent_ready_files to fix. Also states preconditions (public https, port 443) and the when-not case (private/malformed address → 422).

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 by disclosing cost (USD 0.01/Actor), the 1-20 cap, that it is public API reads only, that results are heuristics rather than Apify's own decision, timing expectations (2-10s, up to a minute for 20), and a prompt-injection warning about untrusted returned text. These are meaningful operational caveats not derivable from the readOnly/idempotent annotations.

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

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

Front-loaded with the purpose and alternative routing, which is good, but the text is redundant: pricing is stated twice ("USD 0.01 per Actor, up to 20" and again "Price: USD 0.01 per Actor (1-20 Actors per call)"), and the untrusted-data warning appears twice. Several sentences could be merged without loss.

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-value explanation is unnecessary, and the description covers everything else an agent needs: scope, cost, limits, timing, interpretation caveats, and safety warnings. Complete for this tool's complexity.

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 'actors' param is fully documented in the schema with its accepted id/username~name/URL formats. The description reiterates the 20-item cap and cost but adds no format or syntax 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 (check) and resource (Apify Actors against Store publishing rules), and enumerates the exact checks performed (outside payment links, README/pricing disagreements, near-duplicate listings). It explicitly distinguishes itself from sibling alternatives, so an agent can route correctly 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 names the alternatives and the conditions that select them: preflight_mcp_listing for an MCP server repo vs an awesome list, and check_agent_readiness for a site's AI-agent readiness. This is textbook when-to-use/when-to-use-something-else guidance.

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

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

Annotations already 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 cover only the safety profile (readOnly, idempotent, non-destructive); the description adds substantial context beyond that: offline execution, no DRM removal or script execution, no repair or publisher certification, no logging of input/results, temp files deleted, a 45-second runtime ceiling, and a prompt-injection warning about returned text. That is exactly the extra behavioral layer the annotations cannot express.

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

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

Dense but nearly every clause carries distinct information (tool identity, engine version, exclusions, privacy, price, runtime, safety warning), and the core purpose is front-loaded. Minor waste from the stray '..' and the mildly redundant 'Offline; 10 MB' / 'Unsafe/encrypted input refused' pairing.

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 described, and the description covers the operational envelope an agent needs: input limits, refusal behavior, pricing, latency, privacy handling, and an untrusted-output warning. Only the lack of explicit alternative-routing keeps it from a 5.

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

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

There is a single parameter with 100% schema description coverage — the schema already documents base64 encoding, the 10 MB decoded cap, and the encrypted-file exclusion. The description restates the size limit and refusal rule but adds no new syntax or format detail, so the baseline 3 for high schema coverage 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 — validate/check EPUB 2/3 files using pinned EPUBCheck 5.4.0 — which clearly separates it from the PDF/office siblings in the list. The phrasing is slightly garbled ('Returns checks one EPUB 2/3 with pinned EPUBCheck'), which keeps it just short of a 5, but the intent is unambiguous.

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

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

The description gives operational constraints (10 MB cap, encrypted/unsafe input refused, no repair, up to 45 s, paid) that implicitly define when the tool applies, but it never names an alternative or says explicitly 'use this when you need spec conformance, not repair' beyond the negative list. Usage is implied rather than routed.

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 annotations: discloses that only names and sizes are returned, never header values; that results are estimates; the 1-4s typical runtime and 25s wall-clock limit; cost ($0.002) and free tier (10/day per IP); and a prompt-injection caution about treating page text as untrusted. These are exactly the behavioral facts an agent cannot get from readOnlyHint/idempotentHint alone.

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

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

Purpose is front-loaded and nearly every clause carries information (returns, cost, timing, safety). It is dense to the point of being a run-on, and the 'limit overrides' phrase costs clarity, but there is little pure filler.

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

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

An output schema exists, yet the description still sketches the return shape, error behavior, cost model, timing bounds, and trust posture. For a single-parameter read-only measurement tool, 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% for the single url parameter, so baseline is 3. The description reinforces constraints (public HTTPS, port 443, no redirects) but also mentions 'limit overrides' that do not appear as parameters in the schema, which adds slight ambiguity rather than clarifying argument semantics.

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 (measure) and resource (response headers) and names the exact comparison targets (nginx, aiohttp, Node fetch, Python limits). This distinguishes it from siblings like check_security_headers and get_page_meta 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 clear operating context: one unpaid public-HTTPS GET, no redirects or body read, and invalid/unreachable hosts return 422 without charge. It does not explicitly name a sibling alternative or state when-not to use it (e.g., vs check_security_headers), which keeps it below a 5.

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

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

Beyond the annotations, it discloses the probe mechanics (one probe from Tanod's servers, no credentials, port 443, no redirects, 15 s cap), billing behavior (unresponsive servers are charged, malformed or private addresses are a 422 and not charged), pricing, rate limits, and an untrusted-output warning, none of which 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 and routing to siblings before logistics. It is densely packed with pricing, timing, limits, and a security note in one paragraph, which is efficient but slightly overstuffed for a single-input tool.

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

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

Even though an output schema exists, the description summarizes the returned fields (name, version, protocol, sign-in, tool count and names, latency, TLS expiry, status class) and covers error semantics, timing, cost, and trust guidance. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already spells out 'host name only, port 443, no user info', so the description's 'public https URL of the MCP server endpoint' is largely redundant. The 422-for-private-address note adds a little meaning but is behavioral rather than parameter-level. Baseline 3 fits.

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

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

The first sentence states a specific verb and resource ('Check whether a remote MCP server is up and what it offers') and explicitly contrasts itself with scan_agent_package and preflight_mcp_listing, so the agent can separate it from the closest siblings without opening a schema.

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

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

It gives explicit exclusions ('It reads no code') and names two alternatives with the conditions that select them (scan a package before installing, check a repo against an awesome list). The scope is also bounded by public-only, https-only, one-probe semantics.

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/non-destructive annotations: 10 MB size cap, 25 s runtime, refusal of encrypted files, price of USD 0.01 with no free tier, 'failures not charged', and an explicit prompt-injection warning about returned page text and on-chain strings. These are exactly the operational facts an agent needs before calling a paid, closed-world tool.

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

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

Front-loads purpose then packs limits, cost and safety in short clauses with zero filler. Some fragments are garbled ('Returns runs PDF/UA-1 or PDF/UA-2 machine checks') and read as compressed notes rather than clean prose.

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

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

With an output schema present, the description need not explain return structure, and it still summarizes what comes back (rule, page and object evidence, fix hints, unperformed manual checks) while covering cost, limits, encryption refusal and untrusted-input handling. 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 parameters (standard, file_base64) are already documented with enum values and size bounds. The description only restates that ua1/ua2 correspond to PDF/UA-1/PDF/UA-2 and adds no format or encoding guidance beyond the schema, so the baseline 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 PDF against PDF/UA machine rules') and names the two standards (PDF/UA-1/UA-2, veraPDF) plus the input contract (one inline PDF). It does not differentiate itself from the nearby sibling validate_pdf_a, which an agent could easily confuse with this tool.

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

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

Adds a useful scope exclusion ('Not a full review or legal compliance finding') and a hard precondition ('Encrypted PDFs refused'), but never names an alternative tool or says which situations should route elsewhere (e.g. validate_pdf_a). Usage is implied rather than directed.

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?

Beyond the annotations, the description discloses important behavior: only the submitted report is read, invalid reports or ratings return 422 and are not charged, errors and verdict reasons are returned, the tool is fast, pricing and free-pool limits apply, and submitted text is never logged or stored. These details align with readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false.

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 return behavior, followed by constraints, billing, and privacy details. It is dense but largely earns its space; minor redundancy appears in repeating smartctl or nvme smart-log after already saying Check an SSD's wear.

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-parameter read-only utility with full schema coverage and an output schema, the description is complete: it covers input expectations, output summary, limitations, error handling, pricing, privacy, and performance. Nothing material needed to invoke the tool correctly appears to be missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context about the optional rated_tbw parameter by explaining that it enables rated-TBW share and gap analysis. It also reinforces that report must be smartctl or nvme smart-log text/JSON, though most parameter detail is already in the schema.

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

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

The description names a specific verb and resource: check an SSD's wear from a pasted smartctl or nvme smart-log report. It also distinguishes the tool from merely reading SMART PASSED status and lists the concrete outputs, including percentage used, TBW, verdict, and reasons, so an agent can identify its role 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?

It clearly establishes the required input context, namely a pasted smartctl or nvme report, and states that no commands are run or network calls made. It also warns that SMART PASSED does not rule out failure and that SATA wear is vendor-specific, giving useful when-to-use limits, though it does not name alternative sibling tools.

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

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

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.