x402 agent toolkit: service finder, payment safety, Solana & web tools

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

Annotations only cover readOnlyHint and openWorldHint, but the description adds the cost/payment model ('Paid HTTP: /v1/email-check') and the verdict taxonomy (valid|risky|invalid), both of which materially affect whether and how an agent calls it. It stops short of stating rate limits, latency, or what happens on an unregistered domain, keeping it below a 5.

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

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

The core sentence is dense, front-loaded and well structured. But roughly half the text is a referral/earnings advertisement (20% revenue share, off-chain ledger, monthly USDC settlement, minimum 1 USDC) that does not help an agent decide to call or how to call the tool, and it buries the useful parts.

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 one-parameter, no-output-schema tool, the definition covers what is checked and what verdict comes back, which is enough for correct invocation. What is missing is minor: whether results include the detailed signal breakdown or just the verdict, and whether invalid input strings produce an error versus an 'invalid' verdict.

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

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

There is a single required parameter at 100% schema coverage, so the schema already carries the semantics. The description confirms the input domain implicitly through the list of checks (e.g. disposable-domain and MX lookups imply a full address), but adds no format, normalization, or edge-case guidance beyond that.

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

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

The description opens with a specific verb and resource ('Validate an email address') and enumerates exactly what is checked: syntax, domain existence, MX/null-MX, SPF, DMARC, disposable domains, role accounts, free providers and typo suggestions. It is unmistakably distinct from the sibling tools (solana_mint_check, web_read_markdown, x402_*), which handle entirely different resources.

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 clarifies the method boundary ('without sending mail or SMTP probing'), which implicitly contrasts with heavier SMTP-verification approaches. However, it never states when an agent should reach for this tool versus doing nothing, nor does it address any sibling as an alternative, so usage is only implied.

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 and openWorldHint=true, so the safety profile is partly covered. The description adds important behavioral context beyond annotations: it is a paid HTTP call, it returns riskScore 0-100 and verdict low|medium|high, and it discloses the referral mechanism. It does not describe pricing, auth requirements, or failure behavior, which keeps it from a 5.

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

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

The purpose, checks, and return values are front-loaded and useful. However, the referral program paragraph is lengthy and largely irrelevant to selecting or invoking the tool, which dilutes conciseness and adds operational detail an agent does not need for the call.

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

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

There is no output schema, so the description must carry return semantics; it does so by naming riskScore and verdict. It also lists the checks performed and discloses paid HTTP access. It is broadly complete for a read-only remote check, though additional detail on output fields or payment cost would strengthen it.

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

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

There is only one parameter, and schema description coverage is 100%, so the schema already explains that 'mint' is a Solana mint address in base58. The description does not add format, validation, or example details beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: a rule-based safety check of a Solana SPL / Token-2022 mint. It enumerates the exact checks performed and the returned riskScore/verdict, making the tool's function immediately distinguishable from unrelated 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 by the safety-check framing, but the description does not explicitly say when to use this tool versus alternatives or when not to use it. It provides enough context to infer the use case but no 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 only cover readOnly and openWorld, so the description genuinely adds value: robots.txt enforcement, public-only scope, a 1h cache, and a sha256 of returned content. The 4 rather than 5 comes from the ambiguity introduced by "Paid HTTP: /v1/read" — an agent cannot tell from the text whether invoking this MCP tool itself incurs payment or whether that only applies to the raw HTTP path, and truncation behavior tied to maxChars is unstated.

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 clause is a well front-loaded, useful sentence, but the majority of the description is a referral-program solicitation (ref wallet param, 20% of net revenue, off-chain ledger, monthly USDC settlement, manual review, minimums, earnings endpoint) that has no bearing on selecting or invoking this tool. That block is marketing copy occupying most of the text and diluting the operational 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?

For a two-parameter read tool with no output schema, the description covers the essentials an agent needs: fetch target scope, output format, content hash, caching, and robots.txt gating. It falls short of 5 only because it never explains what happens to output when maxChars truncates the page or whether the sha256 is of the truncated or full content.

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 both url ("public http(s) page") and maxChars ("500-100000, default 20000") already documented in the schema. The description adds nothing about parameter meaning beyond reinforcing the public-only constraint, 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 opening sentence gives a specific verb and resource ("Fetch a public web page and return clean Markdown") and even enumerates the content types preserved (title, headings, links, lists, code) plus the sha256 return. No sibling tool (email_check, solana_mint_check, x402_*) does web fetching, so the tool is unambiguously distinguishable.

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

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

Constraints such as "public pages only" and robots.txt compliance implicitly fence off when this tool is invalid, but there is no explicit statement of when to use it versus alternatives, nor any guidance on fallback behavior when a page is blocked or non-public. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety and network profile is covered; the description usefully adds that it makes a live fetch, that it screens against the OFAC SDN list, and that it returns one of four verdicts. It adds nothing about latency, failure modes when the endpoint is unreachable, or what distinguishes warn from block. The referral paragraph describes an unrelated earnings program, not this tool's behavior, and adds no invocation context.

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 dense, front-loaded, and earns its place. The second half is a referral-program pitch — ref parameter instructions, revenue split, ledger mechanics, payout schedule, minimum, and an earnings endpoint — none of which helps an agent decide to call or how to call this tool.

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

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

