P0 Agent Economy Index (old entry)

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

The annotations declare readOnlyHint=true, but the description states that with a P0 access key the tool 'makes the paid call itself and returns the data, deducting the listed price.' Deducting a balance is a state-changing financial side effect, which contradicts the read-only annotation despite the otherwise useful disclosure of pricing, auth, and pre-charge refusal.

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 primary use case and alternative, then adds pricing, auth, and P0-key behavior. It is somewhat dense and includes a long purchase URL, but those details are relevant to correct invocation and charging behavior.

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 one fully documented parameter, no output schema, and the complexity of paid x402 routing, the description covers the return value (exact paid request plus response schema and example), pricing, refusal-before-charge behavior, auth via P0 key, and the alternative browsing tool. Nothing essential for an agent to call it correctly is missing, aside from the annotation contradiction noted above.

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 input schema already has 100% description coverage for the single 'task' parameter, including an example. The description reinforces the plain-words usage but adds no new syntax or constraint details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: it helps a router agent pick which paid x402 service to send a task to. It clearly distinguishes itself from search_x402_services by stating that this tool returns a recommendation for one task while browsing/comparison belongs to the sibling 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?

It explicitly states when to use the tool ('Use when a router agent must pick which paid x402 service to send a task to') and names the alternative for browsing or comparing ('use search_x402_services'). It also explains the two operating modes: returning a paid request versus making the paid call with a P0 key.

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 mark this read-only/idempotent/non-destructive, and the description reconciles that apparent paradox by explaining this tool only returns the exact paid x402 request payload rather than charging the card itself ('POST that JSON body to the URL with an x402 or MPP client to get the data'). It adds price, currencies (USDC/USDT), accepted protocols (x402 or MPP), validation-before-charge behavior, and a free check endpoint — context 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 what is bought, the price, and the payment mechanics, with the monthly alternative placed late but reachable. Some redundancy ($990 stated twice, the POST /buy/brandwatch endpoint restated) costs it the top mark.

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 compensates by promising 'the response schema and an example' in the returned payload, and covers payment, validation, and the free-check path. It is slightly thin on what actually happens after payment succeeds (how the digest/data is delivered), but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 67% and the schema already documents domain and email usage (weekly digests) as well as the optional contracts array. The description only restates that email is required for the check call ('the same body') and adds no format or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb, resource and scope: 'Lookalike-domain alerts, yearly... $990 in one payment', and explicitly names the endpoint (POST /buy/brandwatch) and the sibling it is not ('for one month use buy_brandwatch_monthly'). An agent can distinguish it from buy_brandwatch_monthly and buy_dao_report without opening schemas.

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

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

Gives explicit selection criteria ('Yearly plan; for one month use buy_brandwatch_monthly'), a recommended free trial path ('POST the same body to /buy/brandwatch/check (email required)'), and a safety note ('Bad input is refused before any charge'). Alternatives and preconditions are both covered.

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

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

With readOnlyHint=true and destructiveHint=false already declared, the description adds substantial context: the $99 USDC/USDT cost, that the call returns an unsigned x402 request body plus response schema and example rather than the data itself, that bad input is refused before any charge, and that a free /check endpoint exists. It does not mention rate limits or wallet prerequisites beyond 'x402 or MPP client'.

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?

Well front-loaded — purpose, price and payment rail come first — and every sentence carries information. It is somewhat dense and repeats the price and endpoint in a parenthetical, but no sentence is pure filler.

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

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

There is no output schema, so the description carries the burden of explaining what comes back, and it does: the exact paid x402 request, its schema and an example, plus the POST target. Combined with the pricing, validation and alternates, an agent has what it needs to call and act on the result, though the exact auth/wallet setup is left implicit.

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

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

Schema coverage is 67% and the schema already documents email (as the digest recipient) and domain. The description mentions the email requirement and the free-check body, but adds no format or constraint detail for domain or the optional contracts array. 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 (buy), a specific resource (lookalike-domain alerts, monthly) and the price/rail, and explicitly routes the yearly case to buy_brandwatch. An agent can distinguish this from the 40+ siblings without opening the schema.

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

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

Gives clear context: prepend the free check at /check before paying, and 'for a year use buy_brandwatch' names the sizing alternative. It stops short of stating exclusions versus adjacent products such as domain_report or buy_lead_list, which would have made it 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?

Adds substantial context beyond annotations: price and accepted stablecoins, that invalid input is refused before any charge, and that the result is a request body you POST with an x402/MPP client. Payment rails (x402 or MPP) are disclosed, though the wording leaves mild ambiguity about whether this call itself charges versus returns a prepared paid request, which matters against readOnlyHint=true.

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 key fact (monthly DAO treasury report, $99), but the price/payment information is repeated — '$99 in one payment' and the POST /buy/dao-report endpoint appear twice, and 'Payable with x402 or MPP' restates the opening sentence.

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

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

Without an output schema, the description still tells the agent what comes back (the paid request, response schema, and an example) and how to complete the transaction. The only gap is the ambiguity around who executes the charge.

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 chain, email, space and address are already documented in the schema. The description adds flow-level meaning (email is optional here but required for the free check) but does not clarify the space-vs-address tradeoff, so baseline 3 applies.

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

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

States a specific verb and resource plus scope and price: a monthly DAO treasury report bought in one x402 payment for $99. It explicitly names the sibling buy_dao_report_yearly for the annual variant, so an agent can disambiguate without opening either schema.

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

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

Gives concrete usage routing: use buy_dao_report_yearly for a year, and optionally run the free /buy/dao-report/check first (email required there). It does not cover which sibling to use for general discovery (list_paid_data_products / search_x402_services), but the core alternative is named.

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?

Adds real context beyond the annotations: the $990 charge, that bad input is refused before any charge, the two acceptable payment rails, and that the tool returns a paid request rather than the data itself. Annotations already cover safety/idempotency, so this extra pricing and charge-timing detail is genuinely value-adding; it stops short of describing retries or failure modes after a charge.

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 most important facts (what it is, price, sibling difference) are front-loaded, but the text is redundant: '$990' and 'in one x402 payment' each appear twice, and the endpoint POST path is repeated. It is information-dense but not tight.

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 stating the return is the paid x402 request plus a response schema and example, and by explaining the two-step pay-then-POST flow. That covers what an agent needs; only post-payment error behavior is unaddressed.

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

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

Schema coverage is 100%, so the parameters are fully documented in the schema and the enum for chain is given there. The description only adds that email is required for the check endpoint, which is marginal; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('buy DAO treasury report, yearly') plus price and payment rail, and explicitly distinguishes itself from the sibling buy_dao_report ('Yearly plan; for one month use buy_dao_report'). An agent can select it without opening either schema.

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

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

Gives explicit routing for yearly vs monthly, describes the free pre-check path ('POST the same body to /buy/dao-report-yearly/check'), and states the workflow (POST body to URL with an x402 or MPP client to get data). Nothing is left to inference.

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

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower, yet the description adds genuinely useful context: exact price ($290), accepted tokens (USDC/USDT), supported payment protocols (x402 or MPP), and the pre-charge validation guarantee ('Bad input is refused before any charge'). It also discloses the two-step nature of the operation and the free check endpoint, which the annotations do not 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 text is information-dense and front-loads the core action, but it is repetitive: $290 appears twice, x402/MPP appears twice, and the run-on sentence with nested parentheticals ('...for your input (POST /buy/listing, $290 in one payment), with the response schema and an example; POST that JSON body...') is harder to parse than it needs to be. Trimming the duplicated price and protocol mentions would tighten it without losing content.

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

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

