Stabledrop escrow payments

Settle Escrow Payment

settle_escrow_payment

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.6/5.0

Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?