x402 Bazaar Rank

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

Beyond the readOnly/idempotent annotations, it discloses price ($0.01 per call), failure behavior (bad input refused before any charge), the shape of the return (response schema and example), and the required follow-up step (call the returned URL with an x402 or MPP client). That is exactly the extra context annotations cannot convey.

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

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

The usage trigger and return behavior are front-loaded, and each clause carries information (cost, refusal semantics, follow-up call, sibling routing). The opening sentence is a bit run-on with its embedded colon clause, but nothing is redundant 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 (the paid x402 request, its schema, and an example) and what the caller must do next. For a one-parameter router tool, nothing an agent needs in order 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?

There is a single parameter with 100% schema description coverage, including a concrete example and the 2-200 character bound, so the schema carries the load. The description only restates the same idea ('send the task in plain words') without adding format, phrasing, or constraint detail beyond the schema.

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

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

The description names a specific action (pick which paid x402 service to send a task to) and a specific resource (x402 service / route), and distinguishes itself from the sibling search_x402_services. An agent can tell what it produces (the exact paid x402 request) 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?

It gives an explicit trigger (a router agent must pick a service), an explicit input mode (send the task in plain words), and names the alternative for a different need: browse or compare services via search_x402_services. The when-not is spelled out, not inferred.

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

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

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

Goes well beyond the annotations by disclosing price ($390 USDC/USDT), that bad input is refused before any charge, the existence of a free check endpoint with an email requirement, and the x402/MPP client flow. This is meaningful side-effect and cost context for a payment tool, though it does not clarify reconciliation or what happens on partial payment.

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

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

Purpose and price are front-loaded, which is good, but the $390 / one-payment phrasing is repeated twice and the URL and method are restated parenthetically. It is denser than it needs to be for the amount of distinct information conveyed.

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 payable tool with no output schema, the description adequately explains the request/response handoff and the free-check fallback. However, with 6 parameters at 33% schema coverage and no output schema, the input contract is left under-explained.

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

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

Schema description coverage is only 33%, so the description should compensate, but it only obliquely references 'your input' and the email requirement for the check step. Required fields (company, domain, category_keywords) and their constraints are left entirely to the schema, adding little semantic value.

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

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

Names a specific verb and resource ('buy', 'market report') and states the concrete price and payment rail, which distinguishes it from data-returning siblings like domain_report or buy_lead_list. Slight ambiguity remains about whether the call itself charges or merely returns a request payload to POST.

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

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

Explains the intended workflow (buy via x402/MPP, POST the returned body) and points to a free pre-check endpoint, which is useful routing guidance. It never states when to prefer this over sibling purchase tools such as buy_lead_list or domain_report, so usage is implied rather than comparative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds non-obvious operational detail the annotations do not carry: the tool returns a paid x402 request URL (GET /v1/email/verify at $0.01 per call) that must be called with an x402 or MPP client, and that bad input is refused before any charge. Pricing, payment protocol, and the no-charge-on-invalid-input guarantee are exactly the kind of context an agent needs.

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 every clause carries information, but the middle sentence packs payment URL, price, return payload, and client requirement into one dense run-on. Slightly tighter segmentation would improve scanning 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?

Despite having no output schema, the description tells the agent what it gets back (the exact x402 request, response schema, and an example) and how to obtain the actual data. For a single-parameter, annotation-covered read 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?

Schema coverage is 100% and the single 'email' parameter is documented in the schema, so the baseline is 3. The description adds meaningful constraint beyond that: the check is IDN-aware and scoped to one mailbox (not a list), which clarifies the accepted input shape. The gain is modest rather than rich, so 4 rather than 5.

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

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

States a specific verb+resource ('check an email address') and enumerates exactly what is checked: IDN-aware syntax, MX with A/AAAA fallback, null MX, disposable and role addresses. It also explicitly names what it is not ('Checks one mailbox; for a list use check_email_batch; for a whole domain use domain_report'), so an agent can separate 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?

Gives an explicit triggering context ('before sending, signing up a user or adding a lead') and routes to alternatives for both adjacent cases: check_email_batch for lists and domain_report for whole-domain DNS/SPF/DMARC. When-to-use and when-to-use-something-else are both 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 already declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious context: this tool does not perform the check itself, it returns a paid x402/MPP request body (POST /v1/email/verify/batch) with the response schema and an example, priced at $0.25 per call, and bad input is refused before any charge. That is exactly the kind of behavioral disclosure 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 usage trigger and the sibling routing, and every clause carries information. The middle sentence is dense with semicolon-joined clauses about the payment flow, which slightly burdens scanning but remains informative rather than redundant.

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

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

For a payment-request-returning tool with no output schema, the description fully explains what is returned (the request body, response schema, example), what the agent must do next (POST with an x402/MPP client), the cost, and the validation guarantee. 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% and there is only one parameter, so the schema already documents items, maxLength, maxItems (25) and duplicate removal. The description reiterates 'up to 25 addresses' but adds no syntax or format detail 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 (check) and resource (email batch) with explicit scope (up to 25 addresses in one POST) and names the sibling it is not ('For one address use check_email_address'). An agent can distinguish it from check_email_address 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 an explicit trigger ('before a mailing or import'), an explicit limit (up to 25), and an explicit alternative with the selecting condition ('For one address use check_email_address'). When-not guidance is effectively covered by routing the single-address case elsewhere.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive) but the description adds substantial non-obvious behavior: it is a paid x402 call at $0.005, it returns the x402 request rather than the data itself, the caller must supply an x402 or MPP client, and bad input is refused before any charge. This is exactly the kind of cost/payment/refusal context annotations cannot convey.

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

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