With no output schema and annotations that only cover the safety profile, the description does most of the work: it names the endpoint, price, payment tokens and protocols, the validation guarantee, and the free-check alternative. Gaps remain — it does not describe how the returned request body is structured beyond 'response schema and an example', nor how the email parameter affects delivery for this tool specifically.

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?

All three parameters (urls, email, contact_name) already carry descriptions in the schema, so the schema does the heavy lifting and a 3 baseline applies. The description adds no new meaning about urls or contact_name, and its only parameter-adjacent remark — '(email required)' — refers to the separate /buy/listing/check endpoint, not this tool's optional email field, which could momentarily confuse the reader.

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

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

The description states a concrete deliverable: it returns the exact paid x402 request body for the supplied URLs (POST /buy/listing, $290), plus a response schema and example. The verb/resource pair is clear enough to distinguish it from non-purchase siblings like list_paid_data_products. However, the opening 'buy it in one x402 payment, $290' blurs whether the tool performs the purchase or merely emits the request, and it never contrasts itself with the many other buy_* 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?

Usage is implied through the workflow ('POST that JSON body to the URL with an x402 or MPP client to get the data') and the offered alternative path ('A free check first: POST the same body to /buy/listing/check'). But there is no explicit when-to-use/when-not guidance relative to alternatives such as search_x402_services or the other buy_* tools. The agent must infer that this is the purchase step for discovery listings specifically.

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 exact cost ($390 in USDC or USDT), the payment rails (x402 or MPP), validation-before-charge ('Bad input is refused before any charge'), and the unusual return contract (it returns a request spec plus schema and example rather than the data). The only soft spot is that whether invoking the tool itself moves funds is implied by the two-step flow rather than stated outright.

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 key facts are front-loaded, but the text repeats itself: '200 contacts' twice, '$390' twice, and x402/MPP three times across the same paragraph. Trimming the restatement would sharpen it without losing information.

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

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

With no output schema, the description usefully explains what is returned (the paid x402 request, response schema, and an example) and how to consume it, which an agent needs. The remaining gaps are parameter semantics and any differentiation from the other buy_* tools in the catalog.

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%, and the description adds essentially nothing about the six inputs (profile, keywords, regions, countries, exclude_domains, email). The only param-like mention ('email required') refers to the separate /buy/leads/check endpoint, not this tool's optional email field, which could actively mislead.

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 ('buy' a 'Verified B2B contact list, 200 contacts') plus the price and payment rail, so an agent immediately knows what is being obtained. It does not, however, differentiate itself from the many sibling buy_* tools (buy_brandwatch, buy_market_report, buy_discovery_listing), relying on the resource name 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?

Provides concrete workflow context: run the free check first ('POST the same body to /buy/leads/check (email required)') before paying, and explains the two-step pattern of obtaining the request then POSTing it yourself. It gives no explicit routing versus sibling tools, so it is clear context without exclusions rather than a full when/when-not map.

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

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds what annotations cannot: the x402 payment flow, the $0.01 price, that bad input is refused before any charge, and that a P0 key makes the tool perform the paid call itself. This is exactly the economic and side-effect 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 usage and check scope, then payment details, then alternatives — good ordering. It is dense and a single long block (payment, auth, and routing all run together), so minor points lost for structure, but 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?

No output schema exists, and the description compensates by stating the tool returns the exact x402 request (GET /v1/email/verify, $0.01) with response schema and example, plus how to authenticate with a P0 key. An agent has everything needed to call and follow through.

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

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

Schema coverage is 100% and the single `email` parameter is documented with an example in the schema, so the description needn't restate it and largely doesn't. Baseline 3 is correct when the schema does the heavy lifting for a one-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?

States a specific verb+resource and enumerates exactly what is checked: syntax (IDN-aware), MX with A/AAAA fallback, null MX, disposable and role addresses. It also explicitly distinguishes itself from check_email_batch (lists) and domain_report (whole-domain DNS/SPF/DMARC).

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?

Opens with explicit trigger conditions ("before sending, signing up a user or adding a lead") and names two alternatives with the conditions that select them. Nothing is left to inference about when to use this vs siblings.

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 it as a safe, idempotent read; the description adds what they cannot: the two execution paths (returns a prepared x402 request body vs. executes the paid call itself with a P0 key), the $0.25 per-call price, and the guarantee that malformed input is refused before any charge. That pricing/authorization/failure-ordering detail is exactly the context an agent needs before invoking a paid endpoint.

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 usage trigger, then the payment mechanics, then the key-based alternative path. Dense but nearly every clause carries operational information; the inline purchase URL and price are justified for a paid tool, though the sentence about the P0 header is long enough to slow scanning slightly.

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 batch endpoint with no output schema, the description supplies everything needed to succeed: input limits, the exact HTTP method and path of the returned request, the price, how to settle it (x402/MPP client or P0 key), and the pre-charge validation guarantee.

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 already documents the 1-25 range, max length, and duplicate removal. The description only restates the 'up to 25' cap and adds no format, normalization, or ordering detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('check a list of email addresses'), the batch limit (up to 25 in one POST), and that each entry is checked exactly like /v1/email/verify. It also explicitly contrasts with the single-address sibling, so an agent can pick the right tool 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?

'Use when you must check a list of email addresses before a mailing or import' gives an explicit trigger, and 'For one address use check_email_address' names the alternative tool and the condition that selects it. Both halves of the use-when / use-instead pair are 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?

Goes well beyond the readOnly/idempotent annotations: discloses the price ($0.005 per call), that the default return is a paid request spec rather than data, that invalid input is refused before any charge, and the exact auth header format for the P0 key path. This is unusually rich; only the P0 balance/failure behavior under error conditions is left implicit.

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 use case and data contents, with the purchase mechanics and pricing following. Dense and mostly earning its place, though the full buy-URL plus key-path explanation makes it long for a single-parameter 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?

Covers everything an agent needs for a single-param, no-output-schema tool: what data comes back, that the default response is a request spec with its own schema and example, cost, and both invocation modes. Nothing material is missing.

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

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

Schema coverage is 100% and the single parameter is fully documented there (URL accepted, host-only, IPs and private names refused). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('one report on a domain') and enumerates exactly what it contains: DNS records with SPF/DMARC parsing plus RDAP registration fields. Names the siblings it is not (domain_report_batch for several domains, check_email_address for a mailbox), so the agent can route without inspecting schemas.

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

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

Opens with an explicit 'Use when' trigger, then gives explicit alternatives with their selecting conditions: domain_report_batch for multiple domains, check_email_address for a mailbox. It also states the decision between buying the raw x402 request versus using a P0 key.

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

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

Beyond the annotations, it discloses pricing ($0.05 per call), the x402/MPP payment flow, that invalid input is refused before any charge, and the P0 key behavior (Authorization: Bearer p0k_, where to buy, price deducted). These are the kind of billing/auth details an agent cannot infer from readOnlyHint/idempotentHint.

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 use case and alternative, then pricing/auth flow. Dense but nearly every sentence carries needed information; the long buy-key URL and payment mechanics make it longer than ideal but not padded.

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

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

With no output schema, the description compensates by explaining the return payload (the exact x402 request, response schema, example) and what the agent must do with it. Auth, cost, and failure behavior are all covered, so an agent has everything needed to invoke and complete the call.

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

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

