Safety checks before an agent pays: address poisoning, phishing links, x402 payment requests.
Scored across 4 tools
address_check and link_check are clearly distinct, but payment_check and x402_preflight overlap heavily: both validate an x402 payment's price, token, payee, and site. Their descriptions distinguish the supplied-402-request case from the live-endpoint-probe case, but an agent could still hesitate over which to use.
The names are consistently snake_case and mostly follow a resource_check pattern. x402_preflight is a minor deviation, but it remains readable and clearly related to the x402 payment-checking family.
Four tools is well-scoped for a focused pre-transaction security verdict service. Each tool targets a recognizable check type, and the set avoids bloat.
The surface covers the main stated domains: crypto addresses, links/domains, x402 payment requests, and live x402 endpoint preflight. Minor gaps exist around standalone token-contract verification, transaction simulation, or batch checks, but core workflows are covered.
Before sending crypto: checks an EVM, Solana or Bitcoin address for a valid checksum, the right network, dead/burn/program addresses, a mismatch with the expected payee, and address-poisoning lookalikes of addresses you already trust. Live on-chain lookup: has the address ever been used, is it a wallet, contract or program. Returns pass / caution / fail with reasons. Price: $0.01 USDC per call after 25 free calls per day.
| Name | Required | Description | Default |
|---|---|---|---|
| known | No | Optional. Addresses you have paid or trust before (max 200). GET: comma-separated. | |
| address | Yes | The address you are about to pay. | |
| network | No | Optional. Network you intend to use. | |
| _payment | No | x402 v2 payment: base64 PaymentPayload, as you would send in the PAYMENT-SIGNATURE header. Only needed after the free allowance is used. | |
| expected | No | Optional. The address you were told to pay, e.g. from an invoice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: discloses that it performs a live on-chain history lookup, states the return shape (pass / caution / fail with reasons), and gives pricing and rate-limit terms ($0.01 USDC per call after 25 free calls/day), which an agent needs before invoking a paid endpoint. The only tension is that a live on-chain lookup of arbitrary addresses sits uneasily with openWorldHint=false, but the description is otherwise unusually forthcoming about cost and side effects.
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 decision context ("Before sending crypto") before the detail, then layers checks, return format, and price in four dense sentences with no filler. Every sentence carries information an agent would otherwise have to guess.
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 naming the verdict vocabulary and its structure. With 100% schema coverage on the five parameters, the cost model disclosed, and the checks enumerated, nothing material is missing 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 the baseline is 3, but the description adds real meaning by explaining what the optional parameters are for: "expected" drives the payee-mismatch check and "known" drives address-poisoning lookalike detection. That connects the two most semantically ambiguous parameters to concrete behaviors rather than restating their types.
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 (checks an address) plus the exact scope: checksum, network match, dead/burn/program addresses, payee mismatch, poisoning lookalikes. The domain (EVM/Solana/Bitcoin payment addresses) is narrow enough that an agent can distinguish it from link_check and payment_check 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?
"Before sending crypto" gives an explicit triggering moment, which is the key selection signal for this tool. It does not, however, name when to prefer link_check or payment_check instead, so routing between 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.
Before opening a link or entering credentials: detects lookalike domains (homoglyphs, mixed alphabets, typosquats), brand impersonation in domains and subdomains, hidden destinations (user@host), unsafe schemes, and risky TLDs across 70+ commonly impersonated brands. Live lookups: does the domain exist (DNS) and how old is it (registration date), since most phishing domains are days old. The page itself is never visited. Price: $0.01 USDC per call after 25 free calls per day.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The link to check. | |
| _payment | No | x402 v2 payment: base64 PaymentPayload, as you would send in the PAYMENT-SIGNATURE header. Only needed after the free allowance is used. | |
| expectedBrand | No | Optional. The brand this link claims to be, e.g. "paypal". Fails if the domain is not official. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: live DNS and registration-date lookups with the rationale ("most phishing domains are days old"), an explicit safety guarantee that the page itself is never fetched, and the full cost model ($0.01 USDC per call after 25 free calls/day) which explains the _payment parameter's role. Read-only nature is consistent with 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 decision trigger ("Before opening a link..."), then signals checked, then lookup behavior and rationale, then the safety guarantee, then price. Every clause carries information an agent would otherwise have to infer; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that reaches external DNS/registration data with no output schema and a paid path, the description covers cost, safety, and detection scope well. The one gap is that it never indicates what a result looks like (verdict/score/reasons), forcing the agent to call blind on the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains why expectedBrand matters (brand impersonation detection across 70+ brands, "fails if the domain is not official") and why _payment exists through the free-allowance/pricing disclosure. It stops short of clarifying the format of the returned verdict.
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 (detects/checks) against a specific resource (a link/URL) and enumerates the exact classes of signal examined: homoglyphs, typosquats, brand impersonation, user@host hidden destinations, unsafe schemes, risky TLDs. The resource is plainly distinct from the siblings (address_check, payment_check), so an agent can disambiguate 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?
"Before opening a link or entering credentials" gives an explicit trigger condition, which is the strongest form of usage guidance. It doesn't state when-not-to-use or name a sibling, but the sibling set covers wholly different resource types (addresses, payments), so the omission costs little.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before you sign an x402 payment to another service: pass the 402 payment request you received and get one verdict on the whole thing. Checks the price against your limit, that the token is real USDC with the right signing name, the payee address (checksum, poisoning lookalikes, on-chain history), whether the request claims a different site than the one you called, and the site itself (lookalike domains, domain age). One call, one price. Price: $0.01 USDC per call after 25 free calls per day.
| Name | Required | Description | Default |
|---|---|---|---|
| _payment | No | x402 v2 payment: base64 PaymentPayload, as you would send in the PAYMENT-SIGNATURE header. Only needed after the free allowance is used. | |
| maxPrice | No | Optional. Your price limit in US dollars, e.g. "0.05". | |
| knownPayees | No | Optional. Payee addresses you have paid before (max 200). GET: comma-separated. | |
| requestedUrl | No | Optional. The URL you called that returned the 402. | |
| paymentRequired | Yes | The PAYMENT-REQUIRED header value (base64) or the 402 JSON body. GET: base64 only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral facts: it is a paid call at $0.01 USDC after 25 free calls per day, and all checks are consolidated into one verdict rather than separate calls. It stops short of describing what the verdict response contains, which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The precondition is front-loaded in the first clause and the enumerated checks are packed into one dense sentence with no wasted lead-in. "One call, one price" borders on marketing filler but does convey the batch-verdict and cost model.
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 five-parameter read-only checker with a fully documented schema and no output schema, the description covers the trigger, the full scope of checks, the cost model and the free allowance. An agent has everything needed to decide to call it and to assemble a 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 every parameter including _payment, maxPrice, knownPayees and requestedUrl is already documented in the schema. The description only reinforces paymentRequired ("pass the 402 payment request you received") and the maxPrice concept via "checks the price against your limit" — 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?
Specific verb-and-resource: pass a received 402 payment request, get a single verdict, with the individual checks enumerated (price limit, USDC/token legitimacy, payee address, site mismatch, domain reputation). It is unmistakable what the tool does, but it never distinguishes itself from the sibling tools address_check and link_check, whose subject matter it subsumes.
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?
"Before you sign an x402 payment to another service" gives a clear triggering condition and an implicit ordering constraint relative to signing. There are no exclusions and no routing advice telling the agent when to prefer address_check or link_check for a narrower question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before paying an x402 service: safely makes one unauthenticated HTTPS request, confirms the endpoint is live and returns a current 402 challenge, then checks its price, USDC token, payee and site. Never signs or settles a payment. HTTPS only; redirects and private/local targets are refused. Price: $0.01 USDC per call after 25 free calls per day.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public HTTPS x402 endpoint to preflight. | |
| _payment | No | x402 v2 payment: base64 PaymentPayload, as you would send in the PAYMENT-SIGNATURE header. Only needed after the free allowance is used. | |
| maxPrice | No | Optional. Your maximum acceptable US-dollar price, e.g. "0.05". | |
| knownPayees | No | Optional. Payee addresses you have paid before (max 200). GET: comma-separated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond readOnlyHint/openWorldHint: it never signs or settles a payment, only unauthenticated HTTPS, refuses redirects and private/local targets, and discloses the $0.01 USDC cost after 25 free calls per day. Cost and safety refusal rules are exactly the behavioral facts 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 decision-relevant condition ('Before paying…') and every clause earns its place (safety scope, no signing, HTTPS-only, cost). It is a single run-on sentence with several stacked clauses, which is dense 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?
No output schema exists, and the description still tells the agent what a successful call yields (liveness confirmation, 402 challenge, price, token, payee, site). Combined with the safety and pricing disclosures, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so url, _payment, maxPrice and knownPayees are already documented in the schema. The description mentions the price/token/payee checks but adds no syntax or usage detail for maxPrice or knownPayees, 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 ('preflight' an x402 endpoint) and enumerates exactly what it verifies: liveness, a current 402 challenge, price, USDC token, payee and site. That is far more specific than the sibling names address_check/link_check/payment_check, so an agent can tell which to pick 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 an explicit trigger ('Before paying an x402 service'), which places it clearly ahead of any payment action. It does not name the sibling tools as alternatives or state when-not-to-use beyond the safety exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
x402_preflightaddress_checklink_checkpayment_checkVerify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
Check any x402 endpoint before your AI agent pays it: trust grade, verdict, and hijack checks.
Pre-payment checks for AI agents: x402 quotes, untrusted prompts and audit receipts.
Verify URLs, payees, and messages before acting: red/yellow/green trust verdicts for agents.
Add one secure layer between your agents and this server.