Front-loaded with the usage trigger, then contents, then the critical payment/return mechanic, then sibling routing. Dense but every clause carries decision-relevant information; 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 must explain what comes back, and it does: the exact paid x402 request (GET /domain/report, $0.005 per call) plus response schema and example, to be replayed with an x402/MPP client. An agent has everything needed to invoke it correctly and understand the two-step flow.

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

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

Schema description coverage is 100%, so the domain parameter, its URL-accepted behavior, and its refusal of IP/private names are already fully documented in the schema. The description adds no additional syntax or format detail beyond noting valid input is required, so the baseline 3 is appropriate.

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

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

The description states a specific resource and scope: 'one report on a domain' enumerating DNS records (A, AAAA, MX, NS, TXT, CAA) plus SPF/DMARC parsing and RDAP registration data. It explicitly differentiates from siblings by naming domain_report_batch and check_email_address, so an agent can pick it without opening any schema.

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

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

It gives a direct when-to-use trigger ('when you need one report on a domain') and routes to alternatives by condition: 'For several domains use domain_report_batch; for a single mailbox use check_email_address.' 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 read-only, idempotent, non-destructive, and open-world behavior. The description adds substantial operational context beyond that: it returns the exact paid x402 request, costs $0.05 per call, includes the response schema and an example, requires posting the returned JSON body with an x402 or MPP client, and refuses bad input before any charge. This is rich behavioral disclosure with no contradiction.

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

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

The description is front-loaded with the usage condition and alternative, then follows with the mechanics of payment and retrieval. It is appropriately sized for a paid batch tool with no output schema, though slightly dense; each sentence earns its place.

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

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

With no output schema, the description fills the gap by explaining that the response is the exact paid x402 request including schema and example, and that the caller must POST it to the given URL with an x402 or MPP client. Combined with annotations and full schema coverage, 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 description coverage is 100%, so the single parameter is fully documented in the schema itself. The description reinforces the batch limit ('up to 10 domains in one POST') and the close relationship to /domain/report, but does not add syntax or format detail beyond 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?

The description states a specific verb and resource (batch domain reports), scopes it to up to 10 domains in one POST, and explicitly distinguishes it from the single-domain sibling via 'For one domain use domain_report.' An agent can tell exactly what this tool does and when to choose it over 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?

It gives explicit when-to-use guidance ('when you must vet several domains at once') and an explicit alternative ('For one domain use domain_report'), plus the hard limit of 10 domains. No inference is needed to route between this and the single-domain 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 already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavior: the call itself does not return data but a paid x402 request (GET /evm/block, $0.001 per call) that must be redeemed with an x402 or MPP client, and bad input is refused before any charge. That second-call and billing behavior is exactly the kind of context annotations cannot convey.

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

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

One dense but well-ordered paragraph: purpose, returned fields, redemption mechanics, pricing, then error handling. Every sentence carries information, though the chain enumeration is redundant with the schema and could be trimmed.

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 well by explaining that the return is the exact paid request plus a response schema and example. An agent knows what it gets, what it costs, and the follow-up step needed; only the pagination/error envelope details are 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 both parameters are already documented, including the decimal/0x-hex format and the default. The description restates the five chains and 'latest or a given number', adding no syntax or constraints beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('a block header') and enumerates the exact chains and fields returned (hash, parent, timestamp, miner, gas used/limit). This cleanly distinguishes it from evm_transaction, evm_receipt, evm_code and evm_nonce 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 ('Use when you need a block header on Base, Ethereum...') and scopes the input to 'latest or a given number'. It gives clear context but never states when-not to use it or names an alternative sibling, so it stops short of the top tier.

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/openWorld, but the description adds substantial context beyond them: a per-call price ($0.002), that it returns a paid x402 request rather than the data itself, that an x402 or MPP client is required to complete the fetch, and that bad input is refused before any charge. The cost and payment-requirement disclosures are exactly the kind of behavioral detail annotations cannot express.

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

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

Front-loaded with the triggering condition, then outputs, then the payment mechanics. It is dense with no obvious filler, though the payment/client explanation makes it longer than a minimal definition would need.

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

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

There is no output schema, so the description carries the return-value burden, and it does: it lists the returned fields and explains the two-step x402 payment flow and the pre-charge validation. 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 description coverage is 100% and both parameters (address, chain enum) are fully documented in the schema, so baseline 3 applies. The description restates the chain list and implies the address input but adds no format or syntax beyond what the schema already carries.

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

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

States a specific verb+resource (check whether an address is a contract) and enumerates the exact outputs (is_contract, bytecode size, sha256 of bytecode) across five named chains. It is clearly distinguishable from siblings like evm_nonce, evm_erc20_balance, and evm_transaction, which cover different on-chain facts.

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 competing alternatives or when-not-to-use cases, so it stops short of a 5, but the context is clear.

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

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive). The description adds genuinely new behavior: it is a paid call ($0.002), returns an x402/MPP request rather than the data directly, and refuses bad input before charging. Rate limits and latency are not covered, keeping it from a 5.

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

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