Schema coverage is 100% and the schema already documents the 1–10 range and duplicate removal. The description's 'each answered exactly like /domain/report' adds slight semantic value about per-item output, but most parameter meaning lives in the schema, so baseline 3 is correct.

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 ('vet several domains at once'), gives the batch cap (up to 10 in one POST), and explicitly distinguishes from the single-domain sibling domain_report. An agent can tell exactly what it does and how it differs from domain_report.

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?

Opens with an explicit trigger ('Use when you must vet several domains at once (vendors, leads, lookalikes)') and names the alternative with its selection condition ('For one domain use domain_report'). Both when-to-use and when-not are 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 already cover read-only/idempotent/open-world safety, and the description layers on genuinely additive behavior: $0.001 per-call pricing, validation refusing bad input before any charge, the exact endpoint (GET /evm/block), and the auth header format with a key-purchase URL. This is well beyond what structured fields disclose.

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

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

Front-loads the use case in the opening clause, then moves to pricing, failure behavior, and auth. The final sentences are dense with nested parentheticals (URL, price, header, purchase link), which slightly hurts scannability but every element is load-bearing.

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

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

With no output schema, the description compensates by enumerating the returned header fields and noting the response schema plus example are included. Pricing, validation-before-charge, and both authentication paths are all disclosed, so an agent can call this correctly on the first try.

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 params are self-documented (chain enum with default base, number accepting decimal/0x hex or latest). The description restates chain names and 'latest or a given number' but adds no new syntax or edge-case meaning, so the baseline 3 applies.

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

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

States a specific verb+resource with scope: a block header across five named chains, latest or a given number, plus the fields returned (hash, parent, timestamp, miner, gas used/limit). This cleanly separates it from siblings like evm_transaction, evm_receipt, and evm_code without opening their schemas.

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

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

"Use when you need a block header" gives a clear selection trigger, and the description explains the two invocation modes (raw x402 request vs. P0 access key making the paid call itself). It never names a sibling alternative or states an exclusion, so it stops 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 declare read-only/idempotent/open-world but say nothing about payment. The description adds the crucial non-obvious behaviors: $0.002 per call, x402/MPP payment flow, refusal before charge on bad input, and the P0 access key path that auto-pays and deducts. That is substantial 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?

Purpose and scope are front-loaded in the first clause, and the payment mechanics follow logically. It is a dense single paragraph that is longer than most, but every clause (pricing, error behavior, auth path) carries operational weight; only the embedded key-purchase URL is slightly noisy.

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 output schema and a non-trivial payment wrapper, the description covers return fields, cost, error handling, authentication, and the two calling modes (raw request vs. auto-pay). An agent has enough to call it correctly without guessing.

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 (address pattern, chain enum with default) are fully documented in the schema. The description mentions chains and address semantics but adds no format or constraint detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific question the tool answers ('whether an address is a contract') and names the exact return fields (is_contract, bytecode size, sha256), plus the five supported chains. This clearly distinguishes it from sibling read tools like evm_erc20_balance, evm_nonce, or evm_block.

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 'Use when you must know whether an address is a contract' gives an explicit triggering condition. It does not name alternatives or exclusions (e.g. when to prefer evm_erc20_balance for token checks), 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?

Goes well beyond the readOnly/idempotent annotations: discloses the price ($0.002 per call), the x402/MPP payment flow, that malformed input is refused before any charge, and the optional P0 access-key header behavior where the tool performs the paid call itself. This is exactly the payment/auth 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 "Use when..." trigger, then the two lookup modes, then the payment mechanics — a logical order with little waste. The very long key-purchase URL and the payment paragraph make it denser than ideal for a two-parameter lookup tool.

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

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

With no output schema, the description carries the return-value burden and does so: it explains that the result is the prepared paid x402 request (GET /evm/ens) with response schema and example, and how to turn that into data. 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 would be 3, but the description adds mode-selection semantics and concrete example values (vitalik.eth, 0x...) that clarify how each parameter changes the operation. It also implies mutual exclusivity of the two parameters, which the schema itself does not 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 specific resource (ENS on Ethereum) and both operations precisely: forward name→address via the Universal Resolver, and reverse address→primary name with forward verification. This is instantly distinguishable from the sibling EVM tools (evm_block, evm_code, evm_native_balance), which do not touch name resolution.

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 when you need ENS on Ethereum" plus the explicit branch rule (set name for forward, address for reverse) gives clear selection guidance between the tool's two modes. It does not name a sibling alternative or state when-not to use it, 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?

Well beyond the annotations (readOnly/idempotent/openWorld), it discloses the paid x402 flow (GET /evm/erc20-balance, $0.002/call), that bad input is rejected before any charge, and that a P0 access key in the Authorization header makes the tool perform the paid call itself with deduction. That is exactly the cost/auth/error context annotations cannot carry.

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

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

It is front-loaded with the trigger condition and scoped alternative before the payment mechanics, and every clause carries information. It runs long, however, and the embedded key-purchase URL plus the dual paid-call/direct-call explanation make it denser than strictly necessary for selection.

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

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

With no output schema, the description compensates by describing the returned fields (balanceOf, decimals, symbol, raw units, decimal amount) and by explaining both the returned x402 request shape and the direct-return mode with a key. Pricing, error handling, and chain coverage are all covered, leaving no gap an agent would need to guess at.

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 per-property descriptions and an enum for chain, so the schema already carries the parameter burden and baseline 3 applies. The description adds only indirect context (which chain set is supported and that symbol/decimals are read alongside the raw balance), not new per-parameter meaning such as address format or token-address 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?

The first sentence states a specific verb and resource: read balanceOf, decimals and symbol for one ERC-20 token on one wallet via a single multicall, across five named chains. It also explicitly distinguishes itself from wallet_balance (multi-token/multi-chain), so an agent can route correctly without opening the schema.

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

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

"Use when you need one ERC-20 balance for one wallet" gives the positive trigger, and "One token on one chain; for several tokens or chains at once use wallet_balance" names the alternative and the condition that selects it. Nothing about when to prefer this over a sibling 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?

Beyond readOnly/idempotent/openWorld annotations, it discloses the unusual two-mode behavior: by default it returns an x402 request descriptor (GET /evm/native-balance, $0.001 per call) that must be invoked with an x402/MPP client, while a P0 access key makes it perform the paid call and deduct the price. Cost, auth header format, and the pre-charge validation guarantee are exactly the traits 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?

Front-loaded with the use case and free of filler, but it is one dense paragraph mixing purpose, payment mechanics, an inline purchase URL, and behavioral caveats. Slightly long and unstructured, though 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?

With no output schema, the description still explains the return payload (wei, decimal amount, block number, as_of) and the indirection of the x402 response envelope with schema and example. An agent has everything needed to call it and to interpret either result 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 coverage is 100% and the chain enum plus address pattern are already self-documenting, so baseline 3 applies. The description restates the chain list and clarifies the returned coin varies by chain (ETH vs POL), but adds no format or defaulting detail beyond the schema.

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

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

States a specific verb and resource ('native coin balance (ETH or POL) of an address') plus the exact chain scope (Base, Ethereum, Arbitrum, Polygon, Optimism). It also names the sibling it is not: 'for stablecoins or several chains use wallet_balance', so an agent can separate it from wallet_balance and evm_erc20_balance without reading schemas.

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

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

