Stablecoin escrow payments the buyer can dispute, with a signed receipt. Pay a wallet or an email.
Scored across 6 tools
Most tools occupy clearly distinct lifecycle stages: prepare, settle, check status, verify receipt, generate QR, and read docs. The only mild ambiguity is between check_escrow_payment and verify_escrow_receipt, since both involve checking an escrow-related artifact, but their descriptions distinguish status lookup from signature verification.
The set is consistently snake_case and mostly follows a verb_noun pattern such as prepare_escrow_payment, settle_escrow_payment, and verify_escrow_receipt. payment_qr deviates by being noun-based rather than verb-led, but the deviation is minor and readable.
Six tools is well-scoped for an escrow payment workflow. The set covers preparation, settlement, status checking, receipt verification, QR sharing, and documentation without obvious redundancy.
The core escrow lifecycle is well covered: prepare terms and address, fund/settle, verify the receipt, and check later status. However, there is no direct tool for dispute initiation, refund/claim actions, or cancellation, which are notable gaps in the broader escrow domain even if they may be handled elsewhere.
What has happened to a settled payment, from the status_url on its receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| status_url | Yes | The `status_url` on the receipt settle_escrow_payment returned, as is. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that this applies to a settled payment and requires the receipt's status_url, but it does not add much beyond that structured context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no wasted text. The purpose and source parameter context are delivered efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema and rich annotations, the description provides enough context to call it correctly. It could be slightly improved by explicitly distinguishing it from verify_escrow_receipt.
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 description already explains that status_url comes from settle_escrow_payment's receipt and should be used as is. The description reinforces the source but does not add syntax or format details 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 clearly identifies the resource as a settled payment and the operation as checking its status via a status_url. It distinguishes this from settlement and receipt verification implicitly, but it does not explicitly name the sibling tools it differs from.
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 clear usage context: use this for a settled payment and supply the status_url from its receipt. It does not explicitly state when to use verify_escrow_receipt instead, but the post-settlement status-check context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A scannable code for a payment request, so nobody retypes an address.
Pass the payment_uri from prepare_escrow_payment. Returns a QR a phone wallet can scan,
with the token, network, destination and amount already in it.
Or pass its share_with_payer.pay_link, for a code that opens the payment on the site
instead — what to hand someone who is being asked to pay, as the site's own requests do.
⚠️ A SEPARATE TOOL RATHER THAN PART OF prepare, because the two have different audiences.
prepare answers a machine and has to stay parseable; an image in its result would make
the structured fields something a client has to dig for. A person who needs the code asks
for it.
⚠️ AND IT ENCODES THE URI, NOT THE BARE ADDRESS. A QR holding only an address leaves the amount and the token to be entered by hand, which is the part worth removing — a payment contract funded with the wrong figure is not the payment contract these terms derive to, and the money sits at an address nothing can deploy to.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_uri | Yes | The `payment_uri` prepare_escrow_payment returned, for a code a wallet scans; or its `share_with_payer.pay_link`, for a code that opens the payment page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavior: the result is an image a phone wallet can scan, and it deliberately encodes the full URI rather than a bare address so token, network, destination and amount survive the handoff. It does not specify the image encoding or transport (raw bytes, URL, MIME type), which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the primary input are front-loaded in the first two lines, and both warning blocks carry non-redundant distinctions an agent could otherwise get wrong. It runs long, though: the closing clause about money sitting at an address nothing can deploy to is rhetorical padding that a call-selection decision does not need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the job of describing the return and does so at a useful level (a scannable code for a wallet, or one that opens the payment page on the site). It stops short of naming the actual return shape — image bytes, file reference, or encoded payload — which is the one thing an agent cannot infer before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, so a baseline of 3 applies, but the description adds meaning beyond the schema by spelling out the two semantically distinct values the same string can carry and what each produces downstream. That is real added value for a one-param tool rather than a restatement.
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 produces a scannable QR code for a payment request from a payment URI. It also explicitly distinguishes itself from the sibling tool `prepare_escrow_payment` and explains why it is a separate tool rather than part of `prepare`.
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 the exact input source (`payment_uri` from `prepare_escrow_payment`) and the alternative (`share_with_payer.pay_link`) with the condition that selects each: a wallet-scanned code versus a code that opens the payment page. It also names the audience distinction that tells an agent when this tool should be called instead of `prepare`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out where a payment must go, before anybody signs or sends anything.
seller and nominal_buyer may each be a wallet address OR AN EMAIL ADDRESS — an email is
converted to the wallet that person owns, so you never need to know a wallet to use this.
The parties are checked against the sanctions lists before an address is given. If any of
them is listed the answer is error: sanctioned_party with no address, and the payment
cannot be made through this service. The same answer comes back for terms whose payment
contract was already refused on sanctions grounds when its money arrived: its address is not
handed out again. If the check cannot be done right now the answer is
error: service_unavailable with retryable: true and no address; try again shortly.
Returns the payment address these terms produce, and TWO ways to fund it. Both end at the same address holding the same money; they differ only in who sends the transaction.
Transfer it yourself. Send the tokens to the address from any wallet — a browser
wallet, a hardware wallet, an exchange withdrawal. Nothing to sign for us, and no payer
needed, because the payment contract never asks who paid: it reads its own balance. Then call
settle_escrow_payment with no signature and we create the payment contract around what is there.
Or let us relay it. Pass payer and this returns an EIP-3009 authorization for them to
sign. We broadcast it and pay the gas, so the payer needs no gas at all. This is the
only one an agent can complete unattended, and the only one that needs a key anywhere.
Either way the address is the same, because it is a pure function of the terms. That is
also what makes the relayed form safe: the payer signs to as part of the authorization,
committing to every term at once — alter any of them afterwards and the address moves and
the signature stops matching.
amount is in the TOKEN's base units (1 USDC = 1000000), because that exact figure is one
of the terms the address derives from.
expiry_timestamp is an absolute Unix time — when the dispute window closes. 0 settles
instantly with no recourse. There is no default: "instant, deliberately" and "nobody said"
are different, and a caller must not discover afterwards which one they got.
nominal_buyer is who may dispute and receives a refund. For an agentic payment this should
be the PERSON, not the agent — they are the one who will later read a report and decide
whether to object.
seller and nominal_buyer may each be a wallet address OR an email address. An email
resolves to the wallet Privy holds for that person — made for them if they have never
logged in — and the same email always resolves to the same wallet, so the address derived
here is the one settle_escrow_payment derives too. The resolved wallets come back under
parties. A seller given by email is paid into that wallet; they sign in with the email to
reach it.
external_id keeps two otherwise-identical payments apart, and is one of the terms the
address derives from. Leave it out and a unique one is generated. That is the right
default: two payments matching in seller, amount, maturity and buyer would otherwise derive
to the SAME address, and funding the second sends money into the first payment contract — recoverable
only after that one is claimed, and only to ITS buyer.
⚠️ PASS BACK THE external_id THIS RETURNS, not the one you sent. A generated one is only
knowable from the result, and settle derives the address again from whatever it is given:
a different id is a different address, and the money is at this one.
Supply your own for the opposite behaviour — a checkout hash gives "one checkout, one payment contract", so re-presenting the same purchase returns the same address rather than a second.
description is what the payment is FOR, in the buyer's own words — ask them for it rather
than defaulting. It is what they will be looking at in the dashboard weeks later deciding
whether to dispute, and "Protected payment" tells them nothing about which one this was. It
does not affect the address, so it can be set freely here.
brand is the white-label partner the payment is being made under, if any (the ?b= id,
e.g. escrow-me). It is recorded on the contract for attribution only: it does not affect
the address, and a malformed one is ignored rather than refused.
product_name is what is being bought, shown on both parties' dashboards. Display only, like
brand. A seller or nominal buyer given by email is recorded with that email as well, so the
payment contract shows to them the way a request made on the site does.
⚠️ 1 to 160 characters. Longer is refused HERE rather than at the chain, where the check happens after the money has already moved.
arbiter is who decides a dispute. Leave it out for the default arbiter, which is almost
always right. It is one of the terms the address derives from, so pass the same value to
settle_escrow_payment.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | The white-label partner the payment is made under, if any: the site's `?b=` id, e.g. escrow-me. Attribution only; does not affect the address. | |
| payer | No | Wallet address (0x…) that will sign an EIP-3009 authorization for us to relay, gas-free. Omit when the payer transfers the tokens to the address themselves. | |
| amount | Yes | How much, in the token's base units: 1 USDC = 1000000, so 25 USDC is 25000000. One of the terms the payment address derives from. | |
| seller | Yes | Who gets paid: a wallet address (0x…) OR an email address. An email is converted to the wallet that person owns, created for them if they have never signed in; the same email always gives the same wallet. | |
| arbiter | No | Wallet address (0x…) of who decides a dispute. Omit for the default arbiter. One of the terms the address derives from, so pass the same value to both tools. | |
| description | No | What the payment is for, in the buyer's own words, 1 to 160 characters, e.g. 'Logo design, final files'. Shown on the dashboard; does not affect the address. | Protected payment |
| external_id | No | Your own id for this payment, e.g. a checkout hash, so re-presenting the same purchase derives the same address. Omit and a unique one is generated; pass back the value this returns. | |
| product_name | No | What is being bought, e.g. 'Blue ceramic vase'. Shown on both parties' dashboards; display only. | |
| token_symbol | No | The token to pay in, e.g. USDC. Must be one the service supports. | USDC |
| nominal_buyer | Yes | Who may dispute and receives any refund — the PERSON, not the agent: a wallet address (0x…) OR an email address. An email is converted to that person's wallet, created for them if they have never signed in. | |
| expiry_timestamp | Yes | When the dispute window closes, as an absolute Unix time in seconds, e.g. 1764547200. 0 settles instantly with no recourse. There is no default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond the annotations (`readOnlyHint: false`, `destructiveHint: false`, `openWorldHint: true`), it discloses the sanctions pre-check and its two failure shapes (`error: sanctioned_party` with no address, `error: service_unavailable` with `retryable: true`), that a previously refused contract never re-issues an address, and that the relayed path is the only one that needs a key or can be completed unattended. The warning to pass back the returned `external_id` rather than the one sent is exactly the kind of hidden precondition annotations cannot carry; the only mild tension with `idempotentHint: true` is that the generated default id makes repeat calls derive different addresses, but the description spells that mechanism out rather than hiding it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded, with concrete warnings and the funding-choice tradeoff placed before the per-field notes. It loses a point for redundancy: the wallet-or-email resolution rule is stated three times in near-identical wording (opening, bolded middle paragraph, and again via the schema), and the `external_id` collision risk is explained at greater length than the decision requires.
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, stateful tool with real financial consequences, it covers everything an agent needs: the address-derivation model, both funding routes, error outcomes, the returned-`external_id` handoff, and the next tool to call. Return values are not re-explained, which is correct given an output schema exists.
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 100%, yet the description still adds meaning the schema cannot: `amount` is in token base units because the figure is itself an address term, `expiry_timestamp` of `0` means instant settlement with no recourse and has no default, and `nominal_buyer` must be the person rather than the agent. It also adds cross-call semantics — `arbiter` and `external_id` must match what `settle_escrow_payment` receives — and the 160-character refusal boundary on `description`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the specific job — deriving where a payment must go before anything is signed or sent — and the body pins down the concrete output: a deterministic payment address plus two funding routes. It explicitly separates itself from `settle_escrow_payment` ("Then call `settle_escrow_payment` with no signature and we create the payment contract around what is there"), so an agent can place it in the sibling set 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?
It lays out the two mutually exclusive funding paths and the exact condition that selects each: omit `payer` to transfer directly, or pass `payer` to get an EIP-3009 authorization you relay gas-free. It also states when to supply your own `external_id` versus letting one be generated, and names `settle_escrow_payment` as the necessary follow-up — explicit alternatives, not inferred ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one of the published pages, for answering questions about how any of this works.
Use it rather than guessing. What the fees are, how a dispute is decided and who decides it, what a buyer is agreeing to — all of it is written down, and none of it is safe to invent.
how-it-works How an protected payment works, start to finish faq Common questions about protected payments, fees, disputes and timing arbitration-policy How a dispute is decided, by whom, and on what evidence terms-of-service The terms a buyer and seller are agreeing to privacy-policy What is collected and why plugins The WordPress and Shopify integrations home What the product is and who it is for
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Which page: how-it-works, faq, arbitration-policy, terms-of-service, privacy-policy, plugins or home. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds the meaningful behavioral point that the content is authoritative and must not be invented ('none of it is safe to invent'), which tells the agent to treat the output as ground truth. It stops short of describing freshness, caching, or return shape, but an output schema exists.
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 instruction is front-loaded in the first sentence and the rationale follows immediately. The page table is longer than a bare list but each line earns its place by adding selection semantics; there is mild duplication with the schema enum, which keeps it from a 5.
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?
Single required parameter fully documented, annotations cover the safety profile, and an output schema handles return values. Nothing an agent needs in order to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single param already lists valid values, so baseline would be 3. The description goes further by annotating each page value with what it contains ('How a dispute is decided, by whom, and on what evidence'), which helps the agent pick the right page rather than guessing from a slug.
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 ('Read one of the published pages') and immediately scopes it to answering questions about how the product works. The enumerated page list makes the retrieval domain unambiguous, and it is trivially distinguishable from the sibling payment-operation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it rather than guessing' plus concrete examples ('what the fees are, how a dispute is decided') tells the agent exactly the class of question this tool answers. It does not explicitly state when not to use it or name an alternative, but the sibling tools are transactional operations rather than competing documentation sources, so the routing ambiguity is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create the payment contract around the money and return a signed receipt.
seller and nominal_buyer may be wallet addresses OR EMAIL ADDRESSES, exactly as in
prepare_escrow_payment; an email converts to the same wallet it did there.
Works both ways, and which one runs is decided by whether you pass a signature:
Already transferred it yourself — omit authorization and signature. We check the
address holds the amount and build the payment contract around what is there. If the transfer has not
arrived it says so, and nothing is spent finding out.
Want us to relay it — pass the payer's authorization and signature. We broadcast it
and pay the gas, so the payer needs none. This process holds no key and signs nothing; it
is handed a signature and carries it.
Pass the terms exactly as they were prepared. They ARE the payment contract's address, so a single altered figure moves it — and with a signature, stops matching what the payer signed.
seller and nominal_buyer may be wallet addresses or email addresses, as in
prepare_escrow_payment; an email resolves to the same wallet it did there.
⚠️ external_id MUST BE THE ONE prepare_escrow_payment RETURNED. It generates one when
you leave it out, and that generated value is only knowable from its result — send a
different one and this derives a different address, while the money is at the first.
⚠️ error: sanctioned_party IS FINAL. A party scored above 0 on the sanctions check when the
money arrived (or the payment contract was refused before): the money is frozen at its
address, and nothing more may be paid into it. Do not retry and do not offer to pay again.
⚠️ The receipt reports what the seller will actually RECEIVE in token_amount, with the
platform fee named beside it. That is less than the amount authorised, and the two
reconcile: token_amount + creator_fee = amount.
brand is the white-label partner, as in prepare_escrow_payment: attribution only, and
ignored when malformed.
arbiter, when one was passed to prepare_escrow_payment, must be passed here too: it is a
term, and leaving it out derives the default arbiter's address instead.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | The white-label partner the payment is made under, if any: the site's `?b=` id, e.g. escrow-me. Attribution only; does not affect the address. | |
| amount | Yes | How much, in the token's base units: 1 USDC = 1000000, so 25 USDC is 25000000. One of the terms the payment address derives from. | |
| seller | Yes | Who gets paid: a wallet address (0x…) OR an email address. An email is converted to the wallet that person owns, created for them if they have never signed in; the same email always gives the same wallet. | |
| arbiter | No | Wallet address (0x…) of who decides a dispute. Omit for the default arbiter. One of the terms the address derives from, so pass the same value to both tools. | |
| signature | No | The payer's hex signature (0x…) over that authorization. Omit together with `authorization`. | |
| description | No | What the payment is for, in the buyer's own words, 1 to 160 characters, e.g. 'Logo design, final files'. Shown on the dashboard; does not affect the address. | Protected payment |
| external_id | Yes | The external_id prepare_escrow_payment returned, exactly. A different id derives a different address while the money sits at the first. | |
| token_symbol | No | The token to pay in, e.g. USDC. Must be one the service supports. | USDC |
| authorization | No | The EIP-3009 authorization object prepare_escrow_payment returned for the payer, unchanged. Omit when the payer transferred the tokens themselves. | |
| nominal_buyer | Yes | Who may dispute and receives any refund — the PERSON, not the agent: a wallet address (0x…) OR an email address. An email is converted to that person's wallet, created for them if they have never signed in. | |
| expiry_timestamp | Yes | When the dispute window closes, as an absolute Unix time in seconds, e.g. 1764547200. 0 settles instantly with no recourse. There is no default. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (destructive, non-idempotent, open-world) by disclosing that the service holds no key and signs nothing, that gas is paid on relay, that sanctions errors are final and frozen with no retry, and that a pre-transfer check spends nothing when funds are missing. The fee reconciliation note (token_amount + creator_fee = amount) is behavior an agent cannot get elsewhere.
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 modes and warnings, which is good, but the seller/nominal_buyer email-resolution explanation is stated twice in near-identical wording, and email-to-wallet conversion is restated a third time. Two paragraphs duplicate schema text and could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter destructive tool this covers the full decision surface: two settlement paths, term immutability, external_id derivation risk, sanctions terminal state, fee accounting, and brand/arbiter handling. With an output schema present, it correctly avoids re-specifying the return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still adds cross-parameter semantics the schema only hints at — external_id must be the exact value returned by prepare_escrow_payment or the derived address diverges from where the money sits, and arbiter must be carried over because it is a term, not an optional convenience.
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?
Opens with a specific verb and resource: "Create the payment contract around the money and return a signed receipt." It is clearly distinct from the sibling prepare_escrow_payment, which it explicitly frames as producing the terms this tool consumes.
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 branches the two invocation modes with the deciding condition ("which one runs is decided by whether you pass a signature"), naming when to omit authorization/signature versus when to pass them. It also tells the agent to pass terms verbatim from prepare_escrow_payment and to reuse its external_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a receipt's signature against the key its issuer publishes.
⚠️ THE KEY IS FETCHED FROM THE RECEIPT'S OWN iss, NOT FROM WHOEVER HANDED IT OVER.
Otherwise anything that can serve a receipt can also serve the key that vouches for it,
and the signature stops meaning anything.
Use this on receipts from anywhere, including ones this server did not produce.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_receipt | Yes | The receipt as a compact JWS string (header.payload.signature), e.g. the `payment_receipt` settle_escrow_payment returned, or one from anywhere else. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing the trust model: the verification key is fetched from the receipt's own `iss` claim, with a rationale for why. This explains the network behavior behind openWorldHint. It does not say what happens when the issuer is unreachable or the signature fails, though an output schema exists.
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 action, followed by a short security caveat and a usage note. The all-caps, emoji-prefixed warning is slightly heavy formatting for the amount of information conveyed, but every sentence carries real content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with an output schema, the description covers what an agent needs: input format via the schema, the trust/network behavior, and the intended scope of receipts. Failure semantics are left to the output 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 100% and the single parameter is fully described as a compact JWS string with examples. The description adds only indirect meaning (the issuer is read from the token itself, so no key parameter is needed). 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 ('Check a receipt's signature against the key its issuer publishes'), which is unambiguous and clearly distinct from the escrow payment siblings that create or settle receipts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this on receipts from anywhere, including ones this server did not produce' gives a clear inclusion criterion and implicitly contrasts with receipts this server generated. It stops short of naming a sibling or stating when-not-to-use (e.g. versus check_escrow_payment).
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.
check_escrow_payment1 field changedInput schema / properties / status_url / descriptionAdded value: +"The `status_url` on the receipt settle_escrow_payment returned, as is."payment_qr1 field changedInput schema / properties / payment_uri / descriptionAdded value: +"The `payment_uri` prepare_escrow_payment returned, for a code a wallet scans; or its `share_with_payer.pay_link`, for a code that opens the payment page."prepare_escrow_payment9 fields changedInput schema / properties / amount / descriptionAdded value: +"How much, in the token's base units: 1 USDC = 1000000, so 25 USDC is 25000000. One of the terms the payment address derives from."Input schema / properties / arbiter / descriptionAdded value: +"Wallet address (0x…) of who decides a dispute. Omit for the default arbiter. One of the terms the address derives from, so pass the same value to both tools."Input schema / properties / brand / descriptionAdded value: +"The white-label partner the payment is made under, if any: the site's `?b=` id, e.g. escrow-me. Attribution only; does not affect the address."Input schema / properties / description / descriptionAdded value: +"What the payment is for, in the buyer's own words, 1 to 160 characters, e.g. 'Logo design, final files'. Shown on the dashboard; does not affect the address."Input schema / properties / expiry_timestamp / descriptionAdded value: +"When the dispute window closes, as an absolute Unix time in seconds, e.g. 1764547200. 0 settles instantly with no recourse. There is no default."Input schema / properties / external_id / descriptionAdded value: +"Your own id for this payment, e.g. a checkout hash, so re-presenting the same purchase derives the same address. Omit and a unique one is generated; pass back the value this returns."Input schema / properties / payer / descriptionAdded value: +"Wallet address (0x…) that will sign an EIP-3009 authorization for us to relay, gas-free. Omit when the payer transfers the tokens to the address themselves."Input schema / properties / product_name / descriptionAdded value: +"What is being bought, e.g. 'Blue ceramic vase'. Shown on both parties' dashboards; display only."Input schema / properties / token_symbol / descriptionAdded value: +"The token to pay in, e.g. USDC. Must be one the service supports."read_published_page1 field changedInput schema / properties / page / descriptionAdded value: +"Which page: how-it-works, faq, arbitration-policy, terms-of-service, privacy-policy, plugins or home."settle_escrow_payment9 fields changedInput schema / properties / amount / descriptionAdded value: +"How much, in the token's base units: 1 USDC = 1000000, so 25 USDC is 25000000. One of the terms the payment address derives from."Input schema / properties / arbiter / descriptionAdded value: +"Wallet address (0x…) of who decides a dispute. Omit for the default arbiter. One of the terms the address derives from, so pass the same value to both tools."Input schema / properties / authorization / descriptionAdded value: +"The EIP-3009 authorization object prepare_escrow_payment returned for the payer, unchanged. Omit when the payer transferred the tokens themselves."Input schema / properties / brand / descriptionAdded value: +"The white-label partner the payment is made under, if any: the site's `?b=` id, e.g. escrow-me. Attribution only; does not affect the address."Input schema / properties / description / descriptionAdded value: +"What the payment is for, in the buyer's own words, 1 to 160 characters, e.g. 'Logo design, final files'. Shown on the dashboard; does not affect the address."Input schema / properties / expiry_timestamp / descriptionAdded value: +"When the dispute window closes, as an absolute Unix time in seconds, e.g. 1764547200. 0 settles instantly with no recourse. There is no default."Input schema / properties / external_id / descriptionAdded value: +"The external_id prepare_escrow_payment returned, exactly. A different id derives a different address while the money sits at the first."Input schema / properties / signature / descriptionAdded value: +"The payer's hex signature (0x…) over that authorization. Omit together with `authorization`."Input schema / properties / token_symbol / descriptionAdded value: +"The token to pay in, e.g. USDC. Must be one the service supports."verify_escrow_receipt1 field changedInput schema / properties / payment_receipt / descriptionAdded value: +"The receipt as a compact JWS string (header.payload.signature), e.g. the `payment_receipt` settle_escrow_payment returned, or one from anywhere else."prepare_escrow_payment1 field changedInput schema / properties / description / defaultPrevious value: -"Escrow payment"New value: +"Protected payment"settle_escrow_payment1 field changedInput schema / properties / description / defaultPrevious value: -"Escrow payment"New value: +"Protected payment"prepare_escrow_payment1 field changedInput schema / properties / arbiterAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}settle_escrow_payment1 field changedInput schema / properties / arbiterAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}prepare_escrow_payment2 fields changedInput schema / properties / brandAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Input schema / properties / product_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}settle_escrow_payment1 field changedInput schema / properties / brandAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}prepare_escrow_payment2 fields changedInput schema / properties / nominal_buyer / descriptionAdded value: +"Who may dispute and receives any refund — the PERSON, not the agent: a wallet address (0x…) OR an email address. An email is converted to that person's wallet, created for them if they have never signed in."Input schema / properties / seller / descriptionAdded value: +"Who gets paid: a wallet address (0x…) OR an email address. An email is converted to the wallet that person owns, created for them if they have never signed in; the same email always gives the same wallet."settle_escrow_payment2 fields changedInput schema / properties / nominal_buyer / descriptionAdded value: +"Who may dispute and receives any refund — the PERSON, not the agent: a wallet address (0x…) OR an email address. An email is converted to that person's wallet, created for them if they have never signed in."Input schema / properties / seller / descriptionAdded value: +"Who gets paid: a wallet address (0x…) OR an email address. An email is converted to the wallet that person owns, created for them if they have never signed in; the same email always gives the same wallet."check_escrow_paymentpayment_qrprepare_escrow_paymentread_published_pagesettle_escrow_paymentverify_escrow_receiptBuy products and services with escrow, or trade crypto P2P. Money moves only with human 2FA.
Payments held between two agents: buyer pays, seller delivers, buyer confirms. Pay per call.
Free reports, EVM/Solana token payment links and capped zero-fee EVM USDC escrow. Wallet signatures.
Private stablecoin payments for people and AI agents on mainnet, hosted or local with limits.
Add one secure layer between your agents and this server.
