Grokzilla Micro Pay

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

With no annotations present, the description carries the load well: it discloses that validation is local, that an RPC call happens only when check_code is set, and names the price ($0.001 via x402). It does not spell out failure behavior (malformed input, unsupported chain) or the full response shape.

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

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

Four short sentences, front-loaded with what the tool does, then cost and RPC behavior. No filler; each sentence contributes a distinct fact.

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

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

There is no output schema, so the description must convey return values, and it only partially does — the eoa|contract label is mentioned but the overall result (validity flag, normalized address, detected chain) is not. Pricing and RPC behavior are covered, so it is adequate but not complete.

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

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

Schema coverage is 75%, and the description adds real meaning on top: it maps chain values to the specific validation algorithms used and explains that check_code triggers eth_getCode on Base to yield eoa|contract. The 'auto' value and the request_id idempotency behavior are left to the schema.

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

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

States a specific verb and resource (validate an address) plus the exact chains and algorithm families covered (EIP-55 checksum, base58, bech32). An agent can distinguish this from siblings like token_risk or erc20_meta 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?

Offers real context for invocation — local validation by default, no RPC needed, optional eth_getCode on Base — but never says when to prefer this tool over a sibling (e.g. token_risk) or when chain=auto should be chosen versus an explicit enum. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it lists specific checks (robots rules per bot, live user-agent probes, llms.txt, sitemap, JSON-LD, canonical host, agent interfaces), clarifies limitations ('Does not guarantee crawling, ranking, citation, or traffic'), and explains charging behavior ($0.0499, no charge on 422). It doesn't describe the return format, which prevents a higher 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?

The description is front-loaded with the core purpose and packs useful details into a few sentences. It is dense but every clause adds value; minor improvement could come from clearer separation of checks vs. limitations vs. pricing.

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

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

Given the tool's complexity (multi-check audit) and lack of output schema or annotations, the description covers what is checked and what is not guaranteed, but omits how to invoke it (required inputs) and what the response looks like. That leaves an agent without enough to call it confidently.

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

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

The tool has 0 parameters, so baseline is 4. The schema is fully permissive with no documented fields, and the description adds no guidance on what to send (e.g., a URL), but the absence of parameters means the description isn't expected to explain them.

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

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

The description states a specific verb ('Audits') and resource ('how AI crawlers and agents can reach and read a site') with a detailed list of checked aspects (robots rules, probes, llms.txt, etc.). It clearly distinguishes from generic SEO tools, though it doesn't explicitly contrast with sibling tools like agent_ready_kit or agent_ready_recheck.

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

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

The description implies the tool is for auditing AI crawler accessibility but never states when to use it versus alternatives. It mentions pricing and a no-charge condition for blocked/unreachable sites, but provides no guidance on when to choose this over agent_ready_kit or agent_ready_recheck.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the charge ($0.2502 via x402), the exact no-charge condition (site blocks us or is unreachable → 422, charged:false), the license restriction (No-Resale, LICENSE.md in zip), and that unknown facts are emitted as TODO rather than fabricated. What it omits is any statement of what input the caller must supply, which for a paid invocation is a notable behavioral gap.

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 deliverable list, then billing, license, and failure semantics — the ordering matches decision order. It is dense and slightly list-like, but every clause (price, 422 refund rule, TODO convention, license) carries information an agent or its user needs before paying.

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

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

There is no output schema, so the itemized deliverables do a fair job of describing the return. For a paid, non-idempotent generation tool, though, the missing input contract is a real hole: the description covers cost, license, and failure handling but never says what to send or how long generation takes.

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?

Parameter count is zero and the schema is explicitly permissive ('MCP does not constrain fields... send the same JSON object the HTTP endpoint accepts'), which is not the same as a genuinely parameterless tool. The description adds no information about what fields to send (presumably a url/site), so the agent is left guessing at the request body despite 100% schema coverage — coverage here documents the absence of spec, not parameter meaning.

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

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

The description names the concrete artifact produced (an audit plus a zip of llms.txt, llms-full.txt, robots.txt AI section, sitemap.xml, JSON-LD/meta/OG per page, agent card, install guide), which is more specific than a generic verb+resource. It is implicitly distinguishable from agent_ready_audit and agent_ready_recheck by the deliverable list, but it never states the contrast outright, so an agent must infer which sibling to pick.

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 only implied by the contents: an agent can guess this is the 'generate everything' counterpart to agent_ready_audit, but there is no explicit when-to-use, when-not-to-use, or named alternative. No prerequisites (e.g., site must be crawlable) are stated beyond the incidental remark that blocking yields a 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?

With no annotations, the description does substantial lifting: it discloses the price ($0.0102 via x402), the failure-billing policy (uncharged on 422/unreachable), and what the result contains (fixed vs. regressed findings). It omits auth requirements and what happens when the report_id is older than 30 days, which keeps it from a 5.

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

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

Three short sentences: purpose and input first, then return content, then billing/failure semantics. Every sentence carries information an agent needs, and nothing is repeated from 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?

Without annotations or an output schema, the description must cover cost, failure behavior, input provenance, and return shape — and it does all four briefly. The gaps are edge cases: expired/unknown report_id behavior and the exact request field name given the unconstrained 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?

The schema is a permissive object with no defined properties, so field names are not constrained or documented anywhere else; the description's mention of "report_id" is the only signal about what to send. It does not state the literal key name or any other accepted fields, leaving some guesswork.

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 ("Re-runs an Agent-Ready audit") and pins the input to "its report_id", which functionally separates it from the sibling agent_ready_audit that presumably creates the initial report. It does not name the sibling outright, so the agent must infer the relationship rather than be told it.

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?

"Re-runs ... from its report_id (30 days)" makes the precondition clear: you need an existing report from a prior audit and it must be within a 30-day window. No explicit when-not guidance or named alternative (e.g. "if you have no report_id, use agent_ready_audit") is given, so the routing is implied rather than stated.

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

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

With no annotations, the description carries the burden well: it discloses the ~78% benchmark accuracy and explicitly warns it is 'not a guarantee', flags uncertainty behavior, and states the $0.01 x402 payment requirement. It omits whether fetching a url is side-effect-free, how errors surface, or what the response shape is.

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

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

Dense but front-loaded: purpose first, then accuracy caveat, then rerun guidance, then pricing. Every clause carries information, though the run-on middle sentence packing rerun advice and tell-phrase caveats together 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?

There is no output schema and no annotations, so the description should describe the return value — it never says whether the tool returns a label, probability, or phrase list, only alluding to 'tell phrases'. Cost, accuracy and input handling are covered, but the output contract is a meaningful gap for a classifier tool.

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

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

Schema description coverage is 0% and both parameters are undocumented in the schema, so the description must compensate. It does clarify the url-vs-text duality ('text (or a web page's text)'), but never states that the two are mutually exclusive or that one is required despite both being optional 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?

States a specific verb ('estimate whether') and resource ('text is AI-written using a trained classifier'), plus the alternative input form (web page text). No sibling tool in the list does anything comparable, so the purpose is unambiguous without opening the schema.

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

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