Opens with an explicit 'Use when...' condition, gives a negative case routed to a named alternative (stablecoins/multi-chain → wallet_balance), and adds a safety rule ('Bad input is refused before any charge'). Nothing about when to select this tool is left to inference.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, but the description adds critical payment context: $0.001 per call, bad input refused before charge, dual invocation modes (request descriptor vs. key-backed execution), and the auth header/key purchase URL. This is exactly the kind of behavioral detail annotations cannot carry.

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

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

Purpose is front-loaded in the first clause, and every sentence carries relevant information. The second sentence is dense, packing payment, auth, purchase URL, and execution modes together, which is slightly harder to scan than it could be.

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

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

For a paid API with no output schema, the description is complete enough: it explains return values (latest and pending nonce), the descriptor mode, key-backed execution mode, billing, and pre-charge validation. 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?

Schema description coverage is 100%, with the address pattern and chain enum fully documented. The description repeats the supported chains and implies the address parameter but adds no syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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

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

States the exact resource (account transaction count) and the specific outputs (nonce at latest block plus pending nonce from the node's pool), and enumerates supported chains. This distinguishes it clearly from sibling EVM lookup tools like evm_transaction or evm_block.

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 when you need an account's transaction count..." gives a clear triggering condition and chain scope. However, it does not explicitly compare against alternative EVM tools or state when to prefer another sibling.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds the economics and flow the annotations cannot: $0.002 per call, bad input refused before any charge, two payment paths (returned x402 URL vs. automatic paid call with a P0 key and deduction). That is material behavioral context for a paid tool.

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

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

Front-loaded with the 'Use when' trigger and the returned fields, which is the right ordering. It is dense but not padded; the long key-purchase URL and parenthetical pricing detail weigh it down slightly, though each sentence still 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?

There is no output schema, and the description compensates by naming the returned fields and stating that the paid response includes a schema and example. Pricing, charge-safety, authentication options, and the sibling alternative are all present, leaving nothing an agent needs to call it correctly.

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

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

Schema coverage is 100% with a regex pattern for hash and a documented enum plus default for chain, so the schema carries the semantics. The description only repeats the chain list and adds no format, constraint, or validation nuances beyond it, 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 resource (transaction receipt) and enumerates exactly what it returns: status, block, confirmations, gas used, effective gas price. It also names the sibling evm_transaction and the boundary between them (receipt outcome vs. transaction fields), so an agent can distinguish them without opening schemas.

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

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

Opens with an explicit 'Use when you need to know whether a transaction succeeded' trigger and names the alternative 'for the transaction fields (from, to, value, input) use evm_transaction'. Both the when-to-use and the when-to-use-something-else are stated outright.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the pay-per-call cost ($0.002), that invalid input is rejected before charging, that input is truncated at 1 KB, and that supplying a P0 bearer key makes the tool perform the paid call itself with a deduction. Those are non-obvious cost, validation and auth behaviors an agent must know.

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 'Use when' trigger and ending with the sibling exclusion, so the key selection cues are at the edges. It is a dense single block covering two invocation modes and payment plumbing, which is a lot of prose for two parameters, though most sentences carry real 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, but the description enumerates the returned fields, notes the response includes a schema and example, and explains the dual direct/paid-URL invocation paths plus the error-before-charge guarantee. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100% — the hash pattern and the five-value chain enum with default 'base' are fully documented in the schema. The description restates the chain list but adds no format or semantics beyond it; the 1 KB note concerns returned input data, not a parameter. 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 verb and resource (fetch a transaction by hash) and enumerates exactly what comes back: from, to, value, nonce, gas/fee fields, block, confirmations, method id and truncated input. It explicitly names the sibling evm_receipt as the tool for status/logs, so it is distinguishable from related tools without opening a schema.

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

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

"Use when you need a transaction by hash on Base, Ethereum, Arbitrum, Polygon or Optimism" gives the triggering condition, and the closing sentence routes the agent to evm_receipt when success status, gas used or logs are wanted. Both the use case and the alternative are explicit.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context the annotations lack: the return shape (text, parsed JSON when applicable, size), the $0.001-per-call x402 payment model, and the guarantee that bad input is refused before any charge.

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 usage condition, then covers return values and payment mechanics. Dense but each clause earns its place; no redundant restatement of the name or title.

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

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

With no output schema, the description carries the burden of describing return values and does so (text, parsed JSON, size). It also explains the two-step x402 request flow, leaving little an agent needs to call it correctly.

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

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

Schema coverage is 100% with a single 'key' parameter fully documented by pattern and length. The description adds no syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb+resource (retrieve a value stored earlier) and explicitly ties it to the sibling /kv/put that created it, so an agent can distinguish it from kv_list and kv_put without opening schemas.

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

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

Gives a clear when-to-use condition ('needs a value it stored earlier with /kv/put'). It does not name explicit alternatives or exclusions, but the pairing with kv_put and kv_list makes selection reasonably inferable.

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 pricing model ($0.001 per call), the exact endpoint and method (GET /kv/list), the fact that it returns the paid x402/MPP request rather than the data itself, and that invalid input is refused before any charge.

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 use case, then packs scope, cost, and next-step mechanics into two tight sentences 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?

With no output schema, the description still explains what the call returns (the paid request, response schema, and an example) and how to complete it, leaving nothing an agent needs unstated.

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

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

Schema coverage is 100%, so the schema already documents limit, cursor and prefix; the description only restates the 100-key ceiling and the optional prefix filter, adding no syntax or edge-case detail. Baseline 3 applies when the schema carries the weight.

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 ('lists up to 100 keys ... in the namespace of the paying wallet') plus the returned fields (size, stored_at, expires_at), which distinguishes it from kv_get and kv_put without needing to name them.

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

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

'Use when an agent needs to see what it has stored' gives an explicit triggering condition, and the payment note implies it is a paid discovery step before actual retrieval. Sibling alternatives such as kv_get are not named, 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?

Annotations declare readOnlyHint=true on a 'put', which would otherwise look contradictory; the description resolves this by explaining the tool returns the exact paid x402 request body for the caller to POST, so no write happens here. It also discloses the $0.001 price, the 8 KB value cap, the endpoint, and that bad input is refused before any charge.

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 usage trigger is front-loaded and each clause carries information (storage scope, size cap, price, endpoint, no-charge-on-error). It is dense and multi-clause, 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?

With no output schema, the description compensates by stating exactly what is returned (the paid x402 request plus response schema and example) and how to complete the call. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so key, value, and ttl are already fully documented with pattern, bounds, and default. The description only restates the 8 KB value cap and adds no TTL or key-format detail beyond the schema, so baseline 3 applies.

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

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

The description states a specific verb and resource ('store value ... under key in a private namespace keyed to the wallet that pays') and scopes it as agent memory between runs. This clearly separates it from the kv_get and kv_list siblings, which read the same namespace.

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 when an agent needs memory between runs without an account' gives an explicit triggering condition, and the payment flow tells the agent exactly when this tool is and isn't the final step (it returns a request body to POST, not the data). It does not name kv_get/kv_list as alternatives 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 already declare read-only, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful non-annotation context: the data is paid per call over x402 or MPP, and each entry carries route, USD price, parameters and an example request URL.

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 purpose and scope rule are front-loaded in the opening and closing clauses. The long parenthetical enumerating every product category is heavy but does usefully delimit what counts as a 'paid data product' on this host.

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 describing the returned fields (route, price, parameters, example URL). Combined with annotations covering the safety profile and a trivial 0-required-param schema, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single 'route' parameter is fully documented in the schema, so the baseline is 3. The description mentions 'route' as a returned field but adds no filtering syntax or meaning beyond the schema's own example.

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 ('List the paid data products on this host') and scopes it explicitly to this host's own tools. It is immediately distinguishable from the sibling search_x402_services, which it names as the third-party alternative.

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

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

It gives an explicit routing rule: use this for THIS host's paid tools, and use search_x402_services to find third-party APIs. The when-to-use condition is stated rather than left to inference.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds substantial non-obvious behavior: a two-mode contract (return the raw x402 request to call yourself vs. execute the paid call with a P0 key), explicit pricing ($0.002/call), input validation before any charge, and the exact auth header/prefix plus a key-purchase URL. That is exactly the kind of cost and auth disclosure 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?

Front-loaded with the use condition, then payment mechanics, validation guarantee, and auth path — each sentence carries information an agent needs. It runs long for a single paragraph and the embedded key-purchase URL is bulky, 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?

With no output schema, the description must convey the return shape, and it does: headlines with links and dates, plus the honest caveat that the default response is a request/schema/example payload rather than data. The only gap is the '11 topics' vs. 13-enum mismatch and no mention of pagination or result ordering.

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 hours, limit, topic enum, and q precedence are already documented in structured fields, making 3 the baseline. The description adds little beyond restating 'your own q=' for topic selection, and its claim of '11 topics' conflicts with the 13-value enum in the schema, which slightly muddies rather than clarifies 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?

States a specific verb and resource up front ('Use when an agent needs recent headlines with links and dates') and scopes the content precisely: crypto/AI news via the GDELT index, 11 topics or a custom q=, plus US agency press releases. This is clearly distinguishable from siblings like sec_filings or domain_report 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 clause gives a clear use condition (need for recent headlines with links and dates) and the source lineage (GDELT index, US government sources for us-agencies/federal-register). It stops short of naming alternatives or exclusions, so an agent is not told when to prefer sec_filings or another news-adjacent sibling instead.

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

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

Annotations only cover safety (readOnly/idempotent/openWorld); the description adds the crucial two-mode behavior: it returns a paid x402 request URL by default, but with a P0 bearer key it executes the paid call itself and deducts the price, plus that bad input is refused before any charge and pricing is $0.005/call. These are exactly the traits an agent cannot infer from the schema or 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?

Purpose and routing come first, then pricing/behavior, then alternatives and the key mode — a sensible front-loaded order with no filler. It is dense and the long key-purchase URL clutters an otherwise tight paragraph, costing a point.

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 covers what comes back (the exact paid request, response schema and example; or the data itself with a key) and the cost/no-charge-on-bad-input guarantees. It leaves the shape of a successful screening result (hit list fields, score meaning) to the referenced schema rather than describing it, so it is complete enough but not fully self-contained.

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 names, limits, ranges and the name/address either-or are already documented. The description restates the address-or-name choice but says nothing about limit or min_score, so it adds no meaning beyond the schema; 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 ('screen a wallet address or a person/company name against sanctions lists') and names the exact list coverage (OFAC SDN, UK, EU, Canada, US CSL). It explicitly distinguishes itself from sibling tools wallet_risk, token_risk and sanctions_screening_batch.

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 paying or trading'), names the alternative tools with their respective scopes, and routes batch use to sanctions_screening_batch. When-not-to-use is implied by 'Sanctions lists only' versus the broader risk-label siblings.

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 pricing ($0.125 per call), the x402/MPP payment handshake, that validation happens before any charge, and that a P0 bearer key switches the tool to making the paid call itself. That is unusually rich behavioral context for a readOnly/idempotent tool. Minor gap: it does not say what happens on partial match results or what the per-call charge is when screening fewer than 25 addresses.

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 usage trigger, then the mechanics and pricing, then the sibling routing – good ordering. It is a single dense paragraph with a long embedded key-purchase URL that slightly hurts scannability, 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?

With no output schema, the description still explains what comes back ('the exact paid x402 request…with the response schema and an example') and how to complete the call. Combined with the single fully documented parameter, an agent has everything needed to invoke it correctly in either payment mode.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is 3; the description nonetheless adds meaning by naming accepted chain formats and reiterating that names are rejected. It does not add format details (e.g. checksum/case requirements) 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 ('screen a list of wallet addresses against sanctions lists') plus concrete scope ('up to 25 per POST', supported chains 0x/BTC/TRX/SOL). It explicitly names the sibling it is not, sanctions_screening, so an agent can select between them without opening either schema.

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

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

Opens with an explicit trigger ('Use when you need to screen a list...in one call') and gives the exclusion plus alternative routing: 'For one address or a name use sanctions_screening.' It also covers the P0 key branch, telling the agent which mode applies when.

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 the safety profile (readOnly, idempotent, open-world); the description adds the substantive behavior: the free tier caps results at the top 5, full results require the paid x402/MPP endpoint on the same host, and the calls/paying-wallets fields are currently null pending on-chain measurement. The data-quality caveat about null demand figures is exactly the kind of disclosure annotations cannot carry.

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

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

Front-loaded with the core verb and result-set composition, then limits, then exclusions — a sound ordering. Slight redundancy in "Calls and paying wallets are null for now: demand figures (calls and paying wallets over 30 days) return after...", which restates the same field names twice and could be one clause.

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 and does reasonably well by describing what each listing includes (price, networks, 402 evidence) and that demand metrics are null. It does not describe result ordering beyond "top 5" or empty-result behavior, which is a minor gap for a search tool.

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

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

Schema description coverage is 100%, with all three parameters (query, network as CAIP-2, include_testnets) documented in the schema itself. The description adds no extra semantics for any parameter, so the baseline 3 applies — it neither helps nor harms beyond structured data.

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 ("Search verified x402 sellers by capability") and immediately defines the result set: compiled from Agenstry, Open 402 and pay.sh, carrying price, networks and evidence of a live 402 challenge or manifest. That distinguishes it from best_service_for_task, x402_market_stats and list_paid_data_products without needing to open any schema.

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

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

Explicitly names three sibling alternatives and the condition that routes to each: best_service_for_task for picking one service for a concrete task, x402_market_stats for market-wide totals, list_paid_data_products for this host's own products. It also explains the free-tier vs paid /search endpoint relationship, so an agent knows both when to use this tool and what its limits are.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: pricing ($0.003/call), the fact that bad input is refused before any charge, the exact endpoint returned, and the access-key path with its own cost implication. No contradiction with 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 trigger and payload, and the payment mechanics are genuinely necessary given the x402 model. It is dense rather than padded, though the verbatim key-purchase URL and the recap of the exact GET path make it longer than strictly needed.

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 8 params and no output schema, the description does what's needed: it explains what the response contains, that a request payload with response schema and example is returned in the no-key path, and that with a key the data itself comes back. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema; baseline is 3. The description echoes a few of them ('filter by form, since', 'XBRL facts: revenue') but adds no syntax, defaults, or interaction detail beyond what the schema states, and says nothing about limit/periods/quarters.

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 US public company's SEC EDGAR filings and key financials by ticker or CIK'), enumerates the payload (latest filings with form/date/accession/link, plus XBRL revenue facts), and names the sibling sec_filings_batch for the multi-company case. An agent can distinguish it from siblings without opening any schema.

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

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

