Pre-payment checks for AI agents: sanctions and AML screening of payees, payment pages and requests.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Most tools target distinct artifacts or workflow stages: messages, endpoints, addresses, calldata, x402 requirements, identity, control baselines, and evidence. The main overlap is that payment_decision and evidence_bundle both incorporate address-screening information, and screen_address sits close to the broader payment_decision gate, but the descriptions explicitly clarify these boundaries.
All names use snake_case, but the set mixes verb-first names (screen_address, verify_payment_requirements, check_payment_request) with noun-first names (baseline_controls, evidence_bundle, payment_decision) and one noun-verb ordering (payee_decide). The pattern is still readable, but it is not a consistent verb_noun convention throughout.
At 13 tools, the set is well within the appropriate range for a multi-layered AML/payment-safety workflow. Each tool covers a recognizable stage or artifact, and the count does not feel padded or thin.
The surface covers payer and payee perspectives, address and endpoint screening, payment-message phishing checks, calldata intent decoding, x402 requirement verification, identity resolution, control-baseline attestation, and signed evidence bundles. For the apparent domain of pre-payment AML and agent-payment compliance, there are no obvious dead ends in the core workflows.
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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true); the description adds real context beyond them: no account or key required, one call, the filing is published to payers, and gaps are permitted. It does not say what happens on re-filing — whether a second attestation replaces or coexists with the first — which matters given idempotentHint=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 identity of the tool and its sibling contrast, then workflow and preconditions. Every sentence carries a distinct instruction; 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?
Covers purpose, prerequisites, authorization, and the gap-tolerance policy for a 5-parameter write tool with a nested object. The one gap is the absence of an output schema combined with no description of what the filing returns (an id, a link, a verification status), which an agent may want to confirm success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description still adds meaning by tying 'answers: false' to the gapPlan field and directing the agent to baseline_controls for control ids. It gives no hints on the shape of the answers map 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 ('file your operator's control-baseline attestation') and immediately positions it against the sibling counterparty_control_baseline by contrasting whose controls are published. An agent can pick between 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?
Gives explicit sequencing ('get the control ids from the baseline list first'), an authorization precondition ('only file for a party you are actually authorised to speak for'), and the when-to-use rationale (payers see it before settling). It also covers the awkward case of partial compliance rather than leaving it ambiguous.
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, idempotentHint and destructiveHint=false; the description adds the cost profile ('free' in title/description) and the per-item payload semantics (each control carries the enforcing gate and its rationale). It does not state pagination, ordering, or total count, which are the remaining behavioral unknowns for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the resource identification, followed by the ordering directive and a note on record contents. No filler and no repetition of annotation-declared safety traits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what comes back; it does so at a high level (a list of yes/no controls, each with enforcing gate and rationale) and marks the tool as free. The exact field names (e.g., control id, question text) are implied but not enumerated, a minor gap for a zero-param call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. The description correctly does not invent parameter discussion, keeping focus on what the call returns.
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 ('Fetch') and a well-defined resource ('the OceanAlt Agent Control Baseline'), and immediately defines what that resource is: the list of yes/no controls an operator must run before moving money. It is clearly distinguished from the sibling attest_control_baseline, which it names as the downstream step.
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 instructs 'Call this before attest_control_baseline so you file against real control ids,' giving a concrete ordering rule and the reason for it. It stops short of naming exclusion cases (e.g., when a cached baseline is acceptable), but the sequencing guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Anti blind-signing. EVM: decodes what a transaction's calldata will actually do (ERC-20 transfer/approve/permit, setApprovalForAll, ownership transfer, native transfer). Solana: decodes a whole base64 transaction (SPL Token / Token-2022 Transfer, TransferChecked, Approve, SetAuthority, CloseAccount, Burn; System Transfer / Assign; ATA creation). Compares it with what you believe you are doing. EVM: pass intent:{action:'pay', to, amount} plus contract (the transaction's to) and data (hex calldata). Solana: pass network:'solana' and transaction (base64) instead of data. decision match = does what you declared; mismatch = different recipient/amount/asset, or an approval / authority change instead of a payment — do not sign; unknown = could not decode (including address-lookup-table accounts), which is not the same as safe.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | EVM only: 0x-prefixed hex calldata. | |
| value | No | EVM only: native value in wei (optional). | |
| intent | No | ||
| network | No | 'solana' to decode a Solana transaction; EVM chain name or CAIP-2 id otherwise (optional). | |
| contract | No | EVM only: the transaction's `to` field (token contract for ERC-20 payments, or the recipient for native transfers). | |
| transaction | No | Solana only: base64-serialized transaction or message. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent; the description adds the decision taxonomy (match / mismatch / unknown) and the critical caveat that unknown includes address-lookup-table accounts and is not a safety signal. That is genuine behavioral context an agent needs before trusting the result, though output shape beyond 'decision' is not described.
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 four words, and the long parenthetical lists of supported opcodes are skimmable and earn their space by defining decode coverage. Slightly dense with semicolon-chained clauses, but no sentence 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?
For a 6-parameter tool with no required params, nested intent object and no output schema, the description covers mode selection, parameter meaning and the interpretation of the returned decision. It would be stronger if it stated that parameters are conditionally required per mode (nothing is marked required 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?
Schema coverage is 83% so the baseline is 3, and the description improves on it by explaining mode-exclusive parameter sets — data is EVM-only, transaction is Solana-only, contract is the transaction's `to` field. It also clarifies intent as a declaration of what you believe you are doing rather than echoing the calldata, which the schema alone does not make obvious.
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 — decode EVM calldata / Solana transactions and compare against declared intent — with the one-line framing 'Anti blind-signing' making the goal plain. It enumerates supported call types, so an agent can tell this apart from siblings like check_payment_request or payment_decision 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?
Gives concrete routing rules: EVM uses intent + contract + data, Solana uses network:'solana' + transaction instead of data. It also states the action consequence ('do not sign' on mismatch) and warns that unknown is not safe. It stops short of naming sibling tools or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this before paying because an email, invoice or chat message asked you to. Pass what you received: raw headers if you have them, the From line, subject and body (or body_html), and the payee address if you already extracted one. OceanAlt checks whether the sender is who it claims to be (SPF/DKIM/DMARC results, a display name that names another domain, Reply-To sent elsewhere), whether the sender domain or any link imitates a brand or is a known phishing host, whether the payee address is listed or differs from previous_pay_to, and whether the text pressures the reader, announces changed payment details, or carries instructions aimed at an AI. Returns allow | review | decline with findings. On decline, do not pay from this message; confirm through a channel you already trust. The text is processed in memory and not stored. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Plain-text body, invoice text or chat message | |
| from | No | The From line, e.g. "Acme Billing" <billing@acme.com> | |
| lang | No | Language for human-readable fields. Defaults to English. | |
| pay_to | No | The payee address the message asks you to pay, if you already extracted it | |
| headers | No | Raw email headers, if available (needed to check SPF/DKIM/DMARC) | |
| network | No | Network of pay_to, e.g. base, ethereum, tron, solana | |
| subject | No | ||
| reply_to | No | The Reply-To line, if any | |
| body_html | No | HTML body, if available (lets OceanAlt compare link text with where links really go) | |
| previous_pay_to | No | The address you paid this requester last time, if any | |
| expected_sender_domain | No | The domain this requester normally sends from, if you know it |
| Name | Required | Description |
|---|---|---|
| decision | No | |
| findings | No | |
| reason_code | No | |
| signal_keys | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context beyond them: the exact evidence sources consulted (SPF/DKIM/DMARC, display name vs. domain, Reply-To, link text vs. destination, prior payee), the three-way verdict shape, privacy handling ('processed in memory and not stored'), and the cost/auth profile ('Free, no API key'). That is the kind of detail that lets an agent anticipate both the output and the 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-loaded with the triggering condition and every sentence carries information—checks, inputs, verdicts, and the no-pay instruction. It is a single dense block of roughly 150 words; light structuring of inputs vs. checks vs. outputs would read faster, but there is no filler to cut.
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 an 11-parameter read-only screening tool, the description covers the trigger, the meaningful inputs, the analysis performed, the return verdicts, privacy, and the required agent action on decline. An output schema exists and the return values are still summarized in prose, so nothing an agent needs to invoke or act on the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 91%, so the schema carries most of the load; the description nonetheless adds meaning by explaining what to pass ('raw headers if you have them, the From line, subject and body (or body_html)') and why (headers enable SPF/DKIM/DMARC, body_html enables link-text comparison). It doesn't cover network, previous_pay_to, or expected_sender_domain semantics in the description, which prevents 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?
States a specific verb and resource ('check_payment_request' / check a payment request before paying) and immediately scopes it to messages that ask for payment. The listed checks (sender authenticity, domain/brand imitation, payee match, pressure language) make it clearly distinct from siblings like payee_decide, screen_address, and verify_payment_requirements.
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 ('call this before paying because an email, invoice or chat message asked you to') and an explicit follow-up rule ('on decline, do not pay from this message; confirm through a channel you already trust'). It doesn't name when to skip this tool or which sibling to use instead, which keeps it 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.
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?
Annotations already cover read-only, idempotent, non-destructive, open-world, so the bar is lower, but the description still adds valuable disclosure: the two return sets must NOT be conflated, and it explains what each set proves. Critically it pre-empts a likely misinterpretation by stating found:false means no information rather than a negative signal.
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 differentiator in sentence one, then explains the return shape and the false-negative trap. No sentence is filler; the length is justified by the misinterpretation risk it defuses.
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 carries the return semantics (two sets, found:false meaning) — a strong compensation. The gap is that with zero required parameters it never says whether the call can be made with neither entity nor agentId, nor what to do if both are supplied.
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 carry their own description, so the schema does the work. The tool description adds nothing about entity vs agentId, including whether either is required or whether both may be supplied — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and return: the counterparty's self-attestation against the OceanAlt Agent Control Baseline. It explicitly distinguishes itself from address screening in the first two sentences, so an agent can route between this and screen_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 a clear semantic contrast to the screening tools ('whether an address is risky' vs 'how much damage the agent could do'), which functions as a when-to-use rule. It stops short of naming the sibling write tool attest_control_baseline or baseline_controls, so the boundary with those two 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.
Everything OceanAlt holds about an address as public facts, in one Ed25519-signed bundle you can verify offline: screening verdict with evidence and freshness, profile signals, one-hop relations to listed addresses, fulfillment receipt stats and coverage. A witness, not a prosecutor: no conclusions about people. Same as GET https://oceanalt.com/api/evidence/bundle.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| network | No | EVM chain name (optional, default ethereum). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the description's job is added context — and it delivers: Ed25519 signature, offline verification, included freshness metadata, and the important interpretive caveat that it is 'a witness, not a prosecutor: no conclusions about people.' It omits auth requirements, rate limits, and behavior for unknown/unindexed addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core deliverable and a tight enumeration of contents; the shorthand URL and the 'witness, not a prosecutor' line both earn their place. 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?
With no output schema, the description carries the burden of describing returns, and it does so field-by-field plus a verification guarantee. Remaining gaps are minor: response encoding, error/not-found behavior, and whether results are cached or time-bounded.
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 50%: network is documented in the schema as an EVM chain name defaulting to ethereum, while address is an unannotated string. The description does not clarify the accepted address format (hex EVM address vs. other identifiers) or how address and network interact, so it adds little 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 concrete resource ('everything OceanAlt holds about an address') and enumerates the payload (screening verdict, freshness, profile signals, one-hop relations, receipt stats, coverage), so an agent knows exactly what comes back. It implicitly differentiates from the narrower sibling screen_address by breadth, though it never names that sibling directly.
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: you call it when you want the full verifiable dossier for one address rather than a single verdict. There is no explicit when-to-use/when-not, no mention of when the cheaper screen_address call suffices, and no guidance on the free-tier limits despite 'free' appearing in the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The receiving side's check before settlement. Given the payee's registry id (sid) and, optionally, the payer, amount and purpose, returns accept / decline / hold_request_info / not_ready with reason codes, the fields to request, evidence and a signature. Rule-based, not a model's opinion. Same logic as POST https://oceanalt.com/api/payee/decide.
| Name | Required | Description | Default |
|---|---|---|---|
| payee | Yes | The payee's registry id (sid). | |
| payer | No | Who is paying (optional). | |
| network | No | Chain of the payment (optional). | |
| purpose | No | What the payment is for (optional). | |
| amountUsdc | No | Amount in USDC (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: the decision is rule-based rather than a model's opinion, and the response carries reason codes, requested fields, evidence and a signature, plus a reference to the equivalent HTTP endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, with the core purpose and the enumeration of return states front-loaded so the agent reads the important part first. The endpoint URL is marginally useful but slightly noise.
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 listing the four decision outcomes and the accompanying artifacts (reason codes, fields to request, evidence, signature). The deterministic rule-based nature is also disclosed. Only minor gaps remain, such as error or not-found behavior.
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 each of the five fields is already documented in the schema. The description restates the optionality of payer, amount and purpose and the sid meaning without adding format or validation 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 ('the receiving side's check before settlement') and clearly frames which side of the transaction it decides for, which separates it from the payer-side siblings like payment_decision and check_payment_request. It even enumerates the possible outcomes the tool produces.
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 phrase 'before settlement' establishes the timing context and 'receiving side' establishes the role, so an agent knows when to reach for it. It does not, however, explicitly name a sibling alternative or state a when-not condition, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this before every payment your agent makes. Free, no signup, no API key. To see it work first, call it with {"to":"0xd90e2f925DA726b50C4Ed8D0Fb90Ad053324F31b","network":"ethereum"}: that address is a known mixer, so the answer is decline with the matching list as evidence. 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. Pass resource_url (the URL that returned the 402 quote) and OceanAlt also asks that site for its own payment quote: if the quote names a different payee, or the site cannot be checked, the decision is raised to review. A match only shows the site and the payee agree; it is not an endorsement of the seller. Every decision carries a receipt signed with Ed25519 that you can verify offline with the public key at https://oceanalt.com/.well-known/oceanalt-keys.json. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Payee address the agent is about to pay: 0x (EVM), T… (TRON), Solana, Bitcoin or r… (XRP Ledger); list matching only: Monero (4…/8…), Bitcoin Cash (q…/p…, optional bitcoincash: prefix), Litecoin (ltc1…) or BNB Beacon Chain (bnb1…). | |
| lang | No | Language for human-readable fields (signals, note, advice). Defaults to English. | |
| task | No | Optional payment intent: what this payment is for. Sending task, reasoning or maxAmountUsdc opts into a deterministic intent check; an empty intent is itself a finding (requires_information). | |
| network | No | EVM chain, only for a 0x address. Leave it out for Tron, Solana, Bitcoin and XRP Ledger addresses: the chain is detected from the address. | |
| purpose | No | Short purpose/memo (optional). | |
| reasoning | No | Optional payment intent: why this payee. Instruction-override phrases here route the payment to review. | |
| amountUsdc | No | Amount in USDC (optional; recorded, not required for the decision). | |
| resource_url | No | Optional: the http(s) URL of the paid resource, i.e. the URL that returned the 402 payment quote. OceanAlt asks that origin for its own quote and checks whether it names this payee (origin binding). | |
| maxAmountUsdc | No | Optional declared per-payment cap in USDC. amountUsdc above it → decline. |
| Name | Required | Description |
|---|---|---|
| code | No | Input error code, e.g. unknown_network, network_address_mismatch, unparsable_url. |
| lang | No | |
| note | No | |
| risk | No | Rounded to 10 when detail_level is coarse. |
| allow | No | if (!allow) do not pay. |
| error | No | Present only on an input error (isError: true). |
| retry | No | |
| cached | No | |
| address | No | |
| blocked | No | |
| receipt | No | Ed25519-signed decision receipt: { signed, signature_ed25519, note }. Verify with https://oceanalt.com/.well-known/oceanalt-keys.json. |
| signals | No | Human-readable. Do not branch on these. |
| verdict | No | clear means no match in the data held, not that it is safe. uncertain must never be treated as clear. |
| decision | No | |
| evidence | No | |
| standard | No | |
| risk_band | No | |
| retry_hint | No | |
| settlement | No | |
| detail_note | No | |
| reason_code | No | Stable reason code; table at https://oceanalt.com/api/contract. |
| signal_keys | No | Language-independent keys. Branch on these. Full list at https://oceanalt.com/api/contract. |
| detail_level | No | |
| evaluated_at | No | |
| intelligence | No | |
| intent_check | No | |
| signal_class | No | |
| evidence_as_of | No | |
| origin_binding | No | |
| evidence_oldest | No | |
| screening_scope | No | Present only for list-only chains: coverage is list_only, no on-chain analysis is performed. |
| screened_network | No | |
| accepted_networks | No | |
| payee_fulfillment | No | |
| requires_information | No | |
| evidence_qualification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it describes the three outcome values, the verifiable evidence and retry semantics returned, the compliance attestation attached on allow/review, and the origin-binding check on resource_url that can escalate a decision to review. It also discloses that every decision carries an Ed25519-signed receipt verifiable offline against a named public key URL, and warns that a payee/site match is not an endorsement. Annotations only say readOnly/idempotent/openWorld; the description supplies the substantive behavioral contract without contradicting them.
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 essential instruction is front-loaded in the first two sentences, which is good. But the description runs long for a tool with a fully documented schema and output schema, and 'Free, no API key' is repeated at the start and again verbatim at the end, which is pure waste. Some of the middle material (attestation, origin binding) duplicates what the schema and output schema already convey.
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?
An output schema exists, so return values need not be enumerated, and the description still covers the decision vocabulary, evidence, attestation, receipt verification path, and the escalation logic. Combined with readOnly/idempotent annotations and 100% parameter descriptions, there is nothing an agent needs in order to call this correctly that 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 the schema already explains to, network, resource_url, task, reasoning, amountUsdc and maxAmountUsdc, including the decline-when-over-cap rule and the intent-check opt-in. The description restates 'pass the payee address' and 'pass resource_url (the URL that returned the 402 quote)' but adds no syntax or format detail the schema lacks. Baseline 3 is correct when the schema carries the parameter burden.
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: pass a payee address and get a machine-executable allow|review|decline decision. The core operation is instantly clear and the three-outcome vocabulary is spelled out. It does not, however, distinguish itself from close siblings such as payee_decide, screen_address, or check_payment_request, so an agent cannot tell from this text alone which of these to reach for.
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 trigger ('Call this before every payment your agent makes') and an explicit gating rule: if the decision is not 'allow', do not pay. It even supplies a ready-made test invocation with a known mixer address so the agent can confirm expected behavior. It stops short of naming when NOT to use it or which sibling supersedes it, so there is no exclusion guidance.
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 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 it a read-only, open-world, non-destructive call. The description adds real value on top: it discloses that the response is a representative sample, that each entry carries a source category and reason, and that access is free with no API key. Sample size and refresh cadence remain 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?
Two compact sentences, front-loaded with what is returned and followed by the no-argument and no-cost notes. 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?
With no parameters and no output schema, the description supplies enough to call the tool correctly and describes the shape of each returned item. It falls short only on factors like sample size, pagination, and how 'recent' is defined.
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 the baseline is 4. Saying 'Takes no arguments' confirms the empty schema rather than adding new meaning, which is consistent but not enriching.
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?
It names a specific verb and resource — returning a representative sample of addresses from OceanAlt's reviewed risk list — and enumerates the included categories (OFAC-sanctioned, mixers, scam/phishing). This clearly separates it from the screening and decision tools among its 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?
The description implies the tool is for browsing example risky addresses, but it never states when to choose it over screen_address or the other screening siblings, nor any exclusions. 'Takes no arguments. Free, no API key' gives context but not usage routing.
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 annotations (readOnly, idempotent, non-destructive), the description discloses that publication is opt-in, only posture is exposed (a ceiling exists but never its value), and that found:false means not published rather than a negative signal. It stops short of describing rate limits or the exact response shape, but covers the key interpretive traps.
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 chain structure is front-loaded in the first sentence and each later sentence adds distinct behavioral meaning (count semantics, break meaning, opt-in posture, found:false). 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?
With no output schema, the description carries the burden of explaining return values and does so conceptually: per-link holds, a completeness count that is factual not a score, the break point, and found:false semantics. Exact field names or shape are not given, which is the only 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?
There is a single parameter with 100% schema coverage, so the baseline is 3. The description adds nothing about agentId format or id semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: it resolves who stands behind a paying agent by walking the chain agent -> principal -> mandate -> credential -> wallet. That structural framing lets an agent tell it apart from the sibling verification/screening tools 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 scope ('a paying agent') implies when to reach for it, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. Usage must be inferred from context rather than stated.
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 pre-payment check on a counterparty. Checks OFAC sanctions, known mixers, scam and 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. A clear verdict means nothing was found in the data OceanAlt holds; it is not a statement that the address is safe. Depth varies by chain (see coverage.chains at /.well-known/agent-capabilities). Supports EVM (0x…), Tron (T…), Solana, Bitcoin and XRP Ledger (r…); Monero, Bitcoin Cash, Litecoin (ltc1) and BNB Beacon (bnb1) by list matching only. 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. Bitcoin: bc1… / 1… / 3…. XRP Ledger: r…. List matching only: Monero (4…/8…, 95 chars), Bitcoin Cash (q…/p…, optional bitcoincash: prefix), Litecoin (ltc1…), BNB Beacon Chain (bnb1…). | |
| network | No | EVM chain (optional; auto-defaults to ethereum; ignored for Tron, Solana, Bitcoin and XRP Ledger). |
| Name | Required | Description |
|---|---|---|
| code | No | Input error code, e.g. unknown_network, network_address_mismatch, unparsable_url. |
| note | No | |
| risk | No | Rounded to 10 when detail_level is coarse. |
| error | No | Present only on an input error (isError: true). |
| retry | No | |
| cached | No | |
| blocked | No | |
| signals | No | Human-readable. Do not branch on these. |
| verdict | No | clear means no match in the data held, not that it is safe. uncertain must never be treated as clear. |
| evidence | No | |
| provider | No | |
| risk_band | No | |
| retry_hint | No | |
| detail_note | No | |
| reason_code | No | Stable reason code; table at https://oceanalt.com/api/contract. |
| signal_keys | No | Language-independent keys. Branch on these. Full list at https://oceanalt.com/api/contract. |
| detail_level | No | |
| evaluated_at | No | |
| signal_class | No | |
| evidence_as_of | No | |
| evidence_oldest | No | |
| screening_scope | No | Present only for list-only chains: coverage is list_only, no on-chain analysis is performed. |
| screened_network | No | The chain actually screened: tron, solana, bitcoin and xrpl follow the address format; an 0x address uses network, or ethereum when none was given. List-only chains (monero, bitcoin-cash, litecoin, bnb-beacon, and dogecoin, dash, zcash etc. for list hits) are named here and described in screening_scope. |
| accepted_networks | No | |
| requires_information | No | |
| evidence_qualification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnly/idempotent/openWorld; the description adds substantially: verdict enum, 0–100 score, blocked flag, matching signals, and a critical negative caveat that a clear verdict is not a safety guarantee. It also discloses per-chain depth variance and which chains are list-match-only, plus that it is free with no API key.
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 and the verdict/return summary, then the caveats and chain support. Every sentence carries information, though the long chain-format enumeration overlaps with the schema's address description 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?
For a screening tool with an output schema, the description still summarizes the verdict, score, blocked flag, and signals, and explains the decisive interpretive limit of a clear verdict. An agent has everything needed to call it and to report results responsibly.
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 explains address formats, network enum, and lang. The description adds the chain-depth caveat pointing at coverage.chains, which is useful context but not parameter-level 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+resource (AML screen on a single blockchain address) and anchors it to a concrete moment: the pre-payment counterparty check. It names the exact data sources checked and the return shape, so an agent can distinguish it from siblings like screen_endpoint or check_payment_request 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?
Explicitly says when to call it: BEFORE paying or receiving from an address. The chain-support notes and the 'list matching only' caveat give practical preconditions. It stops short of naming alternative tools or when to prefer them, so it falls below a 5.
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 phishing-domain intelligence 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. |
| Name | Required | Description |
|---|---|---|
| code | No | Input error code, e.g. unknown_network, network_address_mismatch, unparsable_url. |
| host | No | |
| note | No | |
| risk | No | Rounded to 10 when detail_level is coarse. |
| error | No | Present only on an input error (isError: true). |
| input | No | |
| retry | No | |
| signals | No | Human-readable. Do not branch on these. |
| verdict | No | clear means no match in the data held, not that it is safe. uncertain must never be treated as clear. |
| evidence | No | |
| imitates | No | Present when the host imitates a known brand. |
| listed_as | No | Present when the host or a parent domain is on a phishing list: source, label, firstSeen, lastSeen, delistedAt. |
| risk_band | No | |
| retry_hint | No | |
| detail_note | No | |
| reason_code | No | Stable reason code; table at https://oceanalt.com/api/contract. |
| signal_keys | No | Language-independent keys. Branch on these. Full list at https://oceanalt.com/api/contract. |
| detail_level | No | |
| signal_class | No | |
| accepted_networks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, yet the description adds substantive behaviour: parent-domain traversal, the four hostname shape signals, the verdict vocabulary, the free/no-API-key constraint, and the critical caveat that a "clear" verdict means no match was found rather than safety. That negative-result semantics is exactly what an agent needs to avoid over-trusting the output.
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 verb and resource, and every clause carries information (sibling differentiation, workflow, signals, verdict caveat). It is dense and em-dash-heavy, with the x402 background and the safety caveat competing for attention in one paragraph, but nothing is 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?
An output schema exists, yet the description still supplies the verdict enum and the epistemic caveat about fresh phishing hosts — the one thing a schema cannot convey. Combined with the coverage of checks performed and prerequisites (free, no key), an agent can call this correctly and interpret the result responsibly.
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 both parameters including the URL-or-domain flexibility and the lang default. The description restates URL/domain acceptability and indirectly touches lang via "language-independent signal_keys", 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 and resource ("Screen a payment ENDPOINT (URL or domain)") and immediately positions it against the sibling screen_address ("the half that address screening cannot answer"). The x402 discovery flow explains exactly what object is being screened and why.
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 ordering ("before calling it"), names the alternative ("Use together with screen_address"), and explains the scenario that selects this tool: a URL arrives first and the payee address is only revealed afterward. The division of labour between the two screening tools is unambiguous.
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?
Beyond the readOnly/openWorld/idempotent annotations, the description explains key behavioral outcomes: verified:false reason_code no_signature means unprotected but not necessarily malicious, while digest_mismatch or signature_invalid means tampering and must not be paid. It also explains the expected body formats and the optional expect check.
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 action and usage condition, then proceeds to format details, optional checks, and failure interpretation. Every sentence carries security-relevant information without 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?
For a security verification tool with three params and no output schema, the description covers the critical context: where the signed requirements come from, acceptable input forms, optional expected-payment matching, and how to interpret false verification results. Nothing essential for correct invocation or safety 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, but the description adds meaningful semantics beyond the schema: body may be decoded JSON or raw base64 from the PAYMENT-REQUIRED header, and expect checks the payTo/amount about to be paid against signed values. keys_url is only weakly covered in the description, though the schema documents it.
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: verify that an x402 402 response's payment requirements were signed by the seller and not altered in transit. It clearly distinguishes this from generic payment checks by naming the exact fields checked (payTo, amount, asset, network, resource) and the security condition (proxy/CDN/SDK tampering).
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 when-to-use context — before paying an x402 402 response — and explicitly says not to pay when tampering is indicated. It does not name sibling alternatives such as check_payment_request or payment_decision, so it falls short of full when-vs-alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a payee before your agent pays: sanctions, lookalike domains, payment details, invoice fraud.
Sanctions screening, KYB, identifier validation, jurisdiction risk & secret scanning for AI agents
Real-time AML and sanctions screening for agent-to-agent transactions
Screen counterparties and enrich companies for AI agents — sanctions checks, cited sources.
Add one secure layer between your agents and this server.