Front-loaded with the when-to-use clause and the two lookup modes, and every sentence carries information. It is a dense single paragraph that could be segmented, but nothing is wasted.

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

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

For a paid, multi-step x402 tool with no output schema, the description explains the request URL, cost, response-schema availability, and validation behavior, which is everything an agent needs to invoke it correctly.

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

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

Schema coverage is 100% with both params described and patterned, so the schema already carries the semantics. The description restates the same examples (vitalik.eth, 0x...) and clarifies the two params are alternatives, adding only marginal value 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 operation on a specific resource (ENS resolution on Ethereum) and names both directions: name→address via the Universal Resolver and address→primary name via reverse record. No sibling overlaps with the evm_* family, and an agent can tell exactly what it does without opening the schema.

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

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

"Use when you need ENS on Ethereum" gives clear context, and it distinguishes the two input modes (name= for forward, address= for reverse). It stops short of naming when-not-to-use or an alternative tool for other chain data, so no exclusions are provided.

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 multicall batching behavior, the paid x402 request flow and cost ($0.002 per call), the endpoint, and that bad input is refused before any charge. These are exactly the non-obvious operational traits an agent needs and 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-loads purpose and scope, then payment mechanics, then the error guarantee, then the alternative. Dense but each sentence carries distinct information; only the pricing/URL sentence runs slightly 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?

With no output schema, the description still explains that the response includes the schema and an example, how to retrieve it (x402/MPP client), and the cost. For a paid data-proxy tool this covers 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 description coverage is 100% and the enum is documented, so the schema already carries parameter meaning. The description names the supported chains but adds no format or syntax detail beyond what the schema provides, making the baseline 3 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+scope: one ERC-20 balance for one wallet, reading balanceOf, decimals and symbol in a single multicall across five named chains. It also explicitly distinguishes itself from the sibling wallet_balance for multi-token/multi-chain needs.

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

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

Opens with the exact condition ('Use when you need one ERC-20 balance for one wallet') and closes with an explicit alternative and its trigger ('for several tokens or chains at once use wallet_balance'). When-to-use, when-not-to-use, and the alternative are all 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 already cover read-only/idempotent/non-destructive/open-world, but the description adds material context they cannot: the $0.001 per-call cost, the x402/MPP payment flow needed to retrieve data, and the failure policy ('Bad input is refused before any charge'). It also discloses the return shape (wei, decimal, block number, as_of).

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' condition and the sibling routing, which is what an agent needs first. The body is a dense, comma-chained run-on packing pricing, URL, response schema reference and client instructions into one sentence, so it is slightly overstuffed but every clause carries 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?

For a two-param read tool with no output schema, the description supplies the missing return detail (wei + decimal, block number, as_of) and the payment prerequisite. It is complete enough to call correctly, though the 'returns the paid x402 request' phrasing makes the two-step retrieval flow slightly ambiguous.

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

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

Schema description coverage is 100%, so baseline is 3. The description restates the chain enum and single-chain constraint but adds no format or syntax detail beyond what the schema already documents for address (pattern) and chain (enum + default).

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 ('native coin balance (ETH or POL) of an address') and the supported chains, and explicitly distinguishes itself from siblings by naming evm_erc20_balance's domain ('stablecoins') and wallet_balance ('several chains'). An agent can tell it apart from evm_erc20_balance and wallet_balance 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 'Use when you need...' and states the inverse condition explicitly: 'Native coin on one chain only; for stablecoins or several chains use wallet_balance.' Both the when-to-use and the alternative paths are named, leaving nothing to inference.

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

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

Beyond the annotations, it discloses that the tool does not return data directly but returns an exact paid x402 request (GET /evm/nonce) that must be called with an x402 or MPP client, adds pricing ($0.001 per call), and notes that bad input is refused before any charge. This is meaningful behavioral context about cost, indirection, and error handling that annotations do not cover.

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

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