With no output schema, the description does the right thing by naming the verdict values, so return values are partly covered. But for a tool that performs a live network fetch and an OFAC screen, it omits how the verdict breaks down, what triggers warn versus block, and any handling for non-402 or unreachable endpoints beyond the 'not_402' label.

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

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

With only 50% schema coverage, the description should compensate for the undocumented parameter. It never mentions 'method', its GET/POST enum, or a default, and only vaguely implies a fetch. The 'url' parameter is redundant with its schema description ('x402 endpoint you plan to pay').

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

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

States a specific verb and resource — fetch an x402 endpoint and validate its HTTP 402 payment requirements — and enumerates exactly what is checked (scheme, network, payTo, amount, asset) plus OFAC SDN screening and the verdict vocabulary ok|warn|block|not_402. An agent can distinguish this pre-payment check from a settlement verifier 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?

The opening clause 'Before paying an x402 endpoint' is explicit timing guidance that implies this runs prior to payment, which implicitly separates it from x402_verify_settlement. However, no sibling is named and no exclusion is stated, so the agent must infer the boundary between precheck, recommend, and settlement verification.

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 and openWorldHint, but the description adds substantial behavior the annotations don't convey: ranking by relevance plus live liveness, an unpaid probe validating x402 terms, OFAC screening of payTo, latency and price signals, and that the top 3 are freshly pre-checked. The referral-program details also disclose the economics of routing paid calls, though the off-chain/monthly-settlement mechanics are more vendor promotion than call-relevant behavior.

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

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

The purpose is correctly front-loaded in the first sentence, but the second sentence is a dense, parenthetical referral-program paragraph that does not help an agent select or invoke this tool and crowds out parameter guidance. Roughly half the text is promotional weight rather than decision-relevant 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 does carry the return-value burden and does so reasonably: ranked endpoints with liveness, latency, and price, plus pre-checked top 3. For a four-parameter, read-only discovery tool this is close to complete, with the main gap being how limit/network/maxPrice shape the result and what an empty or no-match response looks like.

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 75%, with task, network, and maxPrice documented in the schema and limit bounded by min/max but undescribed. The description adds no meaning about how ranking interacts with limit, network, or maxPrice — the only parameter-like mention (ref=) is an HTTP query convention for paid calls, not an input to this tool.

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

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

The first sentence states a specific verb and resource: find which x402 paid service to call for a task, and the second clarifies that it returns ranked endpoints. This distinguishes it implicitly from x402_precheck (a single-endpoint check) and x402_verify_settlement (settlement verification), though no sibling is named explicitly.

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

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

Usage is implied by 'for a task' and the ranking/liveness framing, so an agent can infer this is the discovery step before calling a paid endpoint. However, there is no explicit when-to-use vs. when-not guidance and no mention of x402_precheck or x402_verify_settlement, so routing among the three siblings 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 readOnlyHint=true and openWorldHint=true, and the description usefully adds the verdict vocabulary (valid|invalid|pending|not_found) even though there is no output schema. However, it does not explain what distinguishes pending from not_found, how minConfirmations influences the verdict, or how long a not_found result should be retried — and roughly a third of the text is referral-program economics rather than tool behavior.

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

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

The opening sentence is well front-loaded and dense with actionable detail. The second sentence is a promotional referral-program pitch about routing paid HTTP calls and earning 20% of net revenue, which does not help an agent decide how or when to call this tool and dilutes the definition.

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

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

For a 7-parameter, no-output-schema tool, the description should carry more weight than it does: three parameters receive no semantic treatment at all, and verdict lifecycle behavior (pending/not_found, confirmation thresholds) is undefined. The network list and result enum are genuinely complete, but the reference to a separate referral endpoint is tangential to invoking this tool.

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

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

Schema description coverage is only 14% across 7 parameters, yet the description compensates for some of it by enumerating valid network values (base, base-sepolia, polygon, arbitrum, avalanche, bsc) and clarifying that amount is USDC paid to payTo. It leaves 'from', 'match' (exact vs atLeast), and 'minConfirmations' entirely unexplained, which is a meaningful shortfall given no enum or description exists in the schema for most of them.

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

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

The first clause is a precise verb+resource statement: 'Verify an on-chain USDC settlement: tx hash on network ... paid amount to payTo', which tells an agent exactly what inputs constitute a verification. The only gap is that it never contrasts itself with the siblings x402_precheck or x402_recommend, so the agent must infer that precheck is a pre-payment check and this is the post-payment one.

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

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

Usage is only implied — 'settlement' signals this runs after a payment is made, and the sibling name x402_precheck hints at the alternative, but the description never says 'use this after paying' or 'use precheck before paying'. No exclusions, no prerequisites, and no mention of what to do when the verdict is pending.

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