Stablecoin escrow payments the buyer can dispute, with a signed receipt. Pay a wallet or an email.
Scored across 6 tools
Each tool targets a distinct phase or artifact of the escrow payment lifecycle: preparing terms, settling money, checking status, generating a QR code, verifying a receipt signature, and reading documentation. The descriptions explicitly separate prepare vs. settle and check vs. verify, leaving no ambiguous overlap.
Five of six tools follow the same snake_case verb_noun pattern (check_, prepare_, read_, settle_, verify_), making the set highly predictable. The outlier is payment_qr, which is a noun phrase rather than a verb-led name, but it is still snake_case and easily understood.
Six tools is well-scoped for an escrow payment service: creation, settlement, status, QR, receipt verification, and documentation each earn their place without redundancy. No tool feels extraneous, and the count stays far below the heavy range.
The core payment lifecycle is covered—prepare, settle, check, verify, and QR—but there are no tools for initiating a dispute, claiming a refund after the dispute window, or otherwise acting on the arbitration and expiry mechanics heavily described in the prepare and settle tools. This leaves notable dead ends for an agent asked to help with post-settlement recourse.
What has happened to a settled payment, from the status_url on its receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| status_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The wording 'what has happened' implies a read-only, historical lookup rather than a mutating action, but it does not explicitly state side-effect-freedom, authorization requirements, or possible response behaviors. This is minimally acceptable but not fully transparent.
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 a single concise sentence with no filler. It front-loads the core concept ('what has happened to a settled payment') and ends with the key input source (`status_url` on its receipt). Slight awkwardness in phrasing prevents a 5, but it is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameterhare and an output schema present, the description does not need to explain return values. It adequately names the input source and settled-payment precondition, but it omits contextual details such as whether this is safe to call repeatedly, whether the `status_url` expires, or how this relates operationally to `settle_escrow_payment` and `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 description coverage is 0%, so the description must compensate. It adds useful meaning by explaining that `status_url` comes from the payment receiptcars, but it does not provide details about URL format, how to extract it, or what the tool expects beyond the schema's plain string type. The single-parameter design reduces the risk, but the semantics are only partially enriched.
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 a specific action: checking what happened to a settled payment using the `status_url` from its receipt. It distinguishes itself from sibling tools like `settle_escrow_payment` and `verify_escrow_receipt` by focusing on status/history of an already settled payment, though the phrasing 'what has happened' is somewhat indirect.
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 meant for post-settlement inquiries: the payment must be settled and the caller must have the receipt's `status_url`. It does not explicitly name alternatives or state when not to use this tool, so usage context is clear but exclusion/routing guidance is missing.
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 — an escrow funded with the wrong figure is not the escrow these terms derive to, and the money sits at an address nothing can deploy to.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose what the artifact contains (token, network, destination, amount) and what it is for (scan-once, no retyping). It does not state the concrete return shape, i.e. whether the caller receives image bytes, a data URI, or a URL — a meaningful omission for a generator tool with no output schema. No side-effect or auth information is given, though a QR generator is implicitly non-destructive.
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 and the two warning blocks carry real routing value, but the prose is padded with rhetorical justification ('the money sits at an address nothing can deploy to') and restates the same point across multiple sentences. A tighter two-to-three-sentence version would convey the same selection logic.
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 single-parameter, low-complexity tool with no output schema and no annotations, the description covers what it produces, when to choose it, and why it is separate from `prepare`. The remaining gap is the concrete return representation, which nothing else in the definition supplies.
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 0%, so the description must compensate, and it does: it tells the agent the parameter is a payment URI, where to obtain it (`prepare_escrow_payment`), and what that URI encodes. It stops short of giving the URI format/scheme, and the aside about `share_with_payer.pay_link` is slightly ambiguous since the schema exposes only one field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first line states a concrete verb+resource ('a scannable code for a payment request') and the second half of the description explicitly contrasts it with `prepare_escrow_payment`, so the agent can distinguish the two without opening either schema. The scope note that it 'ENCODES THE URI, NOT THE BARE ADDRESS' further pins down what is produced.
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 names exactly which input to pass and where to get it ('Pass the `payment_uri` from `prepare_escrow_payment`'), plus an alternative source (`share_with_payer.pay_link`) with the condition that selects it (handing a link to a human payer). It also states why this is a separate tool rather than folded into `prepare`, which is precisely the routing decision an agent must make.
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.
Returns the escrow 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 escrow never asks who paid: it reads its own balance. Then call
settle_escrow_payment with no signature and we create the escrow 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 escrow — 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 escrow", 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 "Escrow 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
escrow 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 | ||
| payer | No | ||
| amount | Yes | ||
| 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 | ||
| description | No | Escrow payment | |
| external_id | No | ||
| product_name | No | ||
| token_symbol | No | 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: sanctions screening with the exact error code (sanctioned_party), address derivation as a pure function of terms, the email-to-wallet resolution side effect (wallets may be created), gas sponsorship on the relayed path, no default for expiry_timestamp, the 160-char pre-chain validation, and the warning to pass back the generated external_id. These are exactly the mutation/side-effect and failure-mode details annotations would otherwise supply.
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?
Warnings are front-loaded and the sectioned structure with bolded anchors aids scanning, but the email-or-address rule is stated almost verbatim twice (opening paragraph and the bolded sentence near the end), and the length is inflated for a derivation call. The repetition and density cost it despite otherwise sensible ordering.
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 tool with an output schema, the description covers the semantics an agent needs and does not need to restate return values. It is nearly complete, with token_symbol's role in interpreting amount and any permission requirements for the relayed path being the only real omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, so the description must compensate and largely does: it explains email-or-address resolution for seller and nominal_buyer, amount in token base units (1 USDC = 1000000), expiry_timestamp as absolute Unix time with 0 meaning instant, external_id generation and address impact, description's purpose, brand/product_name as display-only, and arbiter's default. Only token_symbol (default USDC) goes unmentioned, which is a minor gap against otherwise complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and object ('Work out where a payment must go, before anybody signs or sends anything') and then names the exact artifact it produces (the escrow address plus two funding routes). It routes clearly against its sibling settle_escrow_payment, which it names as the follow-up step, so an agent can place this tool in the workflow without reading 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?
It gives clear when-to-use context ('before anybody signs or sends anything'), the sequencing into settle_escrow_payment, and an explicit fork between self-transfer and relayed EIP-3009 (with the note that only the relayed path works unattended). It does not, however, contrast itself against the other escrow siblings such as check_escrow_payment or payment_qr, so exclusions are left implicit.
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 escrow payment works, start to finish faq Common questions about escrow, 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. The verb 'Read' signals a non-mutating operation, and the page list clarifies scope, but the description does not mention error behavior, side effects, or return semantics. Since an output schema exists, the lack of return-format detail is acceptable.
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 purpose, then gives a brief rationale, and then a structured list of valid pages. The motivational sentence ('none of it is safe to invent') earns its place by reinforcing when to use the tool, though it is slightly wordy.
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 single-parameter read tool, the description provides the complete set of likely valid page values, the purpose, and the types of questions to answer. It could be slightly more explicit that the listed pages are the only valid values, but the output schema and low complexity mean the description is effectively sufficient.
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 input schema provides only a bare `page` string with no description or enum, yet the description compensates fully by enumerating the valid page identifiers (how-it-works, faq, arbitration-policy, terms-of-service, privacy-policy, plugins, home) and explaining what each contains. This is exactly the semantic information an agent needs to select a correct parameter value.
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: 'Read one of the published pages, for answering questions about how any of this works.' It clearly distinguishes this knowledge-base reader from the sibling payment-operation tools (check, prepare, settle, verify) by framing it as the source of authoritative documentation about fees, disputes, and terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance: 'Use it rather than guessing' and lists the exact topics (fees, dispute resolution, buyer agreements) that should be answered from these pages. It does not explicitly list exclusions or alternative tools, but the context makes the intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create the escrow 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 escrow 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 escrow'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.
⚠️ 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 | ||
| amount | Yes | ||
| 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 | ||
| signature | No | ||
| description | No | Escrow payment | |
| external_id | Yes | ||
| token_symbol | No | USDC | |
| authorization | No | ||
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that a missing transfer costs nothing to check, that the relayer pays gas, that the process holds no key and signs nothing, that altering a term changes the escrow address, and that the receipt reconciles token_amount + creator_fee = amount. These are exactly the behavioral traits annotations would otherwise supply.
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 heading-style structure and ⚠️ warnings are effective and front-load the critical external_id constraint, but the definition is bloated: the sentence explaining that `seller` and `nominal_buyer` may be wallet or email addresses is repeated verbatim twice, wasting space on an already long description.
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 mutation tool with no annotations, the description covers the decisive behaviors, mode selection, address derivation, receipt semantics, and requires little else. Since an output schema exists it needn't detail return shape, though it helpfully does; the only real omissions are a few undistinguished parameters like expiry_timestamp.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, so the description must compensate and largely does: it explains seller/nominal_buyer email-vs-wallet resolution, the criticality of external_id provenance, the signature/authorization mode switch, brand being attribution-only and ignored when malformed, and arbiter defaulting. It leaves expiry_timestamp, description, and token_symbol (all schema-silent) unaddressed, so a gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Create the escrow around the money and return a signed receipt') and explicitly frames the tool around the two settlement modes. It distinguishes itself from prepare_escrow_payment by explaining the progression from preparation to settlement, letting an agent place it in the workflow without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use branches: omit `authorization`/`signature` if the payer already transferred funds, or pass them to have the service relay and pay gas. It also names the prerequisite (external_id must be the value prepare_escrow_payment returned) and the arbiter carry-over requirement, leaving little to inference.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it does. The warning that the key is fetched from the receipt's own `iss`, not from whoever handed it over, is a critical non-obvious behavior. The note about external receipts also clarifies scope, though it does not explicitly state side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one purpose sentence, one security warning, one usage sentence. The warning is emphatic but earns its place because it prevents a critical security misuse. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required string parameter and an output schema, the description covers the purpose, the key security caveat, and the supported input scope. It does not fully compare against sibling tools or document the receipt's wire format, but those are minor given the tool's simple surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type, so the description must supply meaning. It does by indicating the receipt carries a signature and an `iss` claim that determines which key validates it. It does not specify the serialization format, but for a single string parameter this is a moderate gap, not a blocking one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and object: 'Check a receipt's signature against the key its issuer publishes.' This clearly identifies the tool's core function. It does not explicitly name sibling tools, but the usage note about receipts 'from anywhere, including ones this server did not produce' gives some scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage instruction: 'Use this on receipts from anywhere, including ones this server did not produce.' This tells an agent the tool is not limited to receipts the server generated. It does not name alternatives or list when not to use it, so it stops short of full routing guidance.
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.
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_receiptPrivate stablecoin payments for people and AI agents, hosted or local with spending limits.
Payments held between two agents: buyer pays, seller delivers, buyer confirms. Pay per call.
Non-custodial pay links: BTC + Lightning, USDC, USDT, EURC, SOL, ETH. Payer signs; never holds keys.
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Add one secure layer between your agents and this server.