Opens with an explicit trigger ('Use when you need...'), routes multi-company queries to sec_filings_batch, and spells out the two invocation paths: no key → receive the paid x402 request and call it yourself; P0 key → the tool executes the paid call and returns data. Clear when to use and which alternative applies.

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 read-only/idempotent safety, yet the description discloses the non-obvious behavior that matters most: by default the tool returns a payable x402 request envelope (endpoint, price, response schema, example) rather than the filings themselves, and only with a P0 Bearer key does it execute the paid call. Pricing ($0.03/call) and pre-charge validation are stated. It stops short of describing pagination or how the response envelope should be interpreted step by step.

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 use case and scope, then the return contract, then the key option — a sensible order with little waste. The inline key-purchase URL with a long hostname is visually noisy, though it is genuinely needed 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?

A dual-mode tool (request-envelope vs self-executing with a key) with no output schema; the description covers both modes, the cost, the auth header form, and the input bound. An agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100%, so every parameter (form, facts, limit, since, companies) is already documented and the description adds nothing beyond "up to 10 tickers or CIKs," which the schema also carries. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource (recent SEC EDGAR filings for US public companies), the batching scope (up to 10 tickers or CIKs in one POST), and explicitly names the single-company sibling sec_filings. The distinction is legible without opening either schema.

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

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

