Money Maker x402 tools: EVM reads + AI tasks

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

Goes well beyond the readOnly/idempotent annotations: discloses data sources (bytecode, storage slots, probe calls via free public RPCs), the full classification taxonomy, and the non-obvious billing behavior — $0.002 USDC via x402, with an unpaid call returning a PaymentRequired object that must be retried with params._meta['x402/payment']. That payment flow is critical operational context an agent cannot infer from annotations or schema.

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

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

Front-loaded with the purpose question, then structured as classification list → data sources → pricing/payment → HTTP endpoint. It is dense and semicolon-heavy, but nearly every clause carries real information; the HTTP endpoint line is the only borderline addition.

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 semantics — and it does, enumerating every classification, proxy standard, implementation/admin fields, owner(), nonce, balance, and code size. Combined with the payment retry mechanics, an agent has everything needed to call and interpret results correctly.

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

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

Schema coverage is 100%, so both parameters are already documented, including the chain default list. The description reinforces that results are per-chain ('on each chain') but adds no format or syntax detail for the chain parameter beyond the schema. Baseline 3 is appropriate.

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

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

Opens with the exact question the tool answers ('What is this address on each chain') and enumerates the concrete classifications it returns (EOA types, token standards, Safe multisig, proxy patterns). This is unmistakable and easily distinguished from siblings like token_info, wallet_snapshot, or tx_decode.

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

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

Frames clear usage context by stating the question it answers and the per-chain scope, which implies when an agent should reach for it (address classification/inspection). It does not explicitly name alternatives or exclusions (e.g., 'use token_info for token metadata instead'), so it falls short of a 5.

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

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

Annotations already mark it read-only and idempotent, and the description adds substantial non-obvious behavior: rate-limit failure yields a 502 and no charge, price is $0.003 USDC on Base per call via x402, unpaid calls return the x402 PaymentRequired object, and retry requires params._meta["x402/payment"]. It also discloses ranking (newest first), output cap (50), and the underlying free public-RPC log limit that causes the block 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?

Front-loaded with purpose, range, and exclusions before payment mechanics, and nearly every clause carries operational information. It is a single very dense paragraph though; splitting payment/x402 details from scan semantics would make it easier to parse on first read.

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

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

With no output schema, the description fully carries return-shape burden: direction, symbol, decimal amount, block time, newest-first ordering, and the 50-row cap. Combined with failure-mode and payment disclosure, an agent has everything needed to call and interpret this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: the chain-specific conversion of the blocks window to wall-clock time helps an agent choose a value, and it clarifies that the tokens parameter overrides the default major-token set. It doesn't add anything about the 8-value chain enum beyond the schema's "default base".

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

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

The description opens with a concrete verb and resource: "Recent token activity for an address on one chain: ERC-20 Transfer logs where it is sender or recipient," and narrows scope to major tokens or up to 10 user-supplied tokens. It never references the closely related sibling token_transfers, so an agent must infer the boundary between the two itself.

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 context is explicit: recent windows only, with per-chain hour equivalents (~5.5 h base/optimism/polygon, ~33 h ethereum), and clear exclusions ("Native-coin transfers and older history are not included"). However, it does not name an alternative tool for the excluded cases (e.g., tx_find or token_transfers), so the routing decision is left partly to inference.

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

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

The description adds substantial behavioral context beyond annotations: invalid output returns 422 without charge, exhausted daily capacity returns 503 without charge, no calibrated probabilities are provided, and calls are paid via x402 with a specific retry mechanism. This is exactly the operational detail an agent needs for a paid, external-model tool.

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

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

The description is dense but front-loaded: classification task, inputs, outputs, error behavior, model/runtime, capacity, pricing, and HTTP equivalent are all delivered without filler. Every clause earns its place for an agent that must decide whether and how to call the tool.

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

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

There is no output schema, but the description explains the return shape: one label or all applicable labels, always from the supplied list, plus a one-sentence reason. It also covers failure modes and payment flow, leaving no critical invocation detail missing.

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

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

Schema coverage is 75%, so the schema already documents text length and label count. The description compensates for the undocumented multi_label parameter by explaining that multi_label=true returns every applicable label, though it does not elaborate on the optional instructions parameter 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?

The description states a specific verb and resource: zero-shot classification of text into user-provided labels. It clearly distinguishes the operation from siblings like ai_extract and ai_embed by focusing on constrained label selection and explaining both single-label and multi-label behavior.

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

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

The description gives clear usage context: send text plus 2-50 labels, set multi_label=true to return every applicable label, and expect a one-sentence reason. It does not explicitly compare against alternatives such as ai_extract or explain when not to use classification, which keeps it below a 5.

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

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

Annotations only say read-only/open-world/not-idempotent, but the description adds rate limits (daily capacity, 503 when exhausted and not charged), pricing ($0.0005 USDC on Base per call), the full x402 payment handshake including the retry via params._meta["x402/payment"], and an equivalent HTTP endpoint. That is substantial operational context an agent cannot get from the annotations.

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

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