Gives concrete operational guidance: rerun on a longer section (300+ words) when results are uncertain, and treat tell-phrases as only a secondary signal. It does not need to name an alternative tool since none exists, but it also never states the precondition that at least one of url/text must be supplied.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that the operation is deterministic, requires no network, and costs $0.003 via x402, but says nothing about error behavior on invalid decode input, output format, or the 400,000-character input ceiling.

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

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

Two compact sentences, front-loaded with the core capability and followed by supporting facts about determinism and pricing. The telegraphic 'Deterministic, no network. Price $0.003 via x402.' fragments are dense but each earns its place.

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

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

For a 4-parameter tool with no annotations, no output schema, and zero schema description coverage, the description covers codec semantics but omits return-value shape (especially for decode), failure modes, and size limits, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the codec choices in detail (base58 Bitcoin alphabet, URI percent-encoding) and clarifies that url_safe means standard vs URL-safe, but it never explains the required `mode` parameter as a field nor the role and limits of `text`.

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

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

States a specific verb pair (encode/decode) and resource (UTF-8 text) and enumerates the exact codec family supported, which cleanly separates it from siblings like sha256 or uuid_mint that also transform text.

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

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

The description explains what can be encoded but gives no when-to-use guidance, no conditions for choosing between this and sibling text-transform tools, and no exclusions. The 'default' note on base64 is a schema default, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses caching (~2s) and a per-call price ($0.001 via x402, implying payment/auth), but omits return shape, error behavior, and what happens when multiple chains are requested.

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

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

Two compact sentences, front-loaded with the core purpose, then caching and cost. Every clause carries operational information with zero filler.

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

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

With three optional params, no annotations, and no output schema, the description should clarify the return structure (e.g., one block number per requested chain). It covers cost and caching but leaves output shape 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 coverage is 67%, and the description maps to two of three params ('Base and/or Ethereum' for chains, 'optional block timestamp' for include_timestamp). It adds little beyond the schema and says nothing about request_id, so it neither compensates fully nor adds much value.

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

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

States a specific verb and resource ('Latest eth_blockNumber for Base and/or Ethereum'), which is clearly distinguishable from siblings like gas_price or tx_status. The scope (which chains) is explicit, though sibling differentiation is only implicit.

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

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

The description implies it returns the current tip block number, but offers no explicit when-to-use guidance or alternatives. There is no statement of when a caller should choose this over gas_price or tx_status, leaving routing to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses determinism, no network access, DST-aware behavior, and the x402 payment model. It omits error behavior for invalid expressions and whether 'from' defaults to now, which are the remaining gaps.

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

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

Two dense sentences, fully front-loaded with the operation and its output before mentioning cost. Every clause carries information, and there is no filler.

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

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

With no output schema, the description correctly explains return values (local ISO, UTC ISO, epoch seconds) and the count range. It is close to complete, but the unexplained 'from' parameter and absence of error semantics for invalid expressions leave small gaps.

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

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

Schema coverage is 0%, so the description must compensate. It covers expr ('5-field cron expression'), tz ('any IANA time zone'), and count ('next 1-20 run times'), but the 'from' parameter is never explained or even referenced, and no format details for the date/time inputs are provided.

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 verbs (validate, return) applied to a concrete resource (5-field cron expression) with a quantified output (next 1-20 run times). It also enumerates supported syntax (lists, ranges, steps, JAN-DEC/SUN-SAT, @macros), which separates it cleanly from siblings like epoch_convert.

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

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

The description implies its use case (getting upcoming cron run times) but never states when to prefer it over alternatives such as epoch_convert, nor any exclusions or prerequisites. No explicit when-to-use guidance is given.

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

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

With no annotations, the description carries the full burden. It does disclose two valuable traits beyond the schema: the operation is deterministic/no-network and it is a paid endpoint requiring x402 payment ($0.003). However, it says nothing about behavior on malformed CSV, duplicate headers, oversized input (the schema caps at 400k chars), or whether the type hint is advisory or coercive.

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

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

Three short sentences, front-loaded with the core transformation and output shape, followed by determinism and pricing. No filler; every clause carries information an agent needs.

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

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

No output schema exists, so the description correctly spends its words describing the return shape (keyed rows plus type hints). The payment requirement is disclosed. The remaining gaps are the undocumented delimiter parameter and undefined failure/limit behavior, which are minor for a two-parameter utility.

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

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

Schema description coverage is 0% and the description never mentions the `delimiter` parameter or its allowed values, nor explains the `csv` input format. The enum in the schema constrains delimiter options, but the description adds no meaning on top of it, leaving half the parameters undocumented in prose.

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 (Parse CSV) and goes further to specify the output contract: JSON rows keyed by trimmed snake_case headers with a per-column type hint. No sibling in the set does CSV work, so no differentiation is needed and none is owed.

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

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

Usage is implied by the purpose (you have CSV, you want normalized JSON rows) but there is no explicit when-to-use statement, no prerequisites, and no named alternative or boundary condition. No sibling competes here, which softens the omission but does not supply guidance.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: primary and fallback resolvers, rejection of IP literals and private names, and a per-call price of $0.002 billed through x402. It omits rate limits, failure/error behavior, and the shape of the response.

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

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

Three tight sentences: capability first, input constraints second, cost last. Every clause earns its place and nothing is repeated.

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

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

For a simple stateless lookup with no output schema and no annotations, the description covers provider, valid input domain, and pricing — the things an agent needs before calling. The notable gap is that nothing describes the returned record structure, which the absent output schema would otherwise require.

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

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

Schema coverage is 67%, so the baseline is 3. The record-type list in the description duplicates the schema enum and the 'name' description already says 'Hostname to look up', so no meaning is added beyond what the schema provides; the optional idempotency key is documented only 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?

Names a specific verb and resource (DNS-over-HTTPS lookup) and enumerates the record types returned, plus the upstream resolvers. It is clearly a DNS query tool rather than a validator, but it never distinguishes itself from the sibling name_resolve, which could plausibly overlap.

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

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

Usage is only implied: the input-domain constraints ('Rejects IP literals and private names') tell the agent what will fail, but there is no explicit statement of when to pick this over name_resolve or address_validate.

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

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

With no annotations, the description carries the full behavioral burden and does so: it discloses the method (DNS-over-HTTPS), the safety boundary (no mailbox probing), the billing exception ('Not charged if the DNS lookup fails'), and the price ($0.0032 via x402). It also characterizes the return ('One verdict with reasons and sources'). Cost and failure-billing semantics are exactly the traits an agent needs before invoking a paid tool.

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

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

Three dense sentences, front-loaded with what is checked before method, billing, and price. Every clause carries information an agent can act on; there is no filler.

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

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

With no output schema and no annotations, the description still tells the agent what is checked, what comes back, what the method is, and what it costs. The only real gap is that `request_id` and the email length bounds are never acknowledged, so a caller could miss the idempotency mechanism entirely from the prose.

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

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