"Use when you need... several US public companies at once" gives the positive trigger, and "For one company use sec_filings" gives the alternative and the condition that selects it. It also warns that invalid input is refused before any charge, so the agent knows retries are free.

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

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

With annotations already declaring readOnlyHint, idempotentHint, and destructiveHint=false, the description adds substantive context: no money is moved, support is voluntary and non-refundable, and funds go to engineering. The only weakness is the ambiguous phrase 'returns no data', which sits oddly next to the promised information.

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

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

The first sentence is appropriately front-loaded and the safety constraint follows, but the text contains marketing fluff ('your support will be highly appreciated!') and redundant restatements ('Read-only; it moves no money' / 'Information only: it buys nothing and returns no data'). It could be tightened 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?

For a simple no-parameter info tool with annotations covering the safety profile, the description largely covers what information is offered. However, 'returns no data' is confusing for an information endpoint, and it does not clarify the output shape beyond listing broad categories, leaving a small completeness gap.

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

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

The tool takes no parameters (schema coverage 100%), so there is nothing for the description to document; the baseline for zero-parameter tools is 4. No parameter meaning is missing.

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?

Clearly identifies itself as the information endpoint for optionally supporting P0, naming the donation/sponsorship pages, per-network payment addresses, and receipt-claim instructions. This makes it distinguishable from all data-product and blockchain siblings, though the opening 'Information about' is a weaker verb than an explicit 'Get/List'.

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

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

Conveys that the tool is for voluntary, non-refundable support information, which implies when a user might ask about donating. It does not give an explicit when-to-use rule or mention any alternative, so usage is inferred 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?

Annotations cover read-only/idempotent/open-world, but the description adds substantial context beyond them: it discloses the x402 paid-call model, the $0.01 per-call price, that bad input is refused before any charge, and how the P0 access key path works (deducting the listed price). This is rich operational disclosure an agent needs to invoke correctly.

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

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

Purpose and scope are front-loaded, and nearly every clause adds real value (risk dimensions, cost, auth, fallback sibling). It is dense and somewhat run-on, but the information density justifies most of the length.

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

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

For a payment-gated tool with no output schema and full param coverage, the description covers everything an agent needs: the paid-request flow, the exact GET endpoint and price, that a response schema and example are returned, error/no-charge behavior, and the access-key variant.

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 for chain is documented, so the schema already carries the parameter semantics. The description references 'your input' and the request URL but adds no per-parameter detail beyond the schema, 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 ('rule-based risk label on an ERC-20 token') and enumerates the risk dimensions covered (OFAC SDN match, upgradeable proxy, owner with mint/pause/blacklist, issuer-listed examples). It also explicitly distinguishes itself from the sibling wallet_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?

Gives a clear when-to-use trigger ('before you accept or route it') and names the alternative explicitly ('For a wallet (not a token contract) use wallet_risk'), which lets an agent route correctly without inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description still adds substantial behavioral context: the exact paid endpoint (GET /v1/uptime/ping), price ($0.01 per call), that invalid input is rejected pre-charge, and the P0 key path where the tool performs the paid call itself and deducts the listed price. It does not state timeout behavior or what a 'down' result looks like, which keeps it off 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?

Well front-loaded: trigger first, then mechanism, then the x402/key branches. It is dense but nearly every clause carries decision-relevant information; the long key-purchase URL is the one element that inflates length without aiding tool selection.

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

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

There is no output schema, and the description compensates by explaining what is returned in both modes: the exact paid x402 request with response schema and example, or the actual data when a P0 key is supplied. For a one-parameter, read-only check tool, 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?

With a single parameter at 100% schema coverage, the schema already documents the URL format, length cap, example, and allowed ports. The description adds only an implicit constraint ('Bad input is refused') without defining what counts as bad input, 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 ('know if a URL is up right now') with concrete synonyms (uptime ping, health check, link check) and the exact mechanism (one HEAD request from a Cloudflare edge, GET fallback on 4xx/5xx, up to 4 redirects). It also names the sibling it is not ('For several URLs use url_uptime_ping_batch'), so an agent can distinguish it 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?

Opens with an explicit invocation trigger ('Use when you need to know if a URL is up right now') and names the alternative with the condition that selects it ('For several URLs use url_uptime_ping_batch'). It additionally states input refusal occurs before any charge, removing a common hesitation about calling 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?

Beyond the readOnly/idempotent annotations, it discloses the pricing model ($0.10 per call), that the default return value is an unsigned x402 request payload rather than data, and that passing a P0 key switches the tool to executing the paid call itself with a price deduction. The charge-on-execute behavior is a side effect an agent must know about, and it is stated plainly.

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 trigger condition and the sibling alternative are front-loaded, and every clause adds operational detail (limits, cost, payload return, key mode). The single dense paragraph, including the long key-purchase URL, makes it harder to scan than a segmented version would be.

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

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

With no output schema, the description compensates by explaining both possible return shapes (a signed x402 request object containing a schema and example, or direct data when a P0 key is supplied) and what each URL check reports. Nothing needed to call it correctly or interpret the result is missing.

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

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

Schema coverage is 100% and the schema already documents the 1–10 item bounds and duplicate removal, so the schema does the heavy lifting. The description still adds value by constraining entries to http(s) URLs and framing the array as a single batched POST.

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 (ping up to 10 http(s) URLs in one POST) and pins the per-URL semantics by referencing /v1/uptime/ping (status, latency, redirects, TLS, server). It explicitly distinguishes itself from the sibling url_uptime_ping by naming the single-URL case.

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 when you monitor several endpoints" gives the selection condition, and "For one URL use url_uptime_ping" names the alternative with its trigger. It also flags the validation behavior (bad input refused before charge) and the two execution modes, so an agent knows which path it is on.

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

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

