MCP server for keyless-escrow — open, inspect, and resolve non-custodial Solana escrows as agent tools. A moderator can release funds but never steal them.
Server has 7 well-named tools with clear, domain-specific descriptions (avg 156 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented, LLMs cannot predict return structure for chaining. Error handling is minimal; no recovery guidance or actionable error messages. Tool descriptions lack dependency hints and prerequisites. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound (each tool has one responsibility), but missing pagination guidance for list operations.
Swap two assets between two parties in ONE atomic transaction — either both legs settle or neither does. The trustless happy path when a trade is simultaneous and on-chain (no custody window). This server must hold BOTH owner keys. Omit a mint for a native SOL leg. Optionally delivered atomically via a Jito bundle.
Return the full escrow record, including which outcomes this server can settle.
List every escrow this server has opened, with a one-line summary each.
Open a non-custodial escrow: create the keyless vault, deposit the tokens, pre-sign the four fixed-destination outcomes, and destroy the vault key. The buyer/funder must be a key this server holds. Returns the escrow id (the vault address).
Complete one outcome (e.g. release:by-arbiter). The server signs with the held key that the outcome designates as authorizer; it refuses outcomes whose key it does not hold. Optionally delivers the settlement atomically via a Jito bundle.
Output schemas not documented. LLMs cannot predict return structure (fields, types, pagination) for downstream tool chaining or data extraction.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools marked Risk=IRREVERSIBLE (escrow_settle, atomic_swap) lack destructiveHint; read-only tools lack readOnlyHint. Agents cannot distinguish safe from dangerous operations.
No error handling guidance. Descriptions do not explain failure modes, recovery steps, or when to retry. E.g., escrow_settle could fail if key not held, but no actionable error message documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List the Solana public keys this server holds. The server can only settle an outcome whose authorizer key appears here — e.g. a moderator running with only their arbiter key can resolve disputes but can do nothing else.
Check the live on-chain status of an escrow: funded balance and whether it has settled.
escrow_list lacks pagination guidance. No mention of limit, offset, or total count. Large escrow lists could blow context window.
Parameter descriptions lack format/constraint details. E.g., 'amount' is a string but no mention of base units, range, or validation. 'escrowId' is a vault address but no format hint (base58, length).