MM by Escrow MCP

Open an escrow deal

mm_create_deal

Create a deal as the buyer or the seller. Returns your private token (keep it) and a link to send the other side. Pick a delivery check so MM can verify delivery on its own when possible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "role": "<role>",
      "title": "<title>",
      "price_usdc": "<price_usdc>"
    },
    "name": "mm_create_deal"
  }
}

Input Schema

Name	Required	Description
`role`	Yes	Which side you are
`check`	No	How MM confirms delivery
`terms`	No	Exactly what must be delivered and how
`title`	Yes	What is being sold, e.g. "voter.org domain"
`network`	No	USDC deals: base = real USDC; base-sepolia = test USDC
`category`	No
`your_name`	No
`milestones`	No
`price_usdc`	Yes	Price in dollars, e.g. 12000 (USDC, or USD for card/bank deals)
`your_email`	No	MM emails your private link here and tells you when it is your move (people; agents usually use webhook_url)
`fee_paid_by`	No
`webhook_url`	No	MM POSTs every deal event here (signed)
`payment_rail`	No	usdc (default): USDC on Base in a smart contract. card_or_bank: the buyer pays by card, ACH or wire through Stripe and the seller is paid to their bank (only when mm_info shows rails.stripe = true)
`buyer_address`	No
`delivery_days`	No
`inspection_hours`	No
`seller_bond_usdc`	No	Optional performance bond the seller locks first; forfeited to the buyer if the seller fails
`counterparty_name`	No
`counterparty_email`	No	MM emails the other side their private link to the deal
`buyer_receive_address`	No	Where on-chain deliveries should go, if not the paying wallet
`seller_payout_address`	No	Wallet the seller is paid to (required before funding)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load, and it does disclose real behavior: a private token is returned and must be kept, the counterparty receives a link, and delivery verification can be autonomous depending on the check type. It omits the escrow lifecycle context an agent would want — that the deal is unfunded until signature, that funds are held in contract, or what happens on failed delivery.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the return value, then the delivery-check guidance; nothing is padded. The final sentence ("verify delivery on its own when possible") is slightly vague about which checks qualify, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 21-parameter escrow-creation tool with nested check objects, no annotations, and no output schema, so the description bears the heaviest burden. It covers roughly the return shape and one parameter hint, but leaves the multi-step flow (counterparty acceptance, funding, payout address requirement) and the card_or_bank vs usdc branching entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 62% across 21 parameters, so the schema does substantial work already. The description adds one genuine insight beyond the schema — that the chosen check type determines whether MM can verify delivery without human involvement — but says nothing about role, price, payment rail, webhook, or bond semantics, which are the parameters most likely to be misused.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("Create a deal") and names the actor scope ("as the buyer or the seller"), plus what comes back (private token and counterparty link). It is clearly distinct from siblings like mm_cancel_deal or mm_get_deal, though it never explicitly contrasts with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent learns it acts as one of two sides and should choose a delivery check that MM can verify autonomously. There is no explicit when-to-use versus alternatives, and no prerequisite guidance (e.g. checking mm_info for rails.stripe before choosing payment_rail), even though the schema hints at such a condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All MM by Escrow MCP 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?