Goes well past the annotations (readOnly/idempotent/openWorld) by disclosing the 64 KB input ceiling, that encoding is local with 'no external call', the $0.001 per-call price, and that bad input is refused before any charge. It also spells out the auth prerequisite (Authorization: Bearer p0k_… plus where to buy a key) and how behavior changes when that key is absent.

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 trigger condition is front-loaded and the pricing/auth detail follows in a logical order; nearly every clause carries operational information. It is a single dense paragraph with an embedded key-purchase URL, so it is heavier than ideal but not padded with 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 still explains what comes back in each mode — a ready-to-send x402 request with response schema and example, versus the decoded/encoded data when authenticated. Combined with limits, pricing, and pre-charge validation, an agent has what it needs, though the exact response shape is only described, not exemplified.

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 each of the three parameters is already documented in the schema, so the baseline applies. The description adds only the 64 KB limit (matching maxLength) and the decode-to-hex behavior; it introduces no additional parameter syntax or format 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 and resource ('encode UTF-8 text to base64 ... or decode base64 back to text'), including supported alphabets and the hex fallback for non-UTF-8 bytes. It is unmistakable against neighbors like util_hash or util_jwt_decode 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?

Opens with an explicit trigger ('Use when you need base64 in or out') and explains the two operating modes: build a paid request to hand to an x402/MPP client, or have the tool execute it directly when a P0 key is present. It does not name an alternative sibling or state when not to use it, which keeps it off 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?

Well beyond the annotations: it discloses cost ($0.001 per call), that bad input is refused before any charge, that the default behavior performs no external call and instead returns a ready-to-execute x402 request, and that supplying a Bearer p0k_ key causes the tool to make the paid call and deduct the price. These are exactly the operational facts an agent needs and none are in the structured fields.

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

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

The trigger is front-loaded correctly, but the body is a dense run-on that mixes three distinct concerns (hashing parameters, payment mechanics, key purchase URL) into one sentence chain. The key-buy URL and purchase instructions are verbose relative to their decision weight.

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 and mostly does: it explains that the default path returns an x402 request plus response schema and example, while the keyed path returns the digest itself. The dual return mode is slightly ambiguous about which shape you get, keeping it from a 5.

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

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

Schema coverage is 100%, so the schema already documents algo, text, and encoding including defaults and the enum. The description adds only the 64 KB size limit and the notion of hex digests as output, which is minimal marginal value over 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?

Opens with a specific verb and resource: compute a checksum/digest of a string, and enumerates supported algorithms (sha256 default, sha1, sha384, sha512, md5) and input encodings. This clearly separates it from sibling util_* tools like util_base64 or util_jwt_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?

"Use when you need a checksum or digest of a string" gives an explicit trigger condition, and the flow states when the paid-call path applies (P0 access key present) versus when you only get the x402 request to execute yourself. It does not explicitly name a competing sibling or state when not to use it, so it stops 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 declare readOnly/idempotent/non-destructive, yet the description still adds substantial context: exact price ($0.001 per call), the endpoint path, the fact that invalid input is rejected before charging, the required auth header format, and where to obtain a key. This is exactly the cost/auth/charge-semantics 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?

The usage trigger is front-loaded and each sentence carries distinct information (purpose, return shape, price, failure behavior, auth mode). The long key-purchase URL is necessary but makes the single dense paragraph harder to scan than a short bulleted structure would be.

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

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

With no params and no output schema, the description fully carries the burden: it explains what is returned (IP plus geo/ASN fields), that a response schema and example accompany the request, the cost, and both execution modes. 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?

Zero parameters, so the baseline is 4; the schema is trivially complete and requires no description support. 'Returns the exact paid x402 request for your input' is slightly loose phrasing for a parameterless tool but does not mislead.

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 capability: returns the caller's public IP plus country, region, city, ASN and AS organization. The resource is unique among siblings (util_hash, util_base64, etc. are unrelated utilities), so no explicit sibling disambiguation is needed. It does not name an alternative, keeping it just below 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?

Opens with an explicit trigger: 'Use when an agent needs to know how it is seen from outside.' It also distinguishes the two invocation modes — without a key you get a callable x402 request template, with a P0 key the tool performs the paid call itself. No when-not-to-use guidance or sibling exclusions 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?

Goes well beyond the annotations by disclosing price ($0.001 per call), the endpoint (GET /util/json-validate), the payment protocols accepted (x402/MPP), that bad input is refused before any charge, and the exact auth header format and key purchase URL for direct execution. Nothing contradicts the readOnly/idempotent/non-destructive 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 trigger condition, then the mechanics. Sentences are dense but each carries information; the payment/key paragraph is long but operationally necessary. Minor redundancy in 'call that URL with an x402 or MPP client to get the data' following the prior sentence.

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

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

With no output schema, the description shoulders the return-value burden: it explains the response schema and example come back with the paid request, or that the data is returned directly with a P0 key. However it never says what a validation result actually looks like (valid flag, error list), leaving a gap for a two-parameter tool whose whole output is that verdict.

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 `json` and `schema` are already documented in the schema. The description restates the domain ('json document', 'schema') but adds no format or size guidance beyond structured fields, so baseline 3 applies.

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

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

States a specific verb and resource ('validates json against a JSON Schema subset') and frames it with a concrete decision point ('check that a JSON document fits a schema before acting on it'). This clearly separates it from the other util_* siblings such as util_base64 or util_jwt_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?

'Use when you must check that a JSON document fits a schema before acting on it' gives an explicit triggering condition. It also explains the two invocation modes (raw x402/MPP request vs. P0 key), though it does not state when NOT to use it or contrast with siblings.

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 declare readOnlyHint=true and idempotentHint=true, but the description says each call costs $0.001 and that with a P0 key the tool 'makes the paid call itself' while 'deducting the listed price.' Charging is an environmental side effect and repeated calls incur repeated charges, so the description contradicts the read-only and idempotent annotations.

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

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

The description front-loads the usage condition and keeps the operational details together. It is somewhat dense and includes a full key-purchase URL, but the added length is largely justified by the dual-mode payment behavior.

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 explains the decoded return fields, the no-key request-descriptor behavior, the paid-call behavior with a P0 key, and that bad input is rejected before charging. That is sufficient for an agent to understand what comes back and what the call costs.

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 one parameter, token, and schema description coverage is 100% with 'JWT header.payload.signature.' The description explains what is decoded from the token but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: inspect/decode a JWT without a key, returning header, payload, alg, kid, timestamps, and expiry status. This is clear enough to distinguish it from general utilities like util_base64 or util_hash.

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 explicitly says when to use the tool: when you need to inspect a JWT without a key. It also explains the two invocation modes, with an x402/MPP client or via a P0 access key, but it does not name alternatives or when-not-to-use 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?

Annotations already cover safety (readOnly, non-destructive), and the description adds substantial unstated context: edge crypto randomness, sub-100ms latency, $0.001 pricing, validation-before-charge, and the P0-key flow that makes the paid call itself. What's missing is the concrete shape of returned data (e.g., a list of strings) in key mode, which matters since there is no output schema.

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

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