The trigger is front-loaded and the content is dense but purposeful, with each clause carrying distinct information (scope, outputs, price, indirection, error handling). It is slightly lengthy in the second sentence but not wasteful.

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 exactly what is returned (the paid request plus response schema and example) and how to obtain the data. An agent has everything needed to invoke it correctly despite the two-step x402 pattern.

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 already documented in the schema. The description restates the chain names and the account concept but adds no format or syntax 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 resource (an account's nonce / transaction count) and two distinct outputs (nonce at latest block and pending nonce from the pool), and it enumerates the supported chains. This clearly distinguishes it from siblings like evm_transaction, evm_block, and wallet_balance.

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 opens with an explicit trigger ('Use when you need an account's transaction count'), giving a clear condition for selection. It stops short of naming an alternative or stating when NOT to use it, so it does not reach the 5 level.

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), so the bar is lower. The description adds real operational context beyond them: $0.002 per call, an x402/MPP payment flow, and that bad input is refused before any charge. It does not cover rate limits or pagination, so it stops short of a 5.

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

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

Front-loaded with the usage trigger and packed with concrete facts; every clause is informative. It is somewhat dense in the middle where the x402 payment mechanics are described, but nothing is wasted or repeated.

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

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

For a two-parameter read with no output schema, the description tells the agent what fields come back, what it costs, how the paid request is delivered, and where to look for the other fields. The remaining gap is that the unusual 'returns a paid request rather than the data' mechanism could be spelled out a little more plainly.

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 documents the five chains, so the schema already carries both parameters including the 0x+64 hex pattern and the default. The description only recaps the chain list and adds no format or semantics beyond the schema, which is the baseline-3 case.

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 whether a transaction succeeded'), enumerates the exact returned fields (status, block, confirmations, gas used, effective gas price), and explicitly routes the agent to evm_transaction for from/to/value/input. It is distinguishable from every evm_* sibling 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 trigger ('Use when you need to know whether a transaction succeeded'), then names the alternative and the condition that selects it ('for the transaction fields ... use evm_transaction'). When-to-use and the sibling boundary are both spelled out.

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 safe read-only profile, but the description goes well beyond: it discloses the paid x402 flow, the exact price ($0.002 per call), the refusal-before-charge safety guarantee, and the input truncation (first 1 KB). This is exactly the kind of 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 the resource, and every sentence carries information (fields, payment flow, truncation caveat, sibling routing). It is dense and slightly long, 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 naming the returned fields and clarifying that it returns the transaction itself, not its execution outcome. The payment mechanics and the evm_receipt handoff make the definition complete for correct invocation.

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

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

Schema coverage is 100%, so both the hash pattern and the chain enum are already fully documented in the schema. The description restates the chains and 'by hash' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('a transaction by hash') and enumerates the returnable fields and supported chains. It explicitly distinguishes itself from the sibling evm_receipt, 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?

Opens with an explicit trigger ('Use when you need a transaction by hash') and names the alternative with its selecting condition ('to know whether it succeeded... use evm_receipt'). 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 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?

Goes well beyond the annotations (which only cover read-only/idempotent/open-world safety): it discloses that the call is paid ($0.002 per call via x402), that this tool returns a request descriptor plus response schema and example rather than the data itself, and that invalid input is refused before any charge. Cost and billing-failure semantics are exactly the behavioral context an agent needs and structured fields don't carry.

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

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

Three tight sentences, front-loaded with the "Use when" trigger, followed by the return shape and the payment procedure. Every sentence contributes a distinct fact (purpose, protocol/cost, error behavior) with no 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?

There is no output schema, so the description compensates by explaining that the response is an x402 request (URL, price) accompanied by a response schema and example, and by telling the agent what to do next. With all four params documented in the schema, an agent has everything needed to invoke 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 description coverage is 100% — q, hours, limit, and topic all carry their own descriptions, defaults, and bounds, including the note that topic is ignored when q is given. The description only echoes the same numeric ranges in prose, adding no syntax or precedence 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 — retrieve the latest crypto/AI headlines — with concrete bounds (up to 50 English articles, 1-168 hour window, topic-scoped). It is unmistakable what the tool returns. It stops short of naming a sibling alternative (e.g. search_x402_services or list_paid_data_products) for discovery-style lookups.

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 the latest crypto or AI headlines" gives a clear triggering condition, and the follow-up explains the two-step flow: call this tool, then call the returned URL with an x402/MPP client. No explicit when-not guidance or sibling comparison is offered, which keeps it out of 5 territory.

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/openWorld/idempotent/non-destructive), but the description adds materially: the payment model ($0.005 per call via x402/MPP), the exact endpoint to call, and the key behavioral guarantee that 'Bad input is refused before any charge.' That is genuine disclosure beyond what structured fields provide, including the unusual two-step paid-request flow.

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 tight, information-dense; every clause carries routing, pricing, or constraint information. It is somewhat cramped with parentheticals and semicolon-chained clauses ('with the response schema and an example; call that URL...') that slightly burden reading, but no sentence is wasted.

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

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

No output schema exists, and the description compensates by explaining the return mechanism — an x402 request containing the response schema and an example — plus cost, input requirements, and failure behavior. An agent has everything needed to call this correctly and knows the alternatives.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying the matching semantics: addresses are screened by 'exact address match' while names use a similarity model (min_score/limit). This distinction between the two input modes is a real addition the schema only implies.

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 — screening a crypto address or a person/company name against the official OFAC SDN list — and pins the exact scope ('OFAC SDN match only', 'exact address match'). It explicitly distinguishes itself from wallet_risk, token_risk, and sanctions_screening_batch, so an agent can route correctly without opening any schema.

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

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