Schema coverage is only 50%: the required `email` parameter has no description, while `request_id` documents its own idempotency semantics. The description says it checks 'an email address' but adds nothing about format constraints (minLength 3, maxLength 254) or about the idempotency key, so it does not compensate for the uncovered half.

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

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

Names a specific verb (Check) and resource (email address) and then enumerates exactly what is verified: syntax, canonical form, MX, SPF, DMARC, disposable domain. No sibling tool in the list overlaps with email deliverability, so the agent can place it unambiguously.

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

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

The scope line 'DNS-over-HTTPS only, no mailbox probing' tells the agent this is a passive, non-intrusive check and rules out a class of use (mailbox verification), which is genuine usage context. It does not, however, state when to prefer it over another approach or any prerequisites, so it falls short of a full when/when-not statement.

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

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

With no annotations, the description carries the behavioral burden and does disclose meaningful traits: deterministic execution, no network dependency, and the x402 price. It does not cover error behavior (e.g. invalid inputs) or rate limits, but it adds real context a caller would want.

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

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

Two dense sentences with zero filler, front-loading the conversion contract before the deterministic/network/pricing notes. The pricing tail is slightly extraneous to conversion semantics but is short and informative.

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

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

No output schema exists, so the description correctly enumerates the return values (epoch_s, epoch_ms, UTC ISO, and ISO in the requested zone), which is what an agent needs. Combined with the disclosed cost and determinism, it is nearly complete for a 2-param conversion tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains that `value` accepts epoch seconds/milliseconds (auto-detected by magnitude) or an ISO-8601 string, and that `tz` is an IANA time zone applied to the ISO output. The default UTC value's behavior is not spelled out, but the core semantics are conveyed.

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

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

States a specific verb (convert) and precisely enumerates the accepted input forms (epoch seconds, milliseconds detected by magnitude, or ISO-8601 string) and the outputs produced. No sibling tool does time conversion, so the agent can identify this tool's role unambiguously.

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

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

Usage is implied by the conversion enumeration, and the input-format detection rule is stated, but there is no explicit when-to-use or when-not-to-use guidance and no alternatives named. Adequate for a single-purpose utility but not directive.

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

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

With no annotations, the description carries the behavioral burden and discloses several important traits: multicall3 batching, supported chains, a 400 error for non-contract addresses, and a $0.002 x402 price. It does not cover rate limits, partial multicall failures, or response shape, so it is strong but not exhaustive.

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

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

The description is compact, front-loaded with the core operation, and every sentence adds useful information about scope, errors, or pricing. There is no wasted text.

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

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

For a four-parameter read tool with no output schema, the description adequately lists the returned metadata fields and includes important error and pricing context. Minor gaps remain around output structure and request_id behavior, but those are partly covered by the schema.

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

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

Schema coverage is 75%, so the baseline is 3. The description adds some mapping for chain and holder balanceOf, but it largely repeats schema-provided meaning and does not explain request_id or idempotency behavior.

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: read ERC-20 name, symbol, decimals, totalSupply, and optional holder balanceOf. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as token_price or token_risk.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and the description does not route the agent away from related siblings like token_price or token_risk. The intended use is inferable from the stated purpose but is not actively guided.

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

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

With no annotations, the description does real work: it discloses the 10s cache TTL, the paid x402 cost of $0.001, and that data comes from eth_feeHistory. The one weak point is the 'optional eth-transfer USD estimate' — nothing in the schema lets the caller request it, so the behavior is stated but not actionable, and no error/rate-limit behavior is described.

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

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

Four short sentences, front-loaded with what is returned and for which chains, then cache, optional feature, and price. Every sentence carries distinct operational information with no filler.

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

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

For a 2-parameter, no-output-schema tool this is largely sufficient: it names the metrics, the chains, the data source, price, and caching. The gaps are the un-parameterized USD estimate and the absence of any note on output shape when both chains are requested.

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

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

Schema coverage is 50%; request_id is fully documented in the schema itself, and the description adds meaning only for 'chains' by saying 'Base and/or Ethereum'. It does not explain default behavior when chains is omitted, nor the per-chain output differences, so it neither compensates for the coverage gap nor adds much beyond it.

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

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

Names a concrete resource (EIP-1559 base fee and priority fee percentiles p25/p50/p90) over specific chains, and discloses the underlying source (eth_feeHistory). It is clearly distinguishable from siblings like token_price or llm_cost_quote, so an agent knows exactly what this returns.

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 only implied by the subject matter — call it when you need gas fees. There is no explicit when-to-use/when-not, no routing to alternatives (e.g. erc20_meta or token_price for token-level pricing), and no stated defaults beyond the schema's 'base' default.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description still adds real context by disclosing that the call is free, that unknown ids produce a tool error, and what the response includes. It stops short of describing output structure or any rate limiting.

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

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

Three short sentences, zero filler, with the core action front-loaded and the operational notes (cost, error behavior) trailing. Every sentence carries information an agent can act on.

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

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

For a single-parameter read tool with no output schema, the description covers the action, the return contents, the cost, and the failure mode. There is no meaningful gap an agent would need filled before calling 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?

One parameter with 100% schema description coverage, so the schema already defines 'id' with concrete examples (sha256, token_count). The description only echoes 'by id' and adds no further semantics, which matches the baseline for fully documented 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 ('Fetch one public skill by id') and immediately narrows scope vs. the enumeration sibling list_skills by emphasizing a single skill. It also names what the payload contains (input schema, example request), so an agent knows exactly what it gets back.

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 'one ... by id' — the agent can infer this is the lookup-by-id path while list_skills handles enumeration — but the alternative tool is never named and no explicit when-to-use/when-not rule is given. No prerequisites or exclusions are stated.

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

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

With no annotations, the description carries real weight and delivers: it discloses paid access ($0.001 via x402) and that no network call occurs, which are non-obvious operational facts. It stops short of describing the response shape or error behavior for invalid/odd-length hex, so it isn't fully complete.

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

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

Two short, dense sentences with the core capability front-loaded and no padding. The phrase '4-byte selector note' is slightly awkward and the price clause reads as an afterthought, but overall it is efficiently structured.

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

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

For a 3-parameter tool with no output schema, the description never says what the return looks like, whether multiple 'as' targets produce a combined result, or how failures are signaled. The payment and locality details help, but an agent still has gaps before calling.

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

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

Schema coverage is 67%, so the schema documents hex constraints and the request_id idempotency key on its own. The description echoes four of the six 'as' enum values but omits uint256 and bytes, and says nothing about request_id, so it adds only marginal meaning beyond the schema.

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

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

States a specific verb (decode) and resource (hex) plus the concrete output targets (utf-8, bytes32, address, selector). It doesn't explicitly differentiate itself from siblings like base64 or sha256, but the local-conversion framing is clear enough for selection.

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

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

'Local-only' and 'No network fetch (no 4byte.directory)' implicitly tell the agent this won't resolve arbitrary selectors externally, suggesting use when offline/local semantics matter. However there is no explicit 'use this when' guidance or named alternative tool, so usage remains 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?