Front-loaded with the core action and its limits, then payment/logistics detail. It is a single dense paragraph with heavy parentheticals that slightly impede scanning, but nearly every clause carries 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?

Covers input limits, ranking semantics, cost, and failure modes for a 3-parameter tool with no output schema. The one remaining gap is the response shape — what the vectors/ranking payload looks like (vector dimensionality only appears in the title, and ranking field names are unstated).

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

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

Schema coverage is 67%, and the description compensates by explaining what query does semantically (ranks texts by cosine similarity) and what include_vectors=false means, a parameter the schema documents only as an enum. Batching bounds (1-32 texts, 4,000 chars) are also restated usefully.

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 (Embed) and resource (1-32 texts) plus the exact model (BAAI bge-m3), batching and length limits, and an alternate mode (rank by cosine similarity with query=). This clearly separates it from siblings like ai_classify, ai_extract, and ai_image without opening any schema.

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

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

Gives concrete usage context: add query= for a 'cheap semantic search / rerank step', and set include_vectors=false to get only the ranking. It does not name an alternative sibling or state explicit exclusions, so the routing guidance is clear but not exhaustive.

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

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

Goes well beyond the annotations by disclosing the 12,000-char input cap, one automatic repair attempt, the 422-no-charge failure path, daily capacity limits with 503-no-charge, pricing ($0.004 USDC on Base), and the x402 payment retry flow via params._meta['x402/payment']. It also names the backend (Cloudflare Worker, IBM Granite 4.0 micro), which the annotations do not cover.

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 task and output guarantee, then layers on repair, capacity, and pricing details. Dense but nearly every sentence carries operational information an agent needs (payment flow, failure codes); only the model/license parenthetical is arguably extraneous.

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

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

For a paid, schema-validated extraction tool with no output schema, the description covers the success shape (validated JSON), both failure modes (422, 503) with billing implications, capacity limits, and the exact payment retry mechanism. Nothing an agent needs to invoke and pay correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents text, schema, and instructions with their limits. The description only reinforces the 12,000-char text cap and the schema constraints, with one genuinely new detail ('as a JSON string in GET'); it adds little about the instructions parameter beyond what the schema says.

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: send text plus a JSON Schema and receive JSON validated against it, including the validation keywords checked. This clearly distinguishes it from siblings like ai_classify, ai_embed, and web_extract, which do not take a caller-supplied schema.

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

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

