MM by Escrow MCP

Get the message to sign to lock money

mm_get_funding_request

Buyer: locks the payment. Seller: locks the bond (if the deal has one). Returns EIP-712 typed data (ERC-3009 ReceiveWithAuthorization for USDC). Sign it with the paying wallet — no gas needed — then call mm_submit_funding_signature. Valid for 2 hours.

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": {
      "deal_id": "<deal_id>",
      "token": "<token>",
      "payer_address": "<payer_address>"
    },
    "name": "mm_get_funding_request"
  }
}

Input Schema

Name	Required	Description
`token`	Yes	Your private deal token (from mm_create_deal or your deal link ?k=...)
`deal_id`	Yes	Deal ID, like D-7KQ2M9AB
`payer_address`	Yes	The wallet that holds the USDC and will sign

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations at all, the description carries the full burden. It does useful work: discloses the exact payload type (EIP-712 / ERC-3009), that no gas is required, who must sign (the paying wallet), and a 2-hour expiry. It says nothing about idempotency, what happens if the request is fetched twice, or which deal states reject the call.

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

Conciseness5/5

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

Four short clauses, front-loaded with who does what and what is returned, then the next step and the expiry. Every sentence carries distinct information and nothing is repeated from the schema.

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?

With no output schema and no annotations, the description steps in to explain the return value (typed data to be signed), the gas/auth situation, and the expiry. It is nearly complete for a 3-parameter tool, with only failure modes and re-request behavior left implicit.

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, but the description adds real meaning by tying payer_address to the signing act ('Sign it with the paying wallet') and by clarifying that funding is conditional ('if the deal has one'), which shapes how deal_id should be interpreted. The token and deal_id formats are left entirely to the schema.

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?

States a specific action and output: returns EIP-712 typed data (ERC-3009 ReceiveWithAuthorization for USDC) used to lock payment or bond. It also distinguishes the two actor paths (buyer locks payment, seller locks bond) and names the sibling it feeds into, mm_submit_funding_signature, so an agent can separate it from the submit step without opening either schema.

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

Usage Guidelines4/5

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

Gives clear sequencing: get the typed data, sign it with the paying wallet, then call mm_submit_funding_signature, plus the 2-hour validity window that governs how fast the follow-up must happen. It does not state when this tool should be avoided (e.g., deal not yet accepted, or signature already submitted), so it stops short of explicit exclusions.

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?