Without annotations, the description carries the full transparency burden. It discloses useful behavior such as stripping scripts/styles, NFKC normalization, zero-width/bidi character removal, and pricing via x402, but omits input length limits, error behavior, and whether partial output is returned.

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 three tightly written sentences with no waste. Purpose, normalization behavior, and pricing are front-loaded in a logical order.

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

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

For a simple two-parameter tool with no output schema and no annotations, the description covers the core purpose and some behavior. However, it leaves notable gaps around mode values, input limits, and output shape that an agent must infer.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the mode parameter by describing text-mode normalization and implies markdown mode, but it does not name the allowed mode values or document the html parameter's 400,000 character limit.

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: stripping scripts/styles from HTML and returning readable text or markdown. It does not explicitly differentiate itself from the sibling tool url_to_markdown, but the purpose is otherwise clear.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The implied use case is cleaning raw HTML strings, but the description never names or rules out alternatives such as url_to_markdown.

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

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

With no annotations, the description carries the full burden and does well: it discloses billing behavior ($0.0033 via x402), that private ranges are refused before payment, and that no charge applies if registries fail — non-obvious, agent-relevant economics. It omits latency, rate limits, or error-surface detail, keeping it short of a 5.

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

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

Front-loaded with the purpose and output inventory, followed by short sentences on refusal, failure credits, and price. Dense but largely waste-free; the parenthetical license attribution is a slight detour but is required for the data source.

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

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

For a 3-parameter read-only lookup with no output schema and no annotations, the description covers inputs, outputs (network, size, membership, holder, ASN, country), failure behavior, and cost. Only the shape/format of returned fields is left implicit, which is acceptable given no output schema exists.

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

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

Schema description coverage is 100%, so all three parameters (query, check, request_id) are fully documented in the schema. The description adds only indirect hints ('One ... IP or CIDR in', 'membership checks') and nothing about the request_id idempotency semantics, so it does not meaningfully exceed 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 — takes one public IP or CIDR and returns a normalized network, size, membership results, holder, abuse contact, origin ASN, and country. It enumerates the concrete outputs and names the underlying sources (RIR RDAP, RIPEstat, DB-IP Lite), so an agent can distinguish it from every sibling (url_normalize, email_check, phone_normalize all operate on other input types).

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 constraint 'One public IP or CIDR in' and 'Private ranges refused before payment' clearly delimit valid input and state a when-not condition. It doesn't name alternative tools to use instead (e.g., for OSINT graph work), so it stops short of explicit routing, but the applicability context is clear.

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

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

With no annotations, the description carries the full burden, and it does disclose real traits: deterministic output, array handling, configurable separators, depth limits, and a per-call price ($0.006 via x402) that implies a paid/auth flow. It stops short of explaining what happens when max_depth is hit or how separator collisions are handled.

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

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

Three telegraphic fragments, purpose front-loaded, nothing wasted. The clipped style costs a little readability 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?

No output schema exists, so the description should ideally sketch the return shape and failure modes; 'path-value map' is implied but not detailed, and the undocumented `data` parameter plus depth-overflow behavior leave gaps for a tool that has to be invoked correctly.

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

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

Schema coverage is 50% — the nested options block documents sep and max_depth, but the required `data` parameter is bare. The description's mentions of arrays, separators, and depth limits map onto what the schema already says, adding little new 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 transformation (nested JSON → flat path-value map) with the determinism guarantee named explicitly. It is clearly distinguishable from json_repair/json_sort by what it produces, though it never names a sibling directly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when another sibling (e.g. json_sort or json_schema_validate) would be the better pick. The only 'context' offered is pricing, which does not help tool selection.

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

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

No annotations are provided, so the description carries the burden and does so largely well: it discloses the return shape (parsed JSON, compact repaired string, list of fixes), states determinism, and confirms no network access. It omits any mention of failure behavior or limits (e.g. what happens if repair is impossible, the 400k length cap).

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 dense but well-structured single paragraph; the enumeration of supported fixes and the return-spec are front-loaded and useful. Slightly crowded, and the pricing tail is arguably noise for invocation, but nothing is padded or 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?

For a single-input tool with no output schema and no annotations, the description should fully specify the input contract and edge behavior. It covers returns and capabilities well but leaves the input parameter and failure modes unspecified, and ships no output schema to compensate.

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 0% and there is one parameter, 'text', whose meaning is somewhat inferable from the description but never explicitly defined (e.g. that it is the raw malformed string). With only one param the baseline is around 3-4, but the description adds no format or example guidance.

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 (Repair) and resource (malformed/truncated JSON) and enumerates the concrete failure classes it handles, distinguishing it clearly from siblings like json_flatten, json_sort, and json_schema_validate.

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

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

Gives clear context (input from LLMs, JS or Python) that implies when the tool is applicable, but never explicitly excludes or contrasts against sibling tools such as json_schema_validate, which also touches malformed JSON.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the pricing model and payment mechanism ($0.006 via x402), which is real behavioral context an agent needs before invoking. However, it says nothing about the response shape (pass/fail, error listing) or that it is a pure, side-effect-free check, leaving meaningful gaps for a no-annotation, no-output-schema tool.

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

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

Two compact sentences, front-loaded with capability and followed by pricing. No filler. Minor deduction for the jargon 'schema gate', which costs a beat of interpretation.

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

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

With no annotations and no output schema, the description must cover both safety profile and return semantics, and it only covers scope plus pricing. For a two-required-parameter tool at 0% schema coverage, an agent still lacks the input formats and the success/failure response shape.

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

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

Schema description coverage is 0% and the description never explains the two parameters ('instance', 'schema'). Parameter names are suggestive but ambiguous about whether inputs are JSON objects, strings, or references. The enumerated keyword list indirectly signals supported schema dialect, which is the only parameter-adjacent value added.

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

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

The description names the resource (a JSON instance validated against a schema) and enumerates the exact capabilities: type, required, properties, array items, and named format checks. The verb is implied rather than stated ('gate' instead of 'validate'), but an agent can still distinguish this from json_repair, json_flatten, or json_sort 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?

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives. A sibling like json_repair or json_sort is adjacent enough that an agent could plausibly pick the wrong tool; the description does nothing to disambiguate. Only the implicit 'validation' framing hints at usage.

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

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

With no annotations, the description carries the full burden, and it does disclose useful traits: determinism, no network access, and a $0.003 x402 payment requirement. However, it omits error behavior, handling of non-object inputs, and whether array element order is preserved.

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

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

Three tight sentences, front-loaded with the core behavior, and the cost/no-network caveats are relevant for a paid x402 tool. 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?

No output schema, no annotations, and 0% parameter documentation leave gaps, but the tool is simple (2 params) and the return format ('canonical compact JSON') is stated. Adequate but not complete for correct invocation of 'reverse' or 'data'.

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 0%: 'data' is untyped with an empty schema and 'reverse' has no description. The description implies data is an object but never states accepted input formats (object vs. JSON string) or what 'reverse' changes (descending keys? reversed output?). With low coverage, the description fails to compensate.

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

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