Gives an explicit trigger ('before paying or trading'), an explicit boundary ('OFAC SDN match only'), and named alternatives with the condition that selects each ('For a broader rule-based risk label use wallet_risk (addresses) or token_risk (tokens); for a list of addresses use sanctions_screening_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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the paid x402 model, the exact cost ($0.125 per call), the endpoint, that the tool returns a ready-to-POST request rather than the data itself, and that bad input is refused before any charge. Those are behavioral traits an agent cannot get from annotations or schema.

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

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

Front-loaded with the use condition and scope, then the mechanics; nearly every clause carries information. It is dense and packs payment and endpoint detail into one long sentence, which costs a little readability but not waste.

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

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

No output schema exists, but the description explains that the return value is the exact paid x402 request body plus a response schema and example, so the agent knows what it receives and what to do with it. Combined with cost, endpoint, and input limits, 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%, so the baseline is 3, but the description adds chain formats (0x, BTC, TRX, SOL and others as OFAC lists them), the 25-per-POST cap, and confirms names are not accepted. That meaningfully supplements the schema's array constraints.

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

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

States a specific verb and resource (screen a list of wallet addresses against the OFAC SDN list), plus scope (up to 25 per POST) and supported chains. It explicitly names the sibling sanctions_screening and the condition that selects it, so the agent can distinguish the two without opening either schema.

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

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

Opens with 'Use when you need to screen a list of wallet addresses' and closes with 'For one address or a name use sanctions_screening' — an explicit when-to-use plus the named alternative and the condition that routes to it. 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 only cover the safety profile (readOnly, idempotent, openWorld, non-destructive); the description adds genuinely non-obvious behavior: results are capped at the top 5 on the free tier, fuller results/market report/underserved-niche analysis sit behind paid x402 or MPP endpoints on the same host, and ranking is usage-weighted rather than raw-volume. These are exactly the traits an agent needs before deciding whether a call is sufficient.

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?

Single dense paragraph, front-loaded with the verb/resource/ranking before the freemium caveat and the sibling routing. Nearly every clause earns its place, though the parenthetical enumeration of three alternatives makes it longer than strictly necessary.

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

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

No output schema exists, so the description carries return-value burden and does disclose the free-tier result cap and paid escalation path. It does not describe the shape of a returned service record or whether results are paginated, but nothing essential to invoking 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 100% for all three parameters, so the schema already explains query, network (CAIP-2) and include_testnets semantics. The description adds no per-parameter syntax, and its usage commentary concerns result ranking rather than inputs; 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 (Search) and resource (live x402 services), plus the ranking basis (REAL 30-day usage, unique payers weighted above raw call volume) and index coverage. It explicitly names the three siblings it is not (best_service_for_task, x402_market_stats, list_paid_data_products), 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?

Goes beyond context to explicit exclusions: 'Not for picking one service for a concrete task (use best_service_for_task)', 'for market-wide totals (use x402_market_stats)', 'or for this host's own products (use list_paid_data_products)'. Each alternative is paired with the condition that selects it.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds critical behavior the annotations cannot: this is a paid x402/MPP endpoint at $0.008 per call, it returns a request descriptor rather than the data itself, and bad input is refused before charging. That extra step is essential to invoking it 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?

Three sentences, front-loaded with the 'Use when' trigger, followed by the return/payment mechanics and then the sibling routing. Dense but every sentence carries load; the payment-flow sentence is long but necessary.

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

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

With no output schema, the description compensates by explaining that the response is an x402 request descriptor containing the response schema and an example, plus the URL and price. It covers the full invocation flow, though it does not describe pagination or what 'key financials' actually includes.

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 cik, ticker, form, and limit. The description restates 'by ticker or CIK' but adds no format or interaction detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource – retrieving 'SEC EDGAR filings and key financials' – scoped by ticker or CIK, and names the sibling (sec_filings_batch) it is not. An agent can tell exactly what this returns and how it differs from the batch variant.

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 and routes multi-company lookups to sec_filings_batch. It lacks an explicit when-not clause (e.g. non-US companies), but the usage context is clear enough to select correctly.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds the non-obvious behaviors the annotations cannot: the call does not return data but returns a paid x402 request recipe (endpoint, $0.08 per call, response schema + example), the caller must POST it with an x402 or MPP client, and invalid input is refused before any charge. That is exactly the extra context an agent needs to avoid mis-invoking it.

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 condition, then the return semantics, pricing, and fallback. Four sentences, each carrying distinct information; slightly dense with the endpoint/client mechanics but nothing is wasted.

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

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

No output schema exists, and the description compensates by explaining what actually comes back (an x402 request payload plus response schema and example), the price, and the pre-charge validation behavior. An agent has everything needed to call it correctly and route single-company work to sec_filings.

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 companies/form/limit, including the 1-10 bound and duplicate removal. The description restates 'up to 10 tickers or CIKs' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: 'recent SEC EDGAR filings for several US public companies at once: up to 10 tickers or CIKs in one POST.' It also explicitly names the sibling it is not ('For one company use sec_filings'), so an agent can distinguish it from sec_filings 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 an explicit trigger ('Use when you need ... several US public companies at once'), the batch-size constraint, and a named alternative ('For one company use sec_filings'). When/when-not/alternative are all 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?

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?

Beyond the readOnly/idempotent annotations, it discloses pricing ($0.01 per call), the exact paid endpoint (GET /token/risk), that the call must be made with an x402 or MPP client, and that bad input is refused before any charge. These are non-obvious interaction traits the annotations cannot convey.

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

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

The purpose and scope are front-loaded in the first sentence, with the sibling pointer at the end. It is dense but every clause carries weight; the x402 mechanics occupy a long stretch that could be tightened 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?

With no output schema, the description appropriately explains that the response schema and an example are returned by the paid request, so the agent knows it must make a second call to obtain data. For a tool with an unusual two-step paid flow, this is complete.

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

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

Schema description coverage is 100%, so the schema already documents chain, address, and request_key semantics. The description adds no parameter-level detail (e.g., which chains are supported or how request_key behaves) beyond what the schema provides, 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 names a specific verb+resource (rule-based risk label on an ERC-20 token) and enumerates exactly what is checked: OFAC SDN matches on token/owner/proxy admin, upgradeable proxy, and owner mint/pause/blacklist functions. It explicitly distinguishes itself from the sibling wallet_risk (token contract vs. wallet).

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

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

It states the when ('before you accept or route it') and the explicit alternative ('For a wallet (not a token contract) use wallet_risk'), which is exactly the sibling an agent would confuse it with. 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?

Beyond the readOnly/idempotent annotations, it discloses the actual wire behavior (HEAD first, GET fallback on 4xx/5xx, redirects followed up to 4), the $0.01 per-call cost, the requirement to call the returned URL with an x402 or MPP client, and that bad input is refused before any charge. These are material facts an agent cannot infer from annotations or schema.

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

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

The trigger condition is front-loaded and every sentence carries information (mechanics, payment workflow, refusal semantics, batch routing). It is a dense paragraph rather than a run-on, though the payment sentence is long enough to warrant mild trimming.

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 correctly closes that gap by explaining that the call returns the paid x402 request (endpoint, price, response schema, example) rather than the ping result itself. Nothing needed to invoke this tool correctly is missing.

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

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

Schema coverage is 100% with a single well-documented 'url' property, so the baseline is 3. The description adds no format, encoding, or edge-case detail about the parameter beyond what the schema already says (public http/https, ports 80/443/8080/8443).

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 ('know if a URL is up right now', 'one HEAD request from a Cloudflare edge') and immediately distinguishes itself from the sibling url_uptime_ping_batch. An agent can tell exactly what this tool does without opening the schema.

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

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

It opens with 'Use when you need to know if a URL is up right now (uptime ping, health check, link check)' and closes by routing multi-URL cases to url_uptime_ping_batch. Both the when 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds genuinely important behavior: the x402/MPP payment flow, the $0.10 per-call cost, that checks run from Cloudflare's edge, and critically that 'Bad input is refused before any charge' — a cost-safety guarantee not implied by any annotation.

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 and the sibling routing, and each sentence carries real information (checks performed, payment mechanics, cost, error behavior). The middle sentence packing endpoint, price, schema, example, and client instructions into one clause is dense but justified.

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

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

With no output schema, the description still tells the agent exactly what comes back (the paid x402 request body plus response schema and example) and how to obtain the data. Payment flow, cost, error handling, and the single-URL alternative are all covered.

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 already documented ('1 to 10 URLs; duplicates are removed'), so the baseline is 3. The description adds only the http(s) scheme constraint and restates the 10-URL cap; it does not clarify what counts as 'bad input' that triggers the pre-charge refusal.

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 (batch uptime ping), the scope (up to 10 http(s) URLs in one POST), what each check covers (status, latency, redirects, TLS, server), and explicitly names the single-URL sibling it is not: 'For one URL use url_uptime_ping.'

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 the explicit trigger ('Use when you monitor several endpoints') and closes with the alternative and its selection condition ('For one URL use url_uptime_ping'). Both the when-to-use and the when-to-use-something-else cases 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 only cover safety/idempotency, so the description adds substantial behavioral context: a 64 KB size cap, 'no external call', decode-to-hex behavior for non-UTF-8 bytes, and the crucial workflow detail 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-loaded with the use condition, and every sentence carries weight (limits, pricing, rejection-before-charge). It is a dense single paragraph, slightly run-on, but 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 compensates by explaining the x402 payment workflow, the returned request shape, the price, and that a response schema plus example are included. An agent has enough to invoke and follow through correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies the url_safe variant (no padding) and the hex decode fallback, but mostly restates what the schema already documents.

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 specific verbs and resources: encode UTF-8 text to base64 (standard or url_safe) or decode base64 back to text, with hex fallback for non-UTF-8 bytes. An agent can distinguish this from siblings like util_hash or util_jwt_decode 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 base64 in or out' gives a clear triggering condition, and it outlines the encode/decode choice. It doesn't explicitly name sibling alternatives, but the trigger context is unambiguous.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds the crucial non-obvious behaviors: this is a paid endpoint ($0.001/call), it returns an x402 request spec rather than the digest directly, invalid input is refused before any charge, and there is a 64 KB cap. Those are exactly the traits an agent cannot infer from structured fields.

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

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

Two dense sentences with the usage trigger front-loaded and no filler. It is on the longer side, but nearly every clause (pricing, URL, client requirement, input validation) carries distinct operational value.

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

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

No output schema exists, so the description correctly explains what is returned (the exact paid request, response schema and example) and how to turn it into the actual digest. Combined with fully documented parameters, 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%, so algo, text and encoding are already documented with enums and defaults. The description largely restates that (algorithm list, encoding list, size limit), adding no new syntax or format guidance beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource (checksum/digest of a string) and enumerates the supported algorithms and encodings. It is immediately distinguishable from siblings like util_base64 and util_jwt_decode 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 a checksum or digest of a string" gives a clear trigger condition, and the second sentence explains the actual invocation flow (call the returned URL with an x402/MPP client). It does not, however, name alternatives or explicitly exclude sibling utilities, so a 4 rather than 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 read-only, idempotent, non-destructive and open-world status, so the bar is low — yet the description adds genuinely non-obvious behavior: the tool does not return the data itself but a paid request template the agent must execute, the price is $0.001 per call, payment requires an x402/MPP client, and invalid input is rejected before any charge. Those are material traits an agent could not infer from the annotations.

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

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

The when-to-use condition is front-loaded and every clause carries information (IP fields, endpoint, price, return shape, payment mechanism, no-charge guarantee). The second sentence is long and compound, which slightly reduces scannability, but nothing is padding.

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

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

With no parameters and no output schema, the description must carry the return-shape burden — and it does, listing the returned fields and stating that the tool returns the request, the response schema and an example. An agent has everything needed to decide whether to call it and how to complete the paid fetch.

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

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

There are zero parameters, so per the rubric the baseline is 4. The description correctly notes the call takes 'your input' only in the sense of the request template and adds no parameter guidance that is needed, since there is nothing to configure.

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 capability: returning the caller's externally-visible public IP plus country, region, city, ASN and AS organization. That is a distinct resource/verb pair and is easily separable from the other util_* siblings (base64, hash, uuid, jwt_decode, json_validate), none of which report caller geography.

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 a clear triggering condition ('Use when an agent needs to know how it is seen from outside') and tells the agent what to do next: call the returned URL with an x402 or MPP client. It does not name alternatives, but within the util_* family no alternative would satisfy this need, so explicit exclusions are not required.

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

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

Annotations only cover the safe-read profile (readOnly, idempotent, openWorld, non-destructive); the description goes well beyond that by disclosing the paid model ($0.001 per call), the non-obvious indirect return (a paid x402 request rather than the data), and the no-charge-on-bad-input behavior. That is exactly the behavioral context structured fields cannot carry.

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

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

The use case is front-loaded before the mechanics, and every clause carries information (subset scope, price, endpoint, client requirement, refund behavior). It is dense and slightly run-on, but nothing is padding.

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

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

With no output schema, the description carries the full burden and does so: it explains that the immediate return is a payment request, where to send it, what accompanies it (response schema and example), and how bad input is handled. An agent has everything needed to invoke 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 description coverage is 100% and both parameters already carry descriptions in the schema, including the note that an object body is accepted. The description adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('validates json against a JSON Schema subset') and names the precondition for use ('before acting on it'). No sibling tool (util_base64, util_hash, util_jwt_decode) overlaps, so an agent can pick this out immediately.

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

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

'Use when you must check that a JSON document fits a schema before acting on it' gives an explicit when-to-use trigger, and the closing clause explains the follow-up call with an x402 or MPP client. It does not name when-not-to-use or an alternative validator, but no sibling competes for the same job, so the gap is minor.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely new behavioral context: the per-call price ($0.001), that bad input is refused before any charge, and that the tool yields a request descriptor to be invoked separately via an x402/MPP client. This pricing and error-before-charge disclosure is exactly the kind of extra 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?

The purpose is front-loaded in the first clause, and the sentences each carry distinct information (capability, invocation model, error behavior). The middle sentence is somewhat overloaded with URL, price, schema, example, and client details, but nothing is wasted.

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

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

With no output schema, the description carries the return-value burden and does so: it lists the decoded fields and expiry status. It also explains the invocation model, cost, and refusal behavior, so 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?

There is a single parameter with 100% schema description coverage ('JWT header.payload.signature'), so the schema already documents the input format. The description adds no additional syntax or format guidance for the token parameter, which matches the baseline 3 for high-coverage schemas.

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

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

The description names a specific verb and resource (decode/inspect a JWT) and enumerates exactly what is produced: header, payload, alg, kid, and iat/nbf/exp as ISO times plus expiry status. It is clearly distinguishable from the sibling utilities (util_base64, util_hash, util_json_validate) and even discloses that the tool returns a paid x402 request descriptor rather than the raw 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 to inspect a JWT without a key' gives a clear trigger condition, and the description explains the paid two-step flow (call the returned URL with an x402 or MPP client). It does not name an alternative sibling or state when NOT to use it, so it falls short of full when/when-not guidance.

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

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

Beyond the annotations' safety profile, the description discloses behavior an agent could not otherwise infer: the tool does not return UUIDs directly but returns the exact paid x402 request (GET /util/uuid) that the caller must then invoke with an x402 or MPP client. It also states the per-call price ($0.001), that a response schema and example are included, and that bad input is rejected before any charge — all critical, non-obvious traits.

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 every sentence carries information (parameters, delivery mechanics, pricing, safety). The middle sentence is long and dense, but the content is necessary rather than padding.

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

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

With no output schema, the description must explain what comes back — and it does, stating the return is the paid x402 request plus response schema and example. Accounting for the non-trivial payment/MPP flow, an agent has everything it needs to call this correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented by the schema, and the description largely restates them ('n (1-100)', 'random v4 or time-sortable v7'). It adds no format or interaction detail beyond what the schema provides, 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?

The description states a specific verb+resource ('fresh UUIDs'), quantifies it (n 1-100, v4 random or v7 time-sortable) and names the generation substrate (Cloudflare edge, crypto randomness). It is trivially distinguishable from the other util_* siblings such as util_hash or util_base64.

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

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

'Use when you need fresh UUIDs' gives a clear triggering condition, and 'no external call, under 100 ms' implicitly frames it against slower/external alternatives. However it never names when NOT to use it or a specific sibling alternative, 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 readOnly, openWorld, idempotent, and non-destructive. The description adds critical non-obvious behavior: it is a paid x402 endpoint ($0.003 per call), returns a paid request object with response schema and example rather than data directly, requires calling the URL with an x402 or MPP client, and refuses bad input before charging. This is rich disclosure beyond annotations.

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

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

Front-loads the use case and supported assets, then payment mechanics, then routing alternatives. Every sentence adds useful information, though 'One wallet across several chains' is slightly redundant; overall well-structured but not maximally 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?

No output schema exists, but the description explains exactly what is returned (a paid x402 request with response schema and example), how to use it, pricing, and error behavior. Combined with annotations covering safety and idempotency, an agent has everything needed to invoke 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 description coverage is 100%, so both address and chains are already documented in the schema. The description adds output scope (which tokens and chains are covered) but no new parameter syntax or constraints, so the baseline of 3 applies. The chains default and address format remain schema-provided details.

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 (retrieve balances) and resource (wallet's token balances across multiple chains), lists supported tokens and chains, and names three sibling alternatives for narrower or wider use cases. An agent can distinguish it from evm_erc20_balance, evm_native_balance, and wallet_balance_batch without opening schemas.

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

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

Explicitly says 'Use when you need...' and gives concrete alternatives: one token on one chain -> evm_erc20_balance; native coin on one chain -> evm_native_balance; many wallets -> wallet_balance_batch. This is direct routing guidance with clear 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 readOnly/idempotent/openWorld/non-destructive, yet the description adds material behavior beyond them: the call is a paid x402 request at $0.075, it returns a request body to POST rather than the data itself, and bad input is refused before any charge. These are exactly the traits an agent cannot learn from annotations or schema.

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

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

The use condition and scope are front-loaded, and the closing sibling reference is well placed. The middle sentence about the x402 request, pricing, and response schema is dense but each clause carries distinct information, so little is wasted.

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

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

For a two-parameter tool with no output schema, the description covers what is returned (the paid request plus response schema and example), the invocation path, the price, and the failure policy. Nothing an agent needs in order 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 the baseline is 3. The description adds the accepted address formats (0x or ENS names) and the 25-address cap, which slightly enriches the addresses parameter, but it says nothing about the optional 'chains' parameter beyond what the schema already documents.

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 the scope (up to 25 addresses in one POST). It explicitly distinguishes itself from the sibling wallet_balance by naming it as the single-wallet 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?

Opens with the use condition ('when you need native and stablecoin balances for a list of wallets') and closes with the routing rule 'For one wallet use wallet_balance.' The batch-vs-single decision is fully specified with no inference required.

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), and the description goes well beyond them: it discloses the payment model (x402/MPP, $0.01 per call), that bad input is refused before any charge, and that the tool returns a paid request URL rather than the data itself. That payment/delivery behavior is not derivable from annotations or schema.

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

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

Front-loads the purpose, then payment mechanics, then alternatives. Dense but every clause carries information; only minor looseness from packing the exception routing into a single trailing 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 compensates by stating the return is the exact paid x402 request plus response schema and example, and that input validation happens before charging. An agent has everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so both parameters (address with its 0x+40-hex pattern and request_key idempotency) are already documented in the schema. The description adds chain-scope context but nothing per-parameter beyond what the schema states, 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 (risk-label) and resource (EVM address) plus the exact rule set: OFAC SDN match, contract vs plain account, outgoing tx count with chain coverage. It explicitly distinguishes itself from token_risk and sanctions_screening_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?

Gives an explicit when-to-use ('before paying it') and names two alternatives with the conditions that select them (ERC-20 -> token_risk; many addresses, OFAC-only -> sanctions_screening_batch). No inference required.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds value by clarifying that the data is an aggregate snapshot rather than per-service detail, which implies the returned numbers are market-wide and not filterable. Still, it does not mention freshness or the cost of retrieval.

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 two tight sentences: the first delivers the metrics, and the second delivers the scope and the alternative tool. There is no filler, and the key content comes first.

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

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

Because there is no output schema, the description needs to explain what comes back; it does so by listing the reported metrics. It falls short only on response format and freshness, which are minor for a zero-parameter aggregate read.

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 of 4 applies. The description correctly signals that no filtering inputs exist by saying 'Market-wide totals only' and by pointing to the sibling tool for narrower queries.

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

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

The description names a specific verb ('Overall statistics') and resource (the x402 service market), then enumerates exactly which metrics are reported: catalog size, median price per call, 30-day calls, unique payers, and top categories.

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

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

It states the scope constraint ('Market-wide totals only') and routes to the correct sibling ('for individual services use search_x402_services'), so an agent knows exactly when to pick this tool instead of that one.

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

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

Annotations 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.