Explicitly rules out the wrong use case ('Not a chat or model-access API') and states the fixed-prompt constraint ('copy, don't invent'). It does not, however, route the agent to a specific sibling for related tasks (e.g., ai_classify for labeling or web_extract for fetching), so the when-to-use-vs-alternatives guidance is strong but not fully explicit.

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

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

Far exceeds what readOnlyHint/openWorldHint/idempotentHint convey: it discloses the two-stage content screen and what is refused, that refusals return 400 without charge, daily quota exhaustion returning 503 without charge, the exact price ($0.01 USDC on Base), the x402 payment handshake and retry mechanism, and that the generated image itself is not classified. This is unusually rich for a mutation-and-billing operation.

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

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

Front-loaded with the action, size, and model before style detection, screening, billing, and error codes. It is dense and long, but nearly every clause carries operational value (screening, quota, payment); only the trailing HTTP endpoint line feels like padding for an MCP caller.

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

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

With no output schema, the description still specifies the return payload (base64 JPEG plus final prompt and detected style), and covers failure modes (400 refusals, 503 quota) and the payment flow. An agent has everything needed to call it correctly and interpret both success and failure.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: what 'style' forces, that the medium is never switched, and that enhance=false uses the prompt verbatim. The 'steps' parameter is not explained beyond the schema's '1-8, default 6', leaving one small gap.

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

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

States a specific verb and resource (generate one 1024×1024 image from a short prompt) plus the exact model and hosting (FLUX.1 [schnell] on Cloudflare Workers AI). It is trivially separable from the other AI siblings (ai_classify, ai_embed, ai_extract, ai_transcribe) which operate on text/audio rather than producing images.

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 operating guidance: default behavior (auto-detect medium, photo if none), how to override (set style, or enhance=false), and the char limit. It does not explicitly contrast with sibling tools, but among this set there is no competing image-generation alternative, so context is effectively clear.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely non-structured context: there is a daily free cap, ai_* calls fail with 'capacity used up' before charging, and the data is scoped to today. It stops short of saying what the response 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?

One front-loaded sentence plus a parenthetical that earns its place by explaining the cap/failure behavior. 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 never indicates what the response looks like (a remaining count, a reset time, or a boolean). For a status tool that is the one meaningful gap; everything else an agent needs is present.

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

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

Zero parameters, so there is nothing to disambiguate; baseline applies. The description correctly implies no input is needed.

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

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

Names a specific resource and scope: today's remaining free Workers AI capacity for the ai_* tools. It clearly differs from the ai_classify/ai_embed/etc. siblings, which consume the capacity rather than report it. Slightly indirect in phrasing but an agent can tell what it 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?

Explains the surrounding condition — the ai_* tools answer 'capacity used up' before any payment when the daily cap is reached — which effectively tells the agent to consult this before invoking ai_* tools. No explicit 'call this before X' phrasing or exclusions, so short of a 5.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses voice-activity filtering, that audio is not stored, the exact price and chain, the x402 payment handshake, and that a 503 on capacity exhaustion is not charged. These are the non-obvious behaviors an agent needs before spending money.

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 operation and its hard limits, then payment and capacity details. It is dense and mostly earns its length, though the trailing 'Same tool over HTTP' note is peripheral to an MCP caller.

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

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

With no output schema, the description still specifies the return fields (text, language, duration, optional segments + WebVTT) and covers cost, failure modes, and the payment retry loop, which is everything needed to invoke it correctly.

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

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

Schema coverage is 75% and already documents language, audio_url, and audio_base64. The description mainly restates the two audio inputs and hints that 'segments' toggles segment + WebVTT output, but does not explain the segments enum (string 'true'/'false') or any mutual exclusivity between audio_url and audio_base64.

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 ('Transcribe one audio file'), the exact model (Whisper large-v3-turbo), the accepted formats, and the one-megabyte limit, so it is clearly separable from ai_image, ai_classify, and other siblings in the ai_* family.

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?

Constraints on when it is applicable are explicit: file formats, 1 MB cap, public https URL or base64 input, and the retry path via params._meta["x402/payment"] when an unpaid call returns PaymentRequired. It stops short of naming a sibling alternative (e.g., HTTP endpoint or another transcription option), so it is context-rich but not fully comparative.

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

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

Goes far beyond the readOnly/idempotent/openWorld annotations: discloses the search strategy and cost ('batched k-ary search ... about 7 round trips'), a real limitation ('very old history may be unavailable on public nodes'), and the full x402 payment flow including the PaymentRequired retry via params._meta['x402/payment']. This is exactly the operational context an agent needs before invoking.

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

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

Front-loaded with the core semantics and purpose before pricing/transport detail. It is dense but nearly every clause carries needed information; the chain enumeration duplicates the enum and is the one mildly wasteful element.

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 describes the return ('with its timestamp and the next block's'), plus coverage limits and payment mechanics. Nothing an agent needs to call and interpret this correctly is missing.

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

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

Schema coverage is 50% with only two params; the description restates the time formats and chain list (overlapping the schema/enum) but also surfaces the implicit _meta['x402/payment'] parameter that is not in the schema at all, which is genuinely additive. The chain enum being self-documenting keeps the remaining gap minor.

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: 'the last block at or before a given time' across eight named chains. No sibling tool does this, and the description makes the semantics (last block AT OR BEFORE) unambiguous, which is the key distinction an agent needs.

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 the intended use cases explicitly: 'pin eth_call reads, audits and snapshots to a moment.' It does not name alternative tools or state when NOT to use it, but no sibling overlaps this capability, so the practical routing gap is small.

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

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

Beyond the readOnly/openWorld/idempotent annotations it discloses the paid-call mechanics: $0.001 USDC per call via x402, an unpaid call returns the PaymentRequired object and must be retried with params._meta["x402/payment"]. It also describes exactly what an omitted-chain call returns (median, spread, per-feed age, round id, raw eth_call), which is behavior an agent cannot infer from annotations.

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

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

One dense front-loaded paragraph that leads with what is priced and on which chains before moving to return shape and payment. The x402 retry sentence is long but is genuinely operational, not 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?

There is no output schema, so the description carries the return-value burden and does so: median, cross-chain spread, per-feed age in seconds, round id, and the exact eth_call. Combined with the payment flow and error path, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% and both parameters already carry descriptions, so the baseline applies. The description restates the omit-chain aggregation behavior and the USD-only quote constraint that the schema already encodes, adding little new parameter-level meaning.

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

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

States a specific verb (read with latestRoundData()) and resource (Chainlink aggregator price) plus the exact asset list and six supported chains. It explicitly disclaims being a DEX quote, which is the most likely confusion in a toolset full of token/price helpers.

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

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

Gives a concrete usage rule: omit chain to read every chain with the pair and get median/spread/age. It also sets a boundary versus DEX quotes. It does not name a specific alternative tool in this server, but no sibling is a competing price oracle, so the routing guidance is effectively complete.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description goes far beyond them: it discloses the live DNS-over-HTTPS transport, the Cloudflare/Google resolvers, the absence of WHOIS, the x402 payment requirement, the exact behavior of an unpaid call (returns PaymentRequired), and the retry mechanism via params._meta. This is exactly the kind of behavioral context annotations cannot convey.

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

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

The definition is dense but front-loaded: the record list comes first, then transport and payment details. Every sentence carries information, though the single long sentence packs a lot and could be split for readability. 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 complex multi-check tool with no output schema, the description fully covers what is returned (including a plain-language issues list, status, final URL, HSTS, server) and how payment works. An agent has everything needed to call it correctly without opening anything else.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the enum. The description adds only a mild restatement ('domain (or URL)' and 'https=0 skips the HTTPS GET'), which is redundant with the schema. Baseline 3 is appropriate when structured fields do the heavy lifting.

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

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

The description opens with a specific verb+resource ('One call for a domain (or URL)') and then enumerates exactly which records and checks are returned (A/AAAA, NS, SOA, MX, TXT, CAA, DNSSEC, SPF, DMARC, MTA-STS, HTTPS GET). This is far more specific than any sibling and lets an agent distinguish it from email_check or address_info immediately.

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

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

It clearly states the use case ('One call for a domain') and a scoping exclusion ('No WHOIS'), plus an option to skip the HTTPS GET. It does not explicitly name alternative siblings or say when not to use it, so it falls short of the explicit when/when-not/alternatives bar.

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

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

Goes well beyond the annotations: it discloses the DNS-over-HTTPS mechanism, the null-MX/A-fallback semantics, the explicit non-behavior (no SMTP contact) and its consequence, plus the full payment protocol — $0.001 USDC on Base, x402, the PaymentRequired object on an unpaid call, and the retry via params._meta['x402/payment']. That is exactly the operationally critical context an agent would otherwise hit blind.

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 decision question, then the check list, then the limitation, then the payment mechanics — a sensible priority order. The x402 payment sentence is dense but load-bearing since a first call will fail without it; only minor tightening is possible.

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

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

There is no output schema, and the description compensates by naming the components of the response (per-check results plus a verdict). Adequate for correct invocation; only the verdict's possible values are left unspecified.

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

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

A single required parameter with 100% schema description coverage, so the baseline is 3. The description adds no format or normalization guidance for the email value (e.g. whether plus-tags or role accounts are expected input) beyond restating that it takes an address.

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 ('syntax check, then the domain's mail route via DNS-over-HTTPS') and enumerates exactly what is inspected (MX, null MX, SPF, DMARC, role accounts, plus-tags, verdict). An agent can tell this is an email-deliverability check, though it never distinguishes itself from the sibling domain_check, which overlaps on the DNS portion.

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?

'Is this address worth sending to?' frames the decision context well and the explicit limitation ('does not contact the mail server, so it cannot confirm that the mailbox itself exists') sets a clear boundary on when its answer is sufficient. No sibling is named as an alternative for the cases it can't cover, which keeps it short of a 5.

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

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

Goes well past the readOnly/openWorld/idempotent annotations: discloses live resolution via the ENS Universal Resolver with CCIP-read, a per-call price ($0.001 USDC on Base), the x402 flow, and concretely what an unpaid call returns plus the exact retry mechanism (params._meta["x402/payment"]).

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 primary name→records behavior, followed by the address mode and then payment mechanics. It is dense with parentheticals and a raw HTTP endpoint, but nearly every clause carries operational value.

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

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

With no output schema, the description still enumerates the returned fields (address records, resolver, url/avatar/com.twitter/description, reverse_matches) and covers the payment failure path and HTTP equivalent. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: name yields records plus reverse_matches, while address yields a forward-verified primary name across mainnet and Base/ENSIP-19. That explains the semantic difference between the two optional parameters, not just their syntax.

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 (resolve) plus both directions (name→address records, address→primary name) and names the namespaces (ENS, Basename, ENSIP-19). An agent can distinguish it from sibling lookups like domain_check or address_info from the description alone.

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

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

The 'Or pass address= for its forward-verified primary name' clause makes the two usage modes explicit, so an agent knows which parameter selects which behavior. It stops short of naming alternatives (e.g., address_info, domain_check) or stating when not to use it.

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

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

Annotations only say read-only/idempotent/open-world, while the description adds the facts an agent actually needs to succeed: a price of $0.001 USDC on Base, x402 payment flow, the exact retry mechanism (params._meta["x402/payment"]) after a PaymentRequired response, and a parallel HTTP route. It also discloses what is returned per spender, including unlimited-approval and plain-EOA flags, which is behavioral context the annotations cannot carry.

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

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

The core question and chain scope are front-loaded, then the return fields, then payment mechanics, then the HTTP equivalent. It is dense but each block earns its place; the HTTP GET route and the chain enumeration are slightly redundant against the title and enum, keeping it from a 5.

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

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

With no output schema, the description compensates by enumerating the return payload (allowance per spender, balance, symbol, decimals, spender classification, unlimited/EOA flags). Payment and error-retry behavior are spelled out, so nothing essential for a correct call is missing.

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

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

Schema coverage is 75% and the schema already documents owner, token, and the comma-separated spender list. The description echoes the 'up to 10 spenders' batch semantics but adds no format or validation detail beyond that, so the schema is doing the heavy lifting. A 3 is the appropriate baseline at this coverage level.

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

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

Opens with a precise question ('How much can each spender pull from an owner's tokens?') and then names the exact operation, allowance(owner, spender), the chain set, and the batch size. It is unmistakably distinct from siblings like token_balances 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?

"Use before or after approving, or to audit what to revoke" gives concrete when-to-use context for a read-only approval check. It stops short of naming alternatives or exclusions, but the lifecycle placement is clear enough to route an agent correctly.

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

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

Annotations only cover read-only/idempotent/open-world; the description adds the hard contract details that matter: pinned block by default, off-chain registration fetch over https/ipfs/data, sha256 integrity, wallet/registrations[] cross-check, and returned eth_call data for independent re-verification. It also discloses the paid-access behavior most agents would trip on: $0.01 USDC on Base via x402, unpaid calls return PaymentRequired, and retry requires params._meta['x402/payment'].

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 use case, then the read semantics, then payment mechanics; every clause carries information (even the HTTP endpoint mirrors a real alternative transport). It is dense and clause-stacked rather than cleanly sectioned, which costs it the top score but not much else.

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 tells the agent what comes back (three registry getters, fetched registration file, sha256, match verdict, raw eth_call data) and how payment failures manifest. That is sufficient for an agent to call this correctly and interpret failures.

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

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

Schema coverage is 67%, and the description compensates: it enumerates all eight chains in prose, clarifies that `id` is the numeric agentId used for ownerOf/getAgentWallet, and explains that `block` pins the registry read (consistent with the schema's 'default latest'). Minor residual ambiguity about the `block` format is left to the schema.

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

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

States a precise verb and resource ('reads the ERC-8004 Identity Registry at 0x8004A169…a432'), names the exact return fields (ownerOf, getAgentWallet, tokenURI), and adds the file-verification step. Nothing in the sibling list (address_info, token_info, tx_decode) does identity-registry lookups, and the description makes that unique scope obvious.

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?

'Know-your-agent check before you pay or hire an agent' gives a clear triggering context, and the pinned-block framing implies when to use `block`. It does not name an alternative tool or an explicit when-not-to-use case, so it stops short of the 5 bar.

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

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

Annotations only cover readOnly/openWorld/idempotent, so the payment behavior had to come from the description — and it does: $0.001 USDC on Base per call via x402, unpaid calls return a PaymentRequired object, and the retry path is params._meta["x402/payment"]. That is exactly the non-obvious operational detail an agent cannot infer.

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

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

A single dense paragraph with the substantive content (what it returns, which chains) front-loaded and the pricing/payment mechanics trailing. Dense but no filler sentences; the URL endpoint note is marginal but defensible.

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

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

With no output schema, the description must describe returns, and it enumerates the fields and the denomination (native coin). Payment and error-path behavior are fully covered. It stops short of stating units or freshness/caching, which would matter for a price tool an agent might cache.

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

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

Schema coverage is 100% with an enum, so the baseline is 3; the description earns an extra point by documenting an out-of-schema parameter (the x402 payment _meta key) and restating the all-chains default. It adds no unit or format guidance for the enum values themselves.

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

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

The description names the exact resource (gas price, base fee, priority fee, block fullness, transfer costs) with concrete gas units (21k, 65k) and enumerates all eight supported chains. An agent can tell immediately this is a gas-oracle snapshot tool, distinct from price or balance siblings.

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

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

It clearly states the default behavior (omit chain for all 8) and the single-chain option, plus the one-line HTTP equivalent. It does not name an alternative or exclusion case, but no sibling tool overlaps in function, so the selection context is effectively unambiguous.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the x402 payment mechanic: an unpaid MCP call returns a PaymentRequired object and must be retried with params._meta["x402/payment"], priced at $0.01 USDC on Base. That is exactly the non-obvious behavior an agent needs to avoid failing. It also notes the output mirrors the free web generator, which is useful context. Generating text is consistent with readOnlyHint=true, so there is no contradiction.

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

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

The output artifact is front-loaded and every clause carries information (styles, contents, price, transport behavior, HTTP equivalent). It is dense in a single block, though the inline HTTP endpoint is marginal for an MCP caller and slightly crowds the core message.

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

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

With no output schema, the description correctly states the return shape (JSON containing the policy and PR template) and covers the payment handshake an agent must implement. The main gap is leaving the 'project' parameter's effect and the optionality of both inputs 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%, so the description has to carry the load. It does enumerate the three style values inline and reveals the hidden payment parameter (_meta["x402/payment"]), which adds real value. However, the 'project' parameter is never explained, and neither param is marked optional (required set is empty), so coverage is partial.

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 artifact (AI_POLICY.md plus a PR template with an AI-disclosure section) and enumerates the three style variants, so the agent knows exactly what it gets back. It does not distinguish itself from the sibling repo_ai_policy, which sounds like it produces similar output, leaving ambiguity over which to call.

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

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

There is no when-to-use / when-not-to-use guidance and no explicit routing to or away from the near-identical sibling repo_ai_policy. The only implied usage signal is the pricing note, which tells the agent it costs money but not when this is the right tool over its alternatives.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it names the exact files read, the shape of the return (verdict, evidence lines with file:line, build/test commands), warns that the verdict is a keyword heuristic requiring evidence review, and discloses the $0.01 USDC x402 paywall plus the unpaid-call PaymentRequired retry path. That paywall disclosure is critical behavioral context an agent cannot get from annotations.

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

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

Front-loads the core question and the trigger before the mechanics, and every clause carries information. It is dense and slightly run-on in the payment/pricing clause, but nothing is filler.

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

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

With no output schema, the description correctly takes on the job of describing return values (verdict, file:line evidence, build/test commands) and explains the paid-call protocol and the equivalent HTTP endpoint. An agent has everything needed to invoke it and interpret the result.

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

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

The single `repo` parameter is fully documented in the schema (owner/name or URL, public repos), so the schema carries most of the load. The description adds one non-obvious detail the schema omits: the x402 payment is passed via params._meta["x402/payment"], which materially changes how the call is made.

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: it reads a repo's AI_POLICY/CONTRIBUTING/AGENTS.md/PR template/SECURITY files and returns a verdict on whether AI-assisted contributions are allowed. That is far more specific than the name alone. It does not, however, differentiate itself from the sibling tool `policy`, which an agent could plausibly confuse with this one.

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

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

Gives an explicit trigger: 'Before a coding agent opens a PR'. That is a clear usage context. It offers no exclusions or named alternatives (e.g., when to use `policy` instead), so it stops short of full routing guidance.

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

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

Goes well beyond the readOnly/idempotent annotations: discloses one Multicall3 eth_call per chain at a stated block, on-chain symbol/decimals resolution, raw+decimal return shape with a nonzero summary, absence of USD prices, and the full x402 payment flow (unpaid call returns PaymentRequired; retry via params._meta['x402/payment']) at $0.003 USDC per call.

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

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

Purpose and chain scope are front-loaded, and pricing/payment mechanics are grouped afterwards. The first sentence is overloaded with four chained clauses, but given the tool's complexity there is little pure 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?

With no output schema, the description still covers return values (raw and decimal amounts plus a nonzero summary), chain and token coverage, block semantics, and the payment handshake needed to actually invoke it. Nothing an agent needs to call it successfully is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that tokens= requires a single chain=, that token symbol/decimals are resolved on-chain, and that gnosis/celo are non-default. Some of this (the 20-token cap, the default chain list) duplicates 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 and resource ('Typed balances for one address: native coin plus USDC, USDT, WETH...') along with exact chain scope and a custom-token mode. The stated exclusions ('No USD prices', on-chain symbol/decimals) implicitly separate it from metadata/snapshot siblings like token_info or wallet_snapshot.

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

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

Clearly presents two usage modes: the default curated token set across six chains, or 'pass chain= and tokens= (up to 20 addresses) for your own list', with gnosis/celo noted as on-request. It does not name when to prefer a sibling tool or state when not to use this one.

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

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

Annotations only declare readOnly/openWorld/idempotent; the description adds the behavior that actually matters here: a per-call price ($0.001 USDC on Base), the x402 payment mechanics on first-call failure, and the parallel HTTP endpoint. That is real context beyond structured fields.

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

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

Front-loaded with scope and returned fields, then pricing/payment, then the HTTP mirror — a logical order with no filler. It is a single dense run-on paragraph, which costs a point on readability but not on information density.

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

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

With no output schema, the description carries the return-value burden itself and does so by naming every field including raw vs. decimal supply and EIP-1967/legacy OZ proxy slots with implementation and admin addresses. Combined with the payment flow, an agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 50%: 'token' is documented and 'chain' is an enum that the description re-enumerates. It adds value by disclosing an out-of-schema parameter channel — params._meta['x402/payment'] — which the agent cannot learn from the schema, though it does not clarify address formatting beyond '0x'.

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 ('For a token contract on base, ethereum... : name, symbol, decimals, total supply, code size, owner(), proxy status') and enumerates the exact payload returned, which cleanly separates it from siblings like token_risk, token_balances and erc20_allowance.

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 context is clear: call this when you need ERC-20 metadata plus upgradeable-proxy detection on one of the eight listed chains, and it explains the payment retry path (unpaid call → PaymentRequired → retry with _meta['x402/payment']). It does not explicitly route the agent away from siblings such as token_risk, so it falls short of full when-not guidance.

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

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

Beyond the readOnly/idempotent annotations it discloses the commercial and mechanical behavior: $0.003 USDC per call on Base via x402, an unpaid call returns a PaymentRequired object, and the retry must carry params._meta['x402/payment']. It also bounds the result honestly by listing what was not checked, which is exactly the context annotations cannot convey.

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

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

The controlling question is front-loaded and every clause is substantive — checked dimensions, output shape, price, payment flow, HTTP mirror. It is dense to the point of being a single run-on sentence, so scanning costs more than it should, but nothing is filler.

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

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

With no output schema, the description carries the return contract itself: a 0-100 score, one reason per flag, and an explicit not-checked list. Combined with payment mechanics and the HTTP endpoint, an agent has everything needed to invoke this correctly and interpret the response.

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

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

Schema coverage is 50%; only 'token' carries a description, and the description's re-listing of the eight chain names merely restates the enum rather than adding meaning (e.g. default chain, address format quirks). The only genuinely new parameter-level information is the _meta['x402/payment'] field needed on retry, which is useful but not schema-adjacent.

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: a deterministic risk screen of an ERC-20 token across eight named chains, computed from bytecode and eth_call only. It enumerates exactly what is inspected (proxy/admin, ownership, selector scan for mint/pause/blacklist/fee setters, supply concentration) and what is produced, which lets an agent separate it from metadata tools like token_info without opening a schema.

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

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

The opening question 'Is this token centrally controllable?' establishes the decision this tool serves, and the 'no third-party risk API' clause plus the explicit 'no DEX sell simulation' caveat tells the agent what the screen will not answer. It stops short of naming alternatives (token_info, token_balances) or stating when-not-to-call, so it is clear context without exclusions.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the $0.005 USDC price on Base, the x402 flow, that an unpaid call returns a PaymentRequired object rather than data, and the exact retry mechanism via params._meta["x402/payment"]. That is precisely the kind of non-obvious behavior an agent would otherwise stumble on.

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 returned fields, then chains, then pricing/payment mechanics — a sensible order. Mild redundancy in re-listing the chain enum and the HTTP route, but the density is justified for a paid tool.

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

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

With no output schema present, the description carries the full burden and does so by enumerating every returned field including raw and decimal amounts. Payment, retry, supported chains, and the HTTP equivalent are all covered, leaving nothing an agent needs to call this correctly.

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

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

Schema coverage is 50% (only tx is described), and the description compensates by enumerating the eight valid chains and characterizing tx as a transaction hash for an on-chain tx. It also documents the payment parameter _meta["x402/payment"], which appears nowhere in the schema — genuinely added 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?

Names a specific resource and the exact payload returned: success, block, UTC time, confirmations, sender, and every ERC-20/ERC-721 transfer decoded from the receipt. The framing 'Payment proof for any EVM tx' plus the chain list cleanly separates it from siblings like address_transfers (address-scoped) and tx_decode (decoding-only).

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 'Payment proof for any EVM tx' implies the use case, but the description never explicitly contrasts with address_transfers or tx_decode, nor states when-not to use it. The payment retry procedure is spelled out, but tool selection guidance is left to inference.

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

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

Annotations only cover read-only/idempotent/open-world; the description adds substantial context beyond them: the $0.003 USDC price, the x402 402-response-and-retry dance, and the important limitation that revert reasons are an 'approximate replay at the previous block'. That last caveat is the kind of behavioral detail annotations cannot express.

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

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

Front-loaded with the purpose and chain scope, then outputs, then pricing. It is dense but nearly every clause carries information. It is however one long run-on sentence, and the log-type enumeration is listy enough to be skimmable-fragile.

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

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

No output schema exists, so the description must describe return values — and it does thoroughly: success/revert status, method signature, decoded logs, net token flows, fees including L1. Combined with payment mechanics, an agent has everything needed to call it and interpret the result.

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

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

Schema description coverage is 100% and the enum already lists all eight chains, so the schema carries the semantics. The description restates the omit-to-search-all behavior and the chain list but adds no syntax or format detail beyond it; baseline 3 applies.

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

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

States a specific verb and resource ('Typed decode of any tx') and enumerates the eight supported chains plus the exact decoded outputs (method sig, logs, token flows, fee, revert reason). This clearly separates it from siblings like tx_find or token_transfers, which locate data rather than decode a transaction.

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: 'chain optional: all 8 are searched', the x402 payment flow including what an unpaid call returns and how to retry, and that the same capability exists at GET /api/tx-decode. It does not name a sibling alternative or state when not to use it, so it falls short of a 5.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description goes well beyond them: explicit per-call price ($0.002 USDC on Base), the x402 payment handshake and retry mechanism, and the exact response payload including L1 fees and log counts. This is the kind of context an agent needs to invoke it successfully and handle the failure path.

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 use case is front-loaded and the payment mechanics come last where they belong. The long mid-sentence enumeration of return fields is dense but each item is a real output the agent may key on; it is slightly over-stuffed for a single paragraph.

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

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

There is no output schema, so listing the returned fields is necessary and done thoroughly. Payment requirements, the retry path, and the parallel multi-chain scope are all present, leaving nothing essential for a correct invocation unstated.

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

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

With one parameter at 100% schema description coverage, the schema already documents `tx`; the description only reinforces that the hash may belong to any of the eight chains. No added syntax or validation guidance beyond the schema, so baseline 3 applies.

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

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

States a specific verb (search/returns) and resource (a transaction by hash across 8 named chains), with the exact chains enumerated and the returned fields listed. The framing 'Got a tx hash but not the chain?' makes intent obvious, but it never names the closest sibling (tx_decode) to differentiate when both could apply.

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 opening 'Got a tx hash but not the chain?' gives a clear triggering condition, and the payment section explains the prerequisite flow (unpaid call returns PaymentRequired, retry with params._meta['x402/payment']). It does not state exclusions or explicitly route to alternatives such as tx_decode.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld), and the description adds substantial non-structured behavior: the $0.002 price, that unpaid calls return an x402 PaymentRequired object, and the exact retry path via params._meta['x402/payment']. That x402 flow is critical and cannot be inferred from any structured field.

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

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

The core question and outputs are front-loaded, then payment/logistics detail. It is dense with no filler, though the pricing and HTTP-endpoint sentence is a long parenthetical that competes with the primary purpose for attention.

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

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

With no output schema, the description enumerates the return payload (success, confirmations, all USDC transfers, total to `to`, min check), which is exactly what an agent needs. Pricing and auth requirements are also covered, so nothing material is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by clarifying the semantics of `to` ('total received by `to`') and `min` ('whether it meets `min`'), tying them to the returned boolean rather than just naming 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?

Opens with a specific yes/no question ('Did this transaction pay USDC on Base to an address?') naming the chain, asset, and target, then enumerates the exact outputs. An agent can distinguish this from tx_decode (generic decoding) or address_transfers (outbound history) without reading the schema.

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

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

The framing as a verification question implies the use case (confirming payment) and the description covers the payment mechanics needed to actually invoke it. It does not explicitly state when to prefer tx_decode or address_transfers instead, so no exclusion guidance is present.

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

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

Annotations only declare readOnly/openWorld/idempotent; the description adds the decisive behavior the agent cannot infer: cost ($0.003 USDC on Base), the x402 flow (unpaid call returns PaymentRequired, retry via params._meta["x402/payment"]), and the equivalent HTTP endpoint. It also discloses the account-type taxonomy including EIP-7702 delegated EOAs.

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 payload and chains, then payment mechanics — every clause carries information with no filler. It is, however, one long run-on sentence, which makes the payment instructions harder to parse than a short structured break would.

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, so the description must describe returns — it does, itemizing every field plus totals and active-chain summary. Combined with the payment/transport details, an agent has everything needed to call it and handle the paid re-try correctly.

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

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

Only one parameter, and the schema already documents it as a '0x EVM address' at 100% coverage. The description adds no format, checksum, or validation detail beyond the schema, so baseline 3 applies.

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

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

States a concrete resource (wallet snapshot) and enumerates exactly what is returned — native balance, USDC/USDT balances, nonce, account type — across eight named chains. This clearly separates it from single-chain siblings such as address_info, token_balances and token_transfers without the agent needing to open any schema.

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

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

The opening 'One call, 8 chains' implies the use case (consolidated multi-chain portfolio view) and implicitly contrasts with per-chain calls. It does not name an alternative sibling or state when not to use it, so it stops short of full routing guidance.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses many important behaviors: robots.txt checks, bot identification, redirect handling, JavaScript limitations, private-host refusal, failure semantics, and the x402 payment flow. It also explains that failed fetches do not charge clients, which is critical context for a paid tool.

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

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

The description is front-loaded with the core action and then packs in the extraction fields, limitations, and payment details without filler. It is a dense single paragraph, so readability could improve with structure, but every sentence carries relevant information for invoking the tool correctly.

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

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

There is no output schema, and the description compensates by listing the returned fields and explaining failure behavior and payment semantics. Given the tool's complexity, the description provides enough information for an agent to call it correctly and understand what to expect.

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

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

Schema description coverage is 100%, so both url and max_chars are already well documented by the schema. The description reinforces the default text limit and adds the x402 payment retry metadata path, but it does not add substantial new syntax or constraints for the declared input parameters beyond what the schema already 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?

The description states a specific verb and resource: fetching one public web page and extracting structured page data. It clearly distinguishes this from the sibling tools, which are mostly crypto, policy, and AI utilities, and enumerates the returned fields so the agent knows exactly what kind of extraction this is.

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

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

It gives clear usage constraints: public pages only, robots.txt respected, no JavaScript rendering, private hosts refused, and failed fetches returning an error status. It does not name an alternative sibling tool, but none of the siblings appear to overlap with web page extraction, so the context is sufficient.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses the per-call price ($0.005 USDC on Base), the exact payment handshake failure mode, and the response shape ('errors, warnings and human-readable prices'). This is precisely the cost/auth/flow context an agent needs before calling an open-world network tool.

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

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

Front-loaded with the core action and validation checklist, then payment mechanics, then the HTTP mirror. The long field enumeration is dense but each item specifies real validation behavior; only minor tightening is possible.

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

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

No output schema exists, and the description covers what comes back (errors, warnings, human-readable prices), the cost, the failure/retry path, and an alternative transport. Nothing essential for correct invocation 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?

With 50% schema coverage and an undocumented `method` enum, the description should compensate but doesn't mention `method` at all. It does add meaning the schema omits — the implicit `_meta["x402/payment"]` parameter for payment retry — which is valuable, but half the parameter surface remains unexplained.

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 pair ('Probe any public x402 endpoint and validate its 402 challenge') and then enumerates exactly what is validated (version, accepts[], CAIP-2 network, amounts, payTo checksum, EIP-712 extra, Bazaar discovery, /openapi.json). No sibling tool does anything similar, so differentiation is implicit but unambiguous.

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

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

Scopes usage to 'any public x402 endpoint' and tells the agent how to complete a paid call: an unpaid call returns the x402 PaymentRequired object, then retry with params._meta["x402/payment"]. It also gives an HTTP alternative (GET /api/x402-lint). No explicit when-not guidance or sibling comparison, but the target context is clear.

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