The description gives a precise verb and resource: 'Recursively sort object keys and return canonical compact JSON.' This is intrinsically distinct from siblings like json_flatten, json_repair, and json_schema_validate, though no sibling is named explicitly.

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

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

There is no guidance on when to choose this tool over alternatives such as json_flatten or json_repair, nor any prerequisites or exclusions. The agent must infer usage from the verb alone.

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

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

With no annotations, the description carries the full burden: it does disclose stopword filtering, deterministic scoring, ngram expansion behavior, and the $0.008 x402 cost, which is genuinely useful context. It omits return format, error/truncation behavior for the 200k-char input cap, and what x402 payment actually requires of the caller.

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

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

Three short sentences, front-loaded with the core operation, then the ngram qualifier, then cost. No wasted text, though the telegraphic fragments read more like spec bullets than instructions.

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

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

No output schema and no annotations, so the description should ideally describe the returned structure (terms with scores) and payment mechanics. It hints at scores via 'scored multi-word phrases' and does cover cost, but an agent still can't predict the response shape or the x402 flow.

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

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

Schema description coverage is 0%, so all three parameters are undocumented in structured data. The description partially rescues 'ngrams' ('2-3 adds scored multi-word phrases') but its stated range conflicts with the schema's 1-3, and neither 'text' (200k max) nor 'limit' is explained anywhere.

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 operation ('deterministic term ranking from free text') that maps unambiguously to keyword extraction, and names its defining traits (stopword-filtered, deterministic). Siblings are unrelated single-purpose utilities, so no differentiation is needed, but the description never uses the tool's own verb 'extract' to anchor intent.

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

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

No when-to-use guidance, no exclusions, no mention of alternatives. 'Deterministic' faintly implies this is the non-LLM option, but nothing tells an agent when to pick this over, say, seo or token_count.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds non-annotation context — 'Free' (no cost/quota) and the exact shape of what is returned — which is genuine added value, though nothing is said about catalog size or pagination.

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

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

Two compact sentences, front-loaded with the action and resource, with the field list and the 'Free and read-only' qualifier following. No filler.

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

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

With no input parameters and no output schema, the description carries the return-shape burden itself by naming every field, and annotations cover the safety semantics. Nothing needed to invoke this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description lists returned fields rather than parameters, which is appropriate and adds no confusion about inputs.

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

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

States a specific verb and resource ('List the public skill catalog') and enumerates the fields returned, so the agent knows exactly what comes back. It does not explicitly differentiate from the sibling get_skill, but 'catalog' vs. a single-skill getter is reasonably inferable.

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

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

The phrase 'public skill catalog' implies discovery/browsing usage, and 'Free and read-only' signals it is a safe lookup, but there is no explicit when-to-use guidance or reference to get_skill as the alternative for fetching one skill's details.

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

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

With no annotations, the description carries the full burden and does notably well: it discloses the data source, a freshness timestamp, time-of-day pricing behavior, and two failure cases where no charge applies. The $0.0034 x402 billing note is valuable operational context. It does not describe the response shape or ranking/pagination behavior, keeping it short of a 5.

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

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

Dense and front-loaded: the input-to-output transformation leads, followed by source, pricing behavior, and billing terms. Zero filler sentences. It is telegraphic to the point of being slightly cryptic, but 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?

For a 7-parameter tool with no annotations, no output schema, and near-zero schema coverage, the behavioral side is well covered but the parameter side is not, and the relationship to the token_price sibling is unaddressed. Adequate but with clear gaps an agent must resolve by inspection.

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

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

Schema description coverage is only 14% (just request_id), so the description must compensate and largely does not. 'Text or token counts in' loosely gestures at text/input_tokens/output_tokens, but top, models, and include_free are left entirely undocumented in both schema and description.

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: text/token input converted to per-model cost, cheapest first, sourced from OpenRouter. This is concrete and distinguishable from counting tools like token_count. However it never names or differentiates itself from the closely related token_price sibling, which an agent must disambiguate against.

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 description's input/output framing (you supply text or token counts to get costs), but there is no explicit when-to-use statement, no when-not-to-use, and no routing guidance versus token_price or token_count. The agent must infer the boundary itself.

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

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

With no annotations, the description carries the burden and does disclose key traits: it is a paid call ($0.003 via x402), supports forward/reverse resolution, and returns address, name, source, forward_verified, and optional avatar. It still omits error/empty-result behavior, rate limits, and payment mechanics beyond the price.

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

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

Two tightly written sentences, front-loaded with the core operation and followed by return fields and price. Every clause adds useful information with no repetition.

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

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

No output schema exists, so the description helpfully lists return fields. It also covers payment and supported networks, making it mostly complete for a three-parameter resolver, though it leaves gaps around auto-direction behavior and failure cases.

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

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

Schema coverage is 67%; the schema already documents query and request_id. The description adds that input can be an ENS/Basename or address and that direction can be forward or reverse, but it does not explain the default 'auto' behavior or add detail to the idempotency parameter 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 precise verb (Resolve) and specific resources (ENS .eth on Ethereum, Basenames .base.eth on Base) plus supported directions. It also enumerates result fields, making the operation immediately distinguishable from generic lookup or validation siblings like address_validate.

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

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

Usage is implied by the description: use this to resolve names/addresses forward or reverse. However, it does not explicitly say when to prefer it over siblings such as address_validate, nor does it state exclusions or prerequisites beyond the price.

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

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

With no annotations, the description carries the full burden and delivers unusually useful behavior: deduplication semantics, both data sources, the no-article-text limit, billing behavior ('Not charged when nothing matches or sources fail'), and price ($0.0101 via x402). It omits rate limits and payment/auth mechanics beyond the x402 mention, keeping it out of 5 territory.

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

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

Three tight sentences, front-loaded with the input/output contract, then constraints, then billing. Every clause carries distinct information with no filler.

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

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

No output schema exists, and the description correctly describes the return shape (headline, URLs, first-seen time) and cost model. It leaves timespan and max_clusters semantics unexplained, which a paid, tunable tool would ideally cover, but the core contract is complete.

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

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

Schema description coverage is only 25% (only request_id is documented), so the description must compensate but does not: timespan's 24h/3d/7d enum and max_clusters (1-20, default 10) are never mentioned. Only 'Topic in' maps to a parameter, adding nothing the schema does not already state.

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

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

States a precise input/output contract: 'Topic in, deduplicated story clusters out: headline, every outlet URL and first-seen time.' It names the sources (GDELT and publisher RSS) and the output shape, so an agent knows exactly what this produces. No sibling tool covers news aggregation, so there is no ambiguity to resolve.

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

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

Gives a clear negative constraint that routes behavior ('Headlines and links only, no article text'), implicitly telling the agent to use something like url_to_markdown if full text is needed. It does not name an explicit alternative or state when-not-to-use beyond that, 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?

With no annotations, the description carries full burden and does disclose meaningful behavior: the graph is bounded to a fixed property list, depth is capped at two hops, only notable public roles are included for people, and the failure mode returns an empty graph plus a reason. It also surfaces the $0.01 x402 cost, which is important for a paid tool; missing are auth/payment mechanics and rate limits.

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

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

Front-loaded with the core action and output, followed by the two behavioral constraints an agent most needs (notability restriction, empty-graph behavior) and a trailing cost note. No filler sentences; the parenthetical property list is dense but informative.

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

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

No output schema exists, and the description adequately covers return shape (graph, or empty graph with a reason) and the paid-access model. The main gap is input semantics for the two parameters, particularly what max_depth changes, given the description fixes the default at two hops without addressing the adjustable range.

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

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

Schema description coverage is 0%, so the description must compensate. It hints at 'seed_entity' by saying 'one public name' and gestures at depth with 'up to two hops', but 'max_depth' is never named or explained (its schema allows 1-4), and there is no guidance on whether the seed should be a plain name or a QID, nor on the 500-character limit.

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

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

States a concrete verb ('Resolves'), a specific resource ('one public name on Wikidata'), and the returned artifact ('a relationship graph'). The scope of the graph is spelled out via the fixed property list skeleton, so an agent knows exactly what kind of output to expect.

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

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

Usage is implied rather than stated: it's for looking up a single public entity, and the description notes the empty-graph case with a reason. There is no explicit when-to-use/when-not guidance or named alternative, which is acceptable here since no sibling tool overlaps, but it falls short of a 4.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses determinism, no network access (a real privacy-relevant trait), typed placeholder output, and the x402 price of $0.003. It stops short of describing the return shape, reversibility of placeholders, or behavior on oversized input, so it is strong but not exhaustive.

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

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

Two dense sentences, front-loaded with the operation and its scope, followed by behavioral and pricing facts. No filler, no repetition of the tool name.

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 text utility with no output schema, the description covers what gets redacted, how (typed placeholders), key behavioral guarantees, and cost. The main gap is not clarifying the returned artifact or the oversized-input boundary.

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 0% and the single required 'text' parameter is never mentioned in the description; the schema only supplies length bounds. The parameter is trivially inferable from the tool's purpose, but the description adds no syntax, format, or size guidance beyond what the schema already states.

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

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

Specific verb ('Redact') plus an explicit enumeration of the target entities (emails, phone numbers, SSN-shaped strings, Luhn-valid cards, IPv4), which distinguishes it cleanly from every sibling utility (sha256, base64, keyword_extract). An agent knows exactly what the tool does 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?

Usage is implied by the enumerated PII categories, so an agent can infer when it is relevant, but there is no explicit when-to-use/when-not guidance and no mention of alternatives (e.g., token_risk or ai_detector, which touch adjacent concerns). Adequate but leaves routing to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the 7 s timeout cap, the specific failure classes (403/404/5xx, CDN/WAF challenge, timeout), the 422 response with score null and a reason, the charged:false guarantee that no payment is taken, and the $0.012 x402 price. These are exactly the billing and failure semantics an agent needs before invoking a paid tool.

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

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

Three dense sentences plus a price clause, front-loaded with what the tool does and followed by failure and cost behavior. Every sentence adds information and nothing is 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 two-parameter tool with no output schema and no annotations, the description covers purpose, failure modes, and payment well, and it does describe the returned score including the null-on-error case. The remaining gap is parameter meaning, which is left entirely to the bare 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 0%, so the description must compensate, but it never explains the two parameters. The 'keywords' parameter is only glancingly alluded to via the list of checks and it is unclear whether it supplies target keywords or merely reports extracted ones, and the url constraints (maxLength 2000) go unmentioned.

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: 'Fetches a URL and returns an on-page SEO score,' and enumerates the checks (title, meta, headings, alt text, keywords), which separates it from siblings like url_to_markdown, html_clean, and keyword_extract. It does not explicitly name an alternative, so it falls just short of a 5.

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

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

Usage is only implied: run it against a URL to get an SEO score. There is no statement of when to prefer this over keyword_extract or url_to_markdown, and no when-not guidance beyond the failure cases, which describe error handling rather than tool selection.

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

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

With no annotations, the description carries the behavioral burden well by disclosing pricing ($0.0503 via x402), a billing exception for blocked/unreachable pages (422, charged:false), and the maximum of 3 competitor pages. It still omits details such as auth/payment flow and what the per-check gap table contains.

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

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

Two tightly packed sentences, front-loaded with the core action and output. The billing condition and price are relevant and earn their place.

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

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

The description covers purpose, output shape, price, and non-charge behavior, which is good for a paid comparison tool. However, because the input schema is entirely permissive, the agent still lacks field names/format for the page and competitor URLs, and there is no explanation of the x402 payment mechanism.

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

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

The schema is a permissive object with no constrained fields, so the description adds meaningful semantics: the caller supplies 'your page' and up to 3 competitor pages. It does not name the actual JSON fields to send, but with zero formal parameters the baseline is 4.

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: 'Runs SEO Optimizer v2 on your page and up to 3 competitor pages.' The comparison/gap-table focus distinguishes it from the plain seo and seo_v2 siblings, though it does not explicitly name those alternatives.

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

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

Usage is implied by the comparative setup — use this when you want a gap analysis against competitor pages. However, there is no explicit guidance on when to use this versus seo or seo_v2, nor any when-not conditions.

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

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

With no annotations, the description carries the full burden and discloses key behavioral traits: price ($0.0497 via x402), charging only on success (422 returns charged:false), and a caveat that scores reflect technical checks only with no guarantee of ranking or citation. It does not fully detail the response shape or any rate limits, but the essential cost and safety profile is clear.

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 dense but front-loaded, leading with the core audit and output artifacts before pricing and caveats. Every sentence contributes useful information, though it could be trimmed slightly without losing meaning.

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 no output schema and no annotations, the description lists the generated artifacts (title/meta, canonical, Open Graph/Twitter, JSON-LD skeleton) and clarifies the scoring scope (technical checks only). It doesn't fully describe the response structure (e.g., severity fields, score breakdown), but it is reasonably complete for a complex audit 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?

The schema is a permissive object with zero defined parameters, so parameter semantics are not a concern. The description appropriately focuses on outputs and behavior rather than parameters, meeting the baseline for a no-parameter tool.

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

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

The description states a specific verb+resource ('On-page SEO + AEO audit') and enumerates what it returns (0-100 score, ~25 checks, generated title/meta, JSON-LD skeleton). It clearly distinguishes itself from a plain SEO audit by including AEO (AI-answer readiness), but it never names or contrasts with siblings like 'seo' or 'seo_compare', leaving some ambiguity about when this version is preferred.

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 alternatives such as 'seo', 'seo_compare', or 'agent_ready_audit'. The only usage-adjacent context is the note that no charge occurs if the site blocks us or is unreachable, which is behavioral rather than routing guidance.

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

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

No annotations, so description carries full burden. It discloses determinism, no network, and pricing (x402 $0.003), which are useful behavioral traits. However, it omits critical details: encoding behavior, output format specifics, max input size (400k chars in schema), and error conditions.

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?

