AML/compliance address screening for AI agent payments — free tools, no API key.
Scored across 10 tools
Descriptions go out of their way to delimit scope (screen_address vs screen_endpoint, screening vs counterparty_control_baseline vs resolve_agent_identity), which greatly reduces misselection. Still, five tools (screen_address, screen_endpoint, counterparty_control_baseline, resolve_agent_identity, payment_decision) all 'vet the counterparty' from different angles, so an agent must read carefully to pick the right one.
All names are snake_case and mostly verb_noun (attest_control_baseline, check_calldata_intent, screen_address, verify_payment_requirements). A few are bare noun phrases (payment_decision, baseline_controls, recent_flagged), a minor deviation from the dominant verb_noun pattern.
10 tools is well-scoped for an AML/payment-safety server, and each tool maps to a distinct stage of the pre-payment workflow (attest, screen, verify, decide). No redundancy or filler.
The surface covers the full prepayment lifecycle: identity resolution, address/endpoint screening, calldata intent, requirement verification, decision gating, and control-baseline attestation. Minor gaps exist around managing/looking up your own previously filed attestation (no get-or-update counterpart to attest_control_baseline), but core workflows are covered.
File your operator's control-baseline attestation — the counterpart to counterparty_control_baseline. That tool asks what controls the OTHER side runs; this one publishes what YOUR side runs, so payers can see it before settling with you. No account, no key, one call. Gaps are allowed and expected: answer false where a control is not in place and describe how you plan to close it in gapPlan. A filing with declared gaps is worth far more than no filing — it lets a payer decide against a known shape instead of a blank. Get the control ids from the baseline list first. Only file for a party you are actually authorised to speak for.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The accountable party's legal or commonly-used name, e.g. "Acme Robotics Ltd". This is who the attestation is about — not your agent's name. | |
| agentId | No | Optional. If this party already has an agent registered with OceanAlt, link the attestation to it. | |
| answers | Yes | Map of control id to boolean, e.g. {"ACB-1.1": true, "ACB-2.1": false}. Control ids come from the baseline list (see baseline_controls). | |
| contact | No | Optional contact for follow-up. Not published. | |
| gapPlan | No | For controls answered false: how and when you plan to close them. Plain text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write behavior (readOnlyHint=false), idempotentHint, and openWorldHint. The description adds valuable context on top of these: it is a one-call publish without an account/key, gaps are allowed and expected, and the actual value for the payer of a filing with gaps. It doesn't describe the response or failure modes, but that's a minor omission given the annotation coverage and rich behavior notes.
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: the first sentence nails the purpose and sibling distinction, then the next sentences add prerequisites and gap semantics. Every sentence has a purpose and the tone is natural. It's a little long with the 'A filing with declared gaps...' paragraph, but even that sentence adds a useful normative expectation, so it stays effective rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (2 required), a nested object, and no output schema, the description covers the necessary usage context: what the tool is for, how it relates to the sibling, the prerequisite list, the authorization condition, the gap-filling behavior, and even the business reason behind it. Nothing an agent requires 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 coverage is 100% and the schema already documents every parameter. The description adds a little extra semantic nuance (entity is the party, not the agent, and gapPlan is for false controls, plus the hint to derive control ids from baseline_controls), but it does not go far beyond the schema. This matches the baseline score of 3 for high schema coverage.
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 pair ('File your operator's control-baseline attestation') and immediately contrasts it with the sibling tool counterparty_control_baseline: 'That tool asks what controls the OTHER side runs; this one publishes what YOUR side runs.' This gives the agent an unambiguous, scoped purpose and clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool (file your own controls) versus the alternative (counterparty_control_baseline for the other party), names the prerequisite resource (get control ids from baseline_controls first), and imposes an authorization constraint ('Only file for a party you are actually authorised to speak for'). This provides the agent with both the context and the exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the OceanAlt Agent Control Baseline: the list of controls an agent operator is expected to run before it is allowed to move money, each answerable yes or no. Call this before attest_control_baseline so you file against real control ids. Each control carries which gate enforces it and why it exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value by explaining the nature of the content (each control is answerable yes/no, carries the enforcing gate and rationale), which is behavioral context beyond the annotations. No contradictions; a slightly higher score would require mentioning output structure or side effects, but these are unnecessary given the simplicity.
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 concise sentences, front-loaded with the core purpose and key detail (yes/no controls). The prerequisite instruction is placed naturally. No filler or repetition; every 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?
For a parameterless, read-only fetch with no output schema, the description provides all necessary context: what it returns, why it exists, and how it relates to a specific sibling. An agent can safely invoke this tool without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers 100% of parameter definitions (empty object). The description doesn't need to elaborate on parameters; it briefly references the output ('real control ids') which is relevant to consumers. With no parameters, baseline scoring is 4, and nothing is lost.
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 clearly states the tool's purpose: fetching the 'OceanAlt Agent Control Baseline' – a list of yes/no controls. It names the specific verb 'Fetch' and the resource, and distinguishes its role from the sibling attest_control_baseline by explaining it provides real control ids. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call this before attest_control_baseline', giving a concrete precondition and the reason (to file against real control ids). While it doesn't enumerate exclusions, this is a strong, unambiguous usage directive that positions the tool correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Anti blind-signing. Decodes what a transaction's calldata will actually do (ERC-20 transfer/approve/permit, setApprovalForAll, ownership transfer, native transfer) and compares it with what you believe you are doing. Pass intent:{action:'pay', to, amount} plus contract (the transaction's to) and data (hex calldata). decision match = does what you declared; mismatch = different recipient/amount, or an approval instead of a payment — do not sign; unknown = could not decode, which is not the same as safe.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | 0x-prefixed hex calldata. | |
| value | No | Native value in wei (optional). | |
| intent | No | ||
| contract | No | The transaction's `to` field (token contract for ERC-20 payments, or the recipient for native transfers). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds rich output semantics beyond that: it defines the three decision outcomes (match, mismatch, unknown), explains what mismatch means (different recipient/amount, or an approval instead of a payment), and warns that 'unknown' must not be treated as safe. This is exactly the behavioral context an agent needs before acting on the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core warning ('Anti blind-signing') and proceeds directly into what it decodes, how to call it, and how to interpret decisions. Every sentence earns its place: the supported action list, the parameter guidance, and the decision definitions all serve distinct needs. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested intent object, 4 parameters including optional value), the description is nearly complete. It handles the nested intent shape, defines the decision outputs without needing an output schema, and gives the critical safety caveat for 'unknown'. It leaves minor gaps around the optional value parameter and any chain/coverage limitations, which prevents a perfect score.
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%, so the schema already documents data, value, intent, and contract at a basic level. The description adds practical usage detail beyond the schema: it shows how to pass intent:{action:'pay', to, amount}, clarifies that contract is the transaction's `to` field, and reiterates that data is hex calldata. It does not mention the optional value parameter, which keeps it from a 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?
The description gives a specific verb and resource: 'Decodes what a transaction's calldata will actually do' and compares it with declared intent. It even enumerates the supported calldata types (ERC-20 transfer/approve/permit, setApprovalForAll, ownership transfer, native transfer). However, it does not explicitly differentiate itself from sibling tools such as payment_decision or verify_payment_requirements, so the sibling-routing clarity is left to inference.
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 context 'Anti blind-signing' implies the tool should be used before signing a transaction, and the mismatch guidance ('do not sign') reinforces that. But the description never states when to choose this over sibling tools like payment_decision or screen_address, nor does it list alternatives or exclusions. Usage is therefore implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers a different question from address screening. Screening asks whether an address is risky; this asks how much damage the agent on the other side could do if it were talked into something. Returns that party's self-attestation against the OceanAlt Agent Control Baseline, split into two sets that must NOT be conflated: verified_by_oceanalt (enforced by the gateway on every payment — provable) and self_claimed (what they state about their own side — NOT verified by OceanAlt). Most parties have not attested: found:false means no information, not a bad signal.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | No | The counterparty's entity name. | |
| agentId | No | Their agent id, if you have that instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds substantial behavioral context: it distinguishes verified_by_oceanalt from self_claimed, explains verifiability, and warns that found:false means no information rather than a negative signal. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it differentiates the tool, explains the return structure, and provides important interpretation guidance. No filler or repetition.
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 adequately covers what is returned, how to interpret the two sets, and the meaning of found:false. It gives the agent enough context to call the tool correctly and act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both entity and agentId are already documented. The description does not add new parameter-specific meaning, 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 it answers a distinct question from address screening and identifies the resource as the counterparty's self-attestation against the OceanAlt Agent Control Baseline. The purpose is specific and clearly differentiated from the sibling tool screen_address.
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 title gives a clear use context ('before paying') and the description explicitly contrasts when to use this tool versus address screening. It does not mention other siblings like payment_decision, but the guidance for the main alternative is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
"Before your agent pays, call OceanAlt once." Pass the payee address the agent is about to pay; get a machine-executable decision: allow | review | decline, plus verifiable evidence and retry semantics — use it as a gate: if the decision is not "allow", do not pay. On allow/review it also returns a verifiable compliance attestation you can attach to the settlement so the payment carries proof it passed OceanAlt's decision. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Payee address the agent is about to pay. EVM: 0x + 40 hex. Tron: T + 33 base58. | |
| lang | No | Language for human-readable fields (signals, note, advice). Defaults to English. | |
| network | No | EVM chain for the payee (optional; ignored for Tron). | |
| purpose | No | Short purpose/memo (optional). | |
| amountUsdc | No | Amount in USDC (optional; recorded, not required for the decision). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: it returns a machine-executable verdict, includes verifiable evidence and retry semantics, and provides a compliance attestation on allow/review. It also discloses that the service is free and requires no API key. This exceeds what annotations alone 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 description is compact and front-loaded with the critical directive: call it before paying. Every sentence contributes a distinct piece of information: decision types, gate behavior, attestation, and cost/access constraints. There is 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?
There is no output schema, so the description carries the burden of explaining return semantics. It covers the decision enum, evidence, retry semantics, and attestation, which is sufficient for an agent to invoke the tool and interpret its result. The required parameter is obvious and the optional parameters are already fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents all five parameters. The description adds context for the payee address as the key gate input, but it does not add meaningful semantic detail for lang, network, purpose, or amountUsdc beyond what the schema provides. 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 clearly identifies the tool as a pre-payment decision gate: call OceanAlt, get an allow/review/decline decision, and do not pay unless allowed. This is specific and actionable, but it does not explicitly differentiate itself from the sibling tools recent_flagged and screen_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong when-to-use guidance: call it before paying, and treat non-'allow' results as a hard block. It does not mention alternatives or explicitly state when not to use the tool, but the gate semantics are clear enough for an agent to apply correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a representative sample of addresses on OceanAlt's reviewed risk list — OFAC-sanctioned, known mixers, and community-reported scam/phishing — each with its source category and reason. Takes no arguments. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds practical behavioral context beyond the annotation: it returns a 'representative sample' rather than an exhaustive list, includes source category and reason per address, and emphasizes the free/no-key nature. This is meaningful added transparency for agent decision-making.
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 compact and front-loaded: the first sentence states purpose and output contents, and subsequent short clauses cover constraints and access. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no input params, no output schema, and annotations already cover safety, the description provides enough context: what is returned, what categories are included, and that it is a sample. It also clarifies access requirements, making the tool self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already communicates this fully; the description reinforces it with 'Takes no arguments.' Since there are no parameter details to clarify, the baseline for a zero-parameter tool 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?
Description clearly states a specific action ('Return') on a specific resource (OceanAlt's reviewed risk list), enumerating the categories of addresses and the per-item contents. It stands apart from the sibling screen_address tool because it provides a sample list rather than screening a single address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: no arguments are required and no API key is needed, making this an easy entry point. It does not explicitly name alternatives or say when not to use it, but for a zero-parameter read tool the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves who stands behind a paying agent: agent -> principal -> mandate -> credential -> wallet. Each link reports whether it holds; completeness counts how many do (a factual count, not a score). Wherever the chain breaks is where accountability stops. Publication is opt-in and only posture is exposed (that a ceiling exists, never its value), so found:false means the agent has not published — absence of information, not a bad signal.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | The agent id to resolve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/open-world/idempotent annotations, the description adds crucial interpretation: each link reports 'whether it holds,' completeness is 'a factual count, not a score,' publication is opt-in, and 'found:false' means absence of information rather than a negative signal. This prevents misuse and misreading of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the first states the chain, the second clarifies the output semantics, and the third explains the meaning of a missing result. It is front-loaded with the core action and stays dense without 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 one simple parameter, rich annotations, and no output schema, the description fully covers what an agent needs: the chain being resolved, how to interpret link status and completeness, and the meaning of found:false. Nothing critical is missing for calling 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% for the single required agentId parameter, so the baseline is 3. The description adds a little color by framing the agent as a 'paying agent,' but it does not materially extend the schema's parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it 'Resolves who stands behind a paying agent' and enumerates the chain (agent -> principal -> mandate -> credential -> wallet). This clearly distinguishes it from sibling tools centered on payment decisions, screen addresses, and flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for investigating an agent's accountability chain, but it does not explicitly state when to prefer it over the listed siblings or mention exclusion criteria. The intended use is clear from context but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an AML compliance screen on a single blockchain address BEFORE paying or receiving from it — the answer to "is this counterparty safe?". Checks OFAC sanctions, known mixers, community scam/phishing lists, stablecoin issuer freezes, and on-chain heuristics. Returns a verdict (clear | caution | risky), a 0–100 risk score, a blocked flag, and the matching signals — receipts, not a black-box score. Supports EVM (0x…), Tron (T…), Solana (base58). Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for human-readable fields (signals, note, advice). Defaults to English. | |
| address | Yes | Address to screen. EVM: 0x + 40 hex. Tron: T + 33 base58. Solana: base58 public key. | |
| network | No | EVM chain (optional; auto-defaults to ethereum; ignored for Tron/Solana). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a read-only, idempotent, open-world operation, and the description adds substantial non-redundant detail: the exact screening sources, the return shape (verdict, 0–100 score, blocked flag, matching signals), and the 'receipts, not a black-box score' behavior. There is no contradiction with 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?
Four purpose-driven sentences: when to use, what it checks, what it returns, and what formats/access constraints apply. Information is front-loaded and every sentence contributes.
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 explanation and delivers it clearly: verdict, risk score, blocked flag, and signals. It also covers supported networks and cost/authentication constraints, so an agent has enough context 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?
The schema already covers all parameters at 100% coverage, including address format details and enum options, so the description adds little parameter-specific information. It reinforces address format support in plain language but does not deepen meaning 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 opens with a concrete action, 'Run an AML compliance screen on a single blockchain address,' and frames it as the safety check before payment. It names the exact screening sources (OFAC sanctions, mixers, scam lists, stablecoin freezes, on-chain heuristics) and supported address formats, making it easy to distinguish from siblings like payment_decision and recent_flagged.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use the tool: 'BEFORE paying or receiving from it,' with the question 'is this counterparty safe?' as the trigger. It does not explicitly name alternatives or state when not to use it, so it stops short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a payment ENDPOINT (URL or domain) before calling it — the half that address screening cannot answer. In x402 the agent discovers a URL first, receives a 402, and only then learns where to pay: if that endpoint is spoofed, the payee address it hands back is freshly generated and appears on no sanctions list. Checks the hostname and its parent domains against public phishing databases (MetaMask eth-phishing-detect, ScamSniffer) plus hostname shape signals (bare IP, punycode homograph, deep subdomain nesting, free hosting). Returns clear | caution | risky | unknown with language-independent signal_keys. A clear verdict means no match was found, NOT that the endpoint is safe — freshly registered phishing hosts always precede any list. Use together with screen_address. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL or bare domain of the payment endpoint, e.g. https://pay.example.com/x402 or pay.example.com | |
| lang | No | Language for human-readable fields. Defaults to English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already marking readOnly, openWorld, and idempotent, the description adds substantial behavioral context: checks hostname and parent domains against specific public databases, uses hostname shape signals, returns clear | caution | risky | unknown with language-independent signal_keys, and explicitly warns that a clear verdict does not mean safe. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a one-liner but every sentence earns its place: purpose, workflow context, checks performed, verdict output, important caveat, companion tool, and cost/auth note. The main purpose and differentiation are front-loaded.
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 explains the output vocabulary (clear | caution | risky | unknown) and signal_keys. It also covers the key caveat ('NOT that the endpoint is safe'), free usage, no API key requirement, and input format via the schema. An agent has enough to call it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both url and lang. The description's contextual framing of the endpoint as a payment endpoint is helpful, but it does not add parameter-level meaning beyond what the schema provides, which matches the 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 opens with a specific verb and resource: 'Screen a payment ENDPOINT (URL or domain) before calling it.' It immediately distinguishes itself from address screening and names the complementary sibling screen_address, so an agent can tell exactly what this tool covers.
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 situational context: in x402 the agent discovers a URL, receives a 402, and then must screen the endpoint before paying. It also states 'The half that address screening cannot answer' and 'Use together with screen_address,' providing clear when-to-use and companion-tool guidance.
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 402 response, check that its payment requirements (payTo, amount, asset, network, resource) were signed by the seller and not altered in transit by a proxy, CDN, SDK or another tool. x402 v2 carries the requirements in the PAYMENT-REQUIRED response header (base64 JSON): pass either the decoded JSON or the raw base64 value as body. Optionally pass expect:{payTo, amount} — the address and amount you are about to pay — and the tool also checks they match what was signed. verified:false with reason_code no_signature means the seller does not sign (unprotected, not necessarily malicious); digest_mismatch or signature_invalid means the response was tampered with — do not pay.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The decoded PAYMENT-REQUIRED header JSON (object), or the raw base64 header value (string). | |
| expect | No | What you are about to pay; checked against the signed fields. | |
| keys_url | No | Override the seller's public-key URL (defaults to extensions.signedRequirements.keys_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, idempotentHint, openWorldHint), and the description adds substantial extra context: the meaning of reason_code values (no_signature = unprotected but not necessarily malicious vs digest_mismatch/signature_invalid = tampered), and what verified:false implies. This is behaviorally rich beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the decision-relevant rule ('before paying...'), then input mechanics, then failure semantics. Some sentences are dense and long, but nearly all content earns its place; minor tightening possible in the x402 v2 header explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it explains verified:false, reason_code variants, and the required action. Combined with the accept-either-JSON-or-base64 input guidance, an agent has everything needed to call and interpret 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 coverage is 100%, so the baseline is 3, but the description adds meaning to 'expect' beyond the schema: it is what you are about to pay and is matched against the signed fields, plus it clarifies x402 v2 carries requirements in the PAYMENT-REQUIRED header. The keys_url default behavior is largely already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: verifying that x402 402 payment requirements (payTo, amount, asset, network, resource) were signed by the seller and not tampered with. It clearly distinguishes itself from sibling tools like payment_decision and screen_address by scoping to signature/tamper verification of the response itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames usage: 'Before paying an x402 402 response, check that...' and gives actionable interpretation ('do not pay' on digest_mismatch/signature_invalid). It does not name alternative sibling tools (e.g. payment_decision) or state when to skip this step, so it falls short of full when/when-not/alternatives coverage.
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.
verify_payment_requirements2 fields changedInput schema / properties / body / descriptionPrevious value: -"The 402 response JSON exactly as received."New value: +"The decoded PAYMENT-REQUIRED header JSON (object), or the raw base64 header value (string)."Input schema / properties / body / typeRemoved value: -"object"check_calldata_intentverify_payment_requirementsattest_control_baselinebaseline_controlsscreen_endpointcounterparty_control_baselineresolve_agent_identitypayment_decision1 field changedInput schema / properties / langAdded value: +{
+ "description": "Language for human-readable fields (signals, note, advice). Defaults to English.",
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+}screen_address1 field changedInput schema / properties / langAdded value: +{
+ "description": "Language for human-readable fields (signals, note, advice). Defaults to English.",
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+}payment_decisionrecent_flaggedscreen_addressOFAC sanctions screening for AI agents: screen names, wallets, entities against the SDN list.
KYC, KYB, AML, wallet screening, transaction monitoring, and fraud workflows for AI agents.
Address validation & geocoding for AI agents: 240+ countries, UK PAF, free US/CA enrichment
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Add one secure layer between your agents and this server.