The trigger phrase is correctly front-loaded and every clause carries real information (latency, price, auth, validation). It is dense and reads as an extended run-on, but trimming would lose payment-mechanics details an agent needs to choose a mode.

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 output schema, it covers the important unknowns: what is returned in each mode, the endpoint and price, how to authenticate, and that bad input is rejected pre-charge. The only gap is the absence of a concrete return-value shape for the key-authorized path.

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. The description's "n (1-100)" and "v4 random / v7 time-sortable" essentially restate what the schema already documents, adding only slight semantic framing for when v7's sortability matters.

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 plus scope: generate 1-100 v4 (random) or v7 (time-sortable) UUIDs. That is immediately distinguishable from siblings like util_hash and util_base64, which produce different artifacts.

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 when you need fresh UUIDs" gives clear triggering context, and the two operating modes (request-template vs. P0-key direct call) are spelled out. It stops short of explicitly naming alternatives or when-not-to-use conditions, but the use case is narrow enough that the 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: pay-per-call pricing ($0.003), that the return value is a paid x402 request URL with schema and example, that invalid input is rejected before charging, and that a P0 key makes it auto-pay and deduct. That is meaningful added disclosure for a paid read, though it says nothing about latency, pagination or freshness of balances.

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 use condition, then scope, then routing alternatives, then payment mechanics — a sensible ordering. It is dense but every clause carries information; only the long key-purchase URL is mildly noisy, and the payment explanation runs a bit long.

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 with no output schema, the description covers what is returned (an x402 request URL plus response schema and example), the cost, the error/charge behavior, and the auth upgrade path. Combined with annotations that carry the safety profile, an agent has everything needed to call and consume 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 are documented there (chains as a comma list with default of all EVM chains, address as 0x or ENS). The description's only added signal is the enumeration of supported chains and tokens, which is useful scoping but does not enrich the parameter syntax or format beyond the schema. 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 (wallet token balances) plus scope: multiple chains, one wallet, with an explicit token list (native, USDC, USDT, DAI, WETH, WBTC/cbBTC). It names the exact siblings it is not (evm_erc20_balance, evm_native_balance, wallet_balance_batch), so an agent can route without opening any schema.

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

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

Opens with an explicit when-to-use condition (several chains in one call) and enumerates the alternatives with their selecting conditions: one token/one chain -> evm_erc20_balance, native/one chain -> evm_native_balance, many wallets -> wallet_balance_batch. Nothing is left to inference.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the cost ($0.075 per call), the charge-protection rule ('bad input is refused before any charge'), the required auth header (Authorization: Bearer p0k_…), where to buy a key, and that the default return value is a request spec rather than data. For a paid, open-world tool this is exactly the missing context annotations cannot carry.

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

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

Front-loaded with the trigger and scope, then pricing, then the two modes — a sensible order. Slightly over-packed (price restated as both '$0.075 per call' and 'deducting the listed price', plus a long key-purchase URL inline) which costs a bit of scanability.

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 tells the agent what comes back in each mode (an x402 POST body with response schema and example, or the actual data with a key) and covers payment, auth, and input limits. It never sketches the shape of the balance payload beyond 'native and stablecoin balances', which is a minor gap for a tool with no output schema.

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

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

Schema coverage is 100%, so addresses (1-25, duplicates removed) and chains are already documented; the description only adds that entries may be 0x addresses or ENS names, which the schema omits. The 'chains' parameter is not mentioned in the description at all, so value added over the schema is marginal and the baseline 3 applies.

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

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

States a specific verb and resource ('native and stablecoin balances for a list of wallets') plus hard scope ('up to 25 addresses ... in one POST'). It also explicitly contrasts with sibling wallet_balance ('For one wallet use wallet_balance'), so the agent can pick between them without inspecting schemas.

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

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

Opens with an explicit 'Use when you need...' trigger, names the alternative (wallet_balance) for the single-wallet case, and explains the two invocation modes: default returns an x402 request to POST yourself, or with a P0 access key the tool performs the paid call. Nothing about when-to-use is left implicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on substantive extra behavior: per-call cost ($0.01), the x402/MPP client flow, the fact that bad input is refused before any charge, and how a P0 access key changes the tool into a self-executing paid call. The dual-mode return (request template vs. actual data) is disclosed but densely packed, which keeps this just 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?

The purpose and alternatives are front-loaded, which is good, but the single long sentence chain mixes pricing, endpoint, return shape, sibling routing, and access-key auth into one run-on block. Much of it earns its place, yet the access-key/purchase-URL detail could be split or moved later for readability.

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

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

With no output schema, the description carries the burden of explaining returns, and it does: the exact paid x402 request for the input, response schema plus example, or the data itself under a P0 key. Payment and error semantics are covered; only the exact shape of the returned risk label is left implicit.

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 both the address pattern and the idempotency request_key. The description adds nothing further about parameters, so the baseline 3 applies.

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

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

States a specific verb+resource: a rule-based risk label on an EVM address, and enumerates exactly what the label covers (OFAC SDN match, contract vs plain account, outgoing tx count) with chains. It explicitly distinguishes itself from sibling tools token_risk and sanctions_screening_batch, so an agent can route correctly without opening other schemas.

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

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

Gives an explicit use condition ('before paying it') and names the alternatives with the disambiguating conditions: token_risk for ERC-20 tokens, sanctions_screening_batch for OFAC-only bulk checks. Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already declare readOnly/idempotent/destructive-free, so the description's added value is the source and licensing behavior: data comes from x402stats, is CC BY 4.0, and must be attributed in the answer. It also discloses the 30-day window and that only verified sellers are counted, which affects interpretation of results.

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

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

Two sentences, zero filler: the first defines the content and scope, the second handles routing and attribution constraints. The scoping statement is front-loaded rather than buried.

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 parameters and no output schema, the description carries the job of telling the agent what comes back, and it does so at a summary level (seller counts/median price/market totals) plus the attribution obligation. It stops short of describing the response shape or any snapshot freshness beyond the 30-day window.

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 and there is nothing for the description to compensate for. The description's framing of what the parameterless call returns is appropriate.

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

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

The description names the specific resource and its contents: seller-set statistics (sellers by source and evidence, median declared price) plus 30-day market totals. It also explicitly distinguishes itself from search_x402_services, so an agent can route without opening either schema.

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

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

"Market-wide totals only; for individual services use search_x402_services" gives an explicit scope limit and names the alternative tool for the out-of-scope case. No prerequisites or auth requirements are mentioned, which keeps it just 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world); the description adds genuinely new behavioral facts: the endpoint (GET /x402/test), the price ($0.001 per call), that it returns the request plus response schema and an example, and that invalid input is refused before any charge. These do not conflict with readOnlyHint, since payment occurs when the agent calls the returned URL with its own x402 client, not through this 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 usage trigger, which is good, but the opening clause is redundant with itself ('Use when you test an x402 or MPP client ... a test target for x402/MPP clients') and the middle sentence stacks endpoint, price, return contents, and a follow-up instruction into one dense clause chain.

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

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

No output schema exists, and the description compensates by explaining what comes back (the exact paid request, response schema, and an example) and how to consume it. With annotations covering safety and validation/disclosure covered for both params, the only residual ambiguity is whether the $0.001 applies to this call or to the returned endpoint.

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

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

Schema description coverage is 100%, so both parameters ('dry' and 'msg') are already fully documented in the schema, including the echo.query behavior and the free dry-run rails list. The description adds only generic 'for your input' phrasing and a validation note ('bad input is refused before any charge'), which is baseline 3 territory.

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 role ('a test target for x402/MPP clients') and a concrete output ('returns the exact paid x402 request for your input'), which an agent can distinguish from the real-purchase siblings like buy_brandwatch or buy_lead_list. It stops short of naming any sibling explicitly, so differentiation is inferential rather than stated.

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

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

Gives an explicit when-to-use: testing an x402/MPP client, wallet, SDK, facilitator, or CI, and 'use it in your integration tests'. It does not state the inverse (e.g., 'do not use for real production purchases'), but the test-scoped framing makes misuse unlikely.

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