Extremely concise: one sentence covering hashing, algorithms, return format, determinism, network, and price. Front-loaded with core action and zero waste.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It omits encoding semantics, input size limits, and detailed parameter meanings, leaving the agent to guess about non-default encoding and large inputs.

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 0%, so description must compensate. It mentions 'algo' values (sha512, sha3_256, blake2b_256) but not the default 'sha256' explicitly (though implied by tool name and 'by default'). It does not explain 'text' beyond 'string', nor 'encoding' at all, leaving two parameters undocumented.

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?

Clear verb+resource: 'Hash a string' with specific algorithms named, and maps to the sha256 tool name. No sibling does hashing, so differentiation is implicit by name; the description could be slightly more explicit about being the only hash 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?

Implies usage for hashing arbitrary strings, but doesn't state when to choose this tool over alternatives (none exist) or constraints like input size limits, which are in the schema. No exclusions or alternatives are given.

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

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

No annotations are provided, so the description carries the full burden. It does usefully disclose determinism, no network access, and the x402 price ($0.003), which tells the agent this is a paid, side-effect-free, idempotent transform. However it omits what happens on empty input, unicode/non-ASCII handling, and how truncation via max_len behaves, which matters for a text transform with a 4000-char bound.

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

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

Three short, front-loaded sentences with no filler; the core action leads, followed by the behavioral guarantees and the pricing note. Every sentence carries distinct information.

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

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

For a small deterministic utility with no output schema and no annotations, the description covers purpose, determinism, network posture, and billing — the output format is described inline (lowercase, URL-safe slug). The only real gap is that parameter behavior (notably max_len) is absent, though that is already penalized separately.

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

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

Schema description coverage is 0% and the description never mentions either parameter. It says nothing about `text` or about `max_len` (default 80, max 200) — critically, whether exceeding max_len truncates, errors, or word-boundary-splits is left entirely unexplained, so the description fails to compensate for the empty schema documentation.

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?

"Turn free text into a URL-safe lowercase slug" is a precise verb+resource+output format statement. It is unambiguously distinguishable from every sibling (base64, sha256, uuid_mint, keyword_extract) without consulting any schema.

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

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

The usage context is implied by the narrow purpose rather than stated: an agent can infer this is the tool for slug generation, but there is no explicit when-to-use framing, no mention of when a sibling (e.g. keyword_extract or html_clean) should be preferred, and no input preconditions.

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

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

With no annotations, the description carries the full burden. It usefully discloses determinism and the x402 payment requirement ($0.006), which is real behavioral context, but it omits the 200k-char input cap, offline/read-only nature, and any rate or failure behavior.

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

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

Three short, front-loaded sentences covering capability, output, and price with zero filler. Each sentence earns its place.

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

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

The description partially covers returns ('structured ops plus a one-line delta summary') with no output schema, but given 0% schema coverage and an opaque 'options' object, it leaves the mode-selection mechanism and size limits unexplained.

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

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

Schema description coverage is 0% and the mode (line/word/char) is mentioned without mapping to any parameter. The 'options' object is documented nowhere in schema or description, so the agent cannot know how to select diff granularity. 'a' and 'b' are self-evident only from the schema itself.

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 (diff) plus the three granularities (line/word/char) and output shape, so the agent knows exactly what it does. No sibling tool performs diffing, so explicit differentiation isn't needed, but it never names an alternative either.

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

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

There is no when-to-use guidance: nothing says when a line diff is preferable to a word or char diff, nor how to trigger each mode. The agent must infer mode selection from the 'options' black box with no help.

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

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

With no annotations, the description carries the full burden and does disclose two valuable traits: results are approximate (not exact tokenizer output) and the call costs $0.004 via x402, which signals a paid/auth-gated operation. It still omits the return shape (single count vs per-encoding breakdown) and any limits, so it is only moderate coverage.

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

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

Two short sentences with the core purpose front-loaded and the pricing caveat appended. Nothing is redundant, though the pricing detail is a secondary fact that could have followed the purpose clause more tightly.

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

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

For a simple two-param utility with no output schema, the description covers the essentials of what it does and what it costs. It is thin on the return value and on the input size limit, which an agent sizing a request would want to know.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented params. It does clarify the supported encodings (cl100k/o200k), matching the encoding param's default, but says nothing about the required text param or its 400,000-character cap.

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

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

Names a specific verb (count) and resource (tokens) and pins the encodings to cl100k/o200k, which is more precise than the bare tool name. It is distinguishable from most siblings, though it does not explicitly contrast with the related token_risk 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?

"For budget decisions" gives an implied use case, so an agent can infer this is a pre-flight cost/context estimate. However, there is no explicit when-to-use vs when-not guidance and no pointer to the sibling token_risk, which likely covers a related concern.

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

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

With no annotations, the description carries the full burden and does well: it discloses the dual-source methodology, the return fields (price, spread, staleness, confidence), the failure mode ('Refused, not charged, if sources disagree over 2.5% or one is missing'), and the cost ($0.002 via x402). It omits auth/rate-limit details, so not a 5.

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

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

Dense and front-loaded: the core deliverable leads, followed by methodology, return fields, refusal policy, disclaimer, and price. Every clause carries distinct information with no filler.

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

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

Despite no output schema, the description enumerates the return fields and the failure/refund behavior, plus cost and a disclaimer, giving an agent everything needed to call and interpret the tool correctly.

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

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

Schema description coverage is 67%, with token and request_id already documented in the schema and chain defaulting to 'base'. The description adds no parameter-level syntax or format detail, so the schema does the heavy lifting and a 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 resource and scope ('Verified USD price for a Base ERC-20') plus the methodology, making the tool's job unambiguous. It is clearly distinguishable from the sibling token_risk, which covers a different concern.

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

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

Usage is implied by the resource (fetch a verified token price) and the refusal condition is spelled out, but there is no explicit when-to-use vs alternative guidance and no mention of token_risk or other siblings. Adequate but with a clear routing gap.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the read-only public RPC nature, heuristic (not definitive) methodology, simulated sell/buy transfers with tax measurement, a financial-advice disclaimer, and a $0.005 x402 cost. It omits rate limits, failure modes, and payment/auth flow details, so it is strong but not exhaustive.

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

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

The definition is front-loaded with purpose, then a dense list of checks, then concise behavioral notes. Every phrase—checks, read-only RPC, disclaimer, price—earns its place, with no redundant or filler text.

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

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

No annotations, no output schema, and 0% schema description coverage mean the description must carry full context. It thoroughly explains what the tool checks and how it operates, but omits parameter semantics and any indication of return shape, leaving meaningful gaps for a complex paid risk tool.

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

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

Schema description coverage is 0% for two parameters. The description contextualizes the token as a 'Base ERC-20,' but never names or explains the token or chain parameters, their formats, or the chain default. It adds minimal meaning beyond the schema's enum and 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?

The description states a specific verb ('Heuristic risk checks') and resource ('Base ERC-20'), and enumerates the exact checks performed (contract code, metadata, proxy, selectors, pool, simulated transfers). It is immediately distinguishable from all sibling utility tools, none of which perform token risk analysis.

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

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

Usage is implied by the purpose—evaluate risk for a Base ERC-20—but the description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The sibling list contains no comparable risk tools, so routing ambiguity is low, but the definition still leaves invocation criteria to inference.

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

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

With no annotations, the description carries the burden and discloses meaningful traits: short caching, a $0.002 x402 payment model, and pre-payment hash validation. It still omits failure behavior (e.g., pending or unknown tx) and rate-limit details, which keeps it short of a 5.

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

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

Two compact sentences, front-loaded with the resource and scope, followed by behavioral/payment notes. Every clause adds practical information with no repetition.

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

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

No output schema exists, yet the description names the returned fields (status, block, confirmations) and explains cost and caching. For a simple RPC wrapper it is nearly complete, though pending/not-found handling remains unspecified.

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

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

Schema coverage is 67%, with tx_hash and request_id already documented in the schema and chain self-documented via enum. The description confirms chain scope (Base or Ethereum) and hash validation but adds no semantics for request_id idempotency or chain defaulting beyond what the schema provides.

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

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

States a specific resource (transaction receipt status, block, confirmations), the two supported chains, and the exact RPC method (eth_getTransactionReceipt). An agent can immediately distinguish it from siblings like block_number, gas_price, or token_price.

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 RPC method and the required tx_hash: call it when you have a transaction hash and need receipt data. However, there is no explicit when-not-to-use guidance, no mention of alternatives for pending transactions, and no stated prerequisites beyond hash format.

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

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

With no annotations, the description carries the full burden. It usefully discloses the payment model ('Price $0.005 via x402'), which an agent needs to know before invoking, and it discloses that the tool mutates URLs (HTTPS forcing, param stripping). It says nothing about error behavior, idempotency, or how invalid/unreachable URLs are handled.

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

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

One front-loaded sentence with a colon-delimited operation list and the pricing note appended. Nothing redundant; every clause conveys actionable information.

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

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

No output schema exists, and 'extract components' hints at the return shape without specifying it. Combined with an entirely opaque options object and no error semantics, the description leaves meaningful gaps for a 2-parameter tool, though the transformation list does reduce ambiguity about what the call does.

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 0% and neither parameter is documented anywhere. The 'options' parameter is a free-form object with additionalProperties and no described keys, so the agent cannot know how to toggle or configure the listed transformations, which is the main thing it would need to know.

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 ('Canonicalize') and resource ('URLs') plus the concrete transformations applied (strip tracking params, force HTTPS, sort query, extract components). It is clearly separable from siblings like url_to_markdown, though it never names an alternative explicitly.

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

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

Usage is only implied by the operation list; there is no statement of when to reach for this tool versus url_to_markdown or the other normalizers. No prerequisites, no exclusions, no input constraints are given.

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

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

With no annotations provided, the description carries the full burden and does so well: robots.txt compliance, SSRF guarding, HTML-only restriction, 1 MB / 5 s caps, no JS rendering, and the $0.003 x402 price are all disclosed. These are exactly the operational traits (safety, limits, cost) an agent cannot infer from the schema.

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

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

Two dense sentences, front-loaded with the primary action and output, followed by constraints and cost. Every clause carries new information; nothing is padded or repeated from the schema.

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

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

With no output schema, the description still names the return values (title plus Markdown with headings, links, lists, code, tables) and covers limits, eligibility, and pricing. Nothing material is missing for an agent to decide and invoke correctly.

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

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

Schema description coverage is 0% and there is one parameter. The description adds the meaningful 'public' constraint (no authenticated/private URLs), but says nothing about URL formatting or the 2000-char limit, which the schema pattern only partially conveys. Partial compensation for a low-coverage schema warrants a middle score.

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

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

States a precise verb+resource pair ('Fetch one public web page and return its title and clean Markdown') and names the rendered output formats. The word 'Fetch' combined with 'one public web page' distinguishes it from the pure-text-processing siblings (html_clean, keyword_extract) that operate on supplied content rather than retrieving URLs.

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 scope and implicit exclusions: 'public' page, 'HTML only', 'No JavaScript rendering' tell the agent when this tool will fail. It does not, however, name or route to an alternative when those conditions do not hold, so it stops short of explicit when-not/alternative guidance.

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

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

With no annotations, the description carries the full burden and delivers meaningful behavior: the 1-32 batch bound, the default format/version, and critically a price ($0.003 via x402), which signals a payment requirement the agent would otherwise not know. It omits rate limits, whether generated IDs are persisted, and any idempotency guarantee.

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

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

Three compact sentences, front-loaded with purpose and variants, then the ordering behavior, then cost. No filler and nothing redundant with the schema.

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

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

Covers formats, ordering semantics, and pricing well, but with no output schema and no annotations the description should also state the return shape (e.g. an array of ID strings) and clarify the format/version interaction. Those gaps leave the agent inferring part of the contract for a 3-parameter 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 0%, so the description must compensate, and it largely does: it explains that v7/v1 are time-ordered, that ULID is selected via 'format: ulid', and restates the 1-32 count bound. The interaction between 'format' and 'version' (e.g. whether version is ignored for ULID) is left unresolved.

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 (mint) and resource (IDs), scopes the batch (1-32), and names the exact output variants (UUID v4/v7/v1, ULID). An agent can tell immediately this is an ID generator, distinct from hash/encode siblings like sha256 or base64.

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

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

Names concrete use cases ('agent job IDs and idempotency keys') and flags that v7/ULID batches sort in mint order, which implicitly tells the agent when to prefer time-ordered variants. It stops short of explicit when-not guidance or a direct v4-vs-v7 decision rule.

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

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

With no annotations, the description carries the burden well: it discloses rate limiting, a ~5s timeout, SSRF safety (no private redirects), input rejection rules, and even cost ($0.003 via x402). It stops short of describing failure/error behavior or response shape beyond the field list, which keeps it from a 5.

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

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

A single dense paragraph with the core purpose front-loaded and every clause carrying information (scope, exclusions, rate limit, timeout, safety, price). No filler or restated title.

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

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

For a two-parameter read-only lookup with no output schema, the description covers scope, exclusions, limits, safety, and cost, and enumerates returned fields. Only error/failure semantics are unaddressed.

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

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

Schema coverage is 100%, so both the domain and request_id parameters are already documented in the schema, including the idempotency semantics. The description adds only the IP-literal rejection constraint on domain, so baseline 3 is appropriate.

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

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

States a specific verb+resource ("Domain registration lookup via IANA RDAP DNS bootstrap only") and enumerates the data returned (registrar, status, nameservers, events). It doesn't name siblings like dns_lookup or name_resolve explicitly, but "registration" vs "DNS lookup" makes the distinction inferable.

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 defines negative scope clearly ("Rejects IP literals and private names", "RDAP bootstrap only"), which implicitly steers callers away from misuse. However, there is no explicit when-to-use-this-vs-alternative guidance for siblings such as dns_lookup or name_resolve.

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