Stabledrop escrow payments

Settle Escrow Payment

settle_escrow_payment

Destructive

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.

Input Schema

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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 29, 2026

addedInput schema / properties / amount / description

Added 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."

addedInput schema / properties / arbiter / description

Added 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."

addedInput schema / properties / authorization / description

Added value: +"The EIP-3009 authorization object prepare_escrow_payment returned for the payer, unchanged. Omit when the payer transferred the tokens themselves."

addedInput schema / properties / brand / description

Added 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."

addedInput schema / properties / description / description

Added 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."

addedInput schema / properties / expiry_timestamp / description

Added 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."

addedInput schema / properties / external_id / description

Added value: +"The external_id prepare_escrow_payment returned, exactly. A different id derives a different address while the money sits at the first."

addedInput schema / properties / signature / description

Added value: +"The payer's hex signature (0x…) over that authorization. Omit together with `authorization`."

addedInput schema / properties / token_symbol / description

Added value: +"The token to pay in, e.g. USDC. Must be one the service supports."

Changed1 schema field changedOct 17, 2026
- changedInput schema / properties / description / default
```
Previous value: -"Escrow payment"New value: +"Protected payment"
```

Changed1 schema field changedOct 1, 2026

addedInput schema / properties / arbiter

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed1 schema field changedOct 1, 2026

addedInput schema / properties / brand

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed2 schema fields changedSep 18, 2026

addedInput schema / properties / nominal_buyer / description

Added 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."

addedInput schema / properties / seller / description

Added 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."

First observedSep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Stabledrop escrow payments tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?