agent-embassy

Register Recovery

register_recovery

Idempotent

Register a dead-man's recovery configuration for your AI agent: the Embassy stores your client-encrypted recovery blob and quorum rules and queues them for human review within 24h. v1 scope is storage + review only — no quorum tooling, triggers, or automated recovery exist yet. One-time $1.00 registration per agent wallet, paid in USDC via x402. Acceptance test: the stored blob's hash matches the hash in your receipt.

MONETIZED VIA x402 — this tool is not callable for free. POST https://agent-embassy.fly.dev/v1/recovery/register with an x402 payment ($1.00, USDC on Base). Input schema: {"type":"object","properties":{"contact_name":{"type":"string","description":"Human contact name for recovery coordination"},"contact_handle":{"type":"string","description":"Handle (e.g. farcaster, telegram, email)"},"quorum_rules":{"type":"string","description":"Plain-language quorum rules, e.g. '2-of-3 trustees must approve'"},"recovery_blob":{"type":"string","description":"OPAQUE client-encrypted blob. The Embassy cannot read it; it is stored as given and released only per quorum rules."},"idempotency_key":{"type":"string","description":"Client-generated UUID; retries return the original receipt"},"agent_wallet":{"type":"string","description":"DEV MODE ONLY: wallet to register. In live mode the payer wallet from the verified x402 payment is used."}},"required":["contact_name","quorum_rules","recovery_blob","idempotency_key"]}

Input Schema

TableJSON Schema

Name	Required	Description
`agent_wallet`	No	DEV MODE ONLY: wallet to register. In live mode the payer wallet from the verified x402 payment is used.
`contact_name`	Yes	Human contact name for recovery coordination
`quorum_rules`	Yes	Plain-language quorum rules, e.g. '2-of-3 trustees must approve'
`recovery_blob`	Yes	OPAQUE client-encrypted blob. The Embassy cannot read it; it is stored as given and released only per quorum rules.
`contact_handle`	No	Handle (e.g. farcaster, telegram, email)
`idempotency_key`	Yes	Client-generated UUID; retries return the original receipt

Output Schema

TableJSON Schema

Name	Required	Description
`how`	Yes	How to pay: POST the tool inputs as JSON to paid_url with an x402 v2 PAYMENT-SIGNATURE header
`tool`	Yes	Tool name, e.g. verified_check
`asset`	Yes	Settlement asset
`price`	Yes	Exact price, e.g. "$0.15"
`networks`	Yes	EVM CAIP-2 network ids accepted
`paid_url`	Yes	x402-paid HTTPS URL to POST the tool inputs to
`facilitator`	Yes	x402 facilitator
`payment_required`	Yes	Always true: this MCP tool is a payment pointer; the tool itself is monetized via x402.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "asset": {
+      "description": "Settlement asset",
+      "type": "string"
+    },
+    "facilitator": {
+      "description": "x402 facilitator",
+      "type": "string"
+    },
+    "how": {
+      "description": "How to pay: POST the tool inputs as JSON to paid_url with an x402 v2 PAYMENT-SIGNATURE header",
+      "type": "string"
+    },
+    "networks": {
+      "description": "EVM CAIP-2 network ids accepted",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "paid_url": {
+      "description": "x402-paid HTTPS URL to POST the tool inputs to",
+      "type": "string"
+    },
+    "payment_required": {
+      "const": true,
+      "description": "Always true: this MCP tool is a payment pointer; the tool itself is monetized via x402.",
+      "type": "boolean"
+    },
+    "price": {
+      "description": "Exact price, e.g. \"$0.15\"",
+      "type": "string"
+    },
+    "tool": {
+      "description": "Tool name, e.g. verified_check",
+      "type": "string"
+    }
+  },
+  "required": [
+    "payment_required",
+    "tool",
+    "paid_url",
+    "price",
+    "networks",
+    "asset",
+    "facilitator",
+    "how"
+  ],
+  "type": "object"
+}

Changed6 schema fields changedSep 21, 2026

addedInput schema / properties / agent_wallet / description

Added value: +"DEV MODE ONLY: wallet to register. In live mode the payer wallet from the verified x402 payment is used."

addedInput schema / properties / contact_handle / description
```
Added value: +"Handle (e.g. farcaster, telegram, email)"
```

addedInput schema / properties / contact_name / description

Added value: +"Human contact name for recovery coordination"

addedInput schema / properties / idempotency_key / description

Added value: +"Client-generated UUID; retries return the original receipt"

addedInput schema / properties / quorum_rules / description

Added value: +"Plain-language quorum rules, e.g. '2-of-3 trustees must approve'"

addedInput schema / properties / recovery_blob / description

Added value: +"OPAQUE client-encrypted blob. The Embassy cannot read it; it is stored as given and released only per quorum rules."

First observedSep 21, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description discloses significant behavior: the tool is monetized via x402, costs $1.00 in USDC, queues for human review within 24 hours, stores an opaque client-encrypted blob the server cannot read, and returns a receipt whose hash can be verified. These details materially shape how an agent should call and trust the tool, and nothing contradicts the annotations.

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 prose is front-loaded and information-dense, but the description embeds a full duplicate of the input schema, which is redundant with the separately provided schema. Payment information is also stated twice ('paid in USDC via x402' and the MONETIZED VIA x402 sentence), so the structure is effective but not tight enough for a top score.

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?

Given the tool's real-world complexity (paid call, endpoint, idempotency, review delay, dev-mode override, and absence of recovery execution), the description is complete. It tells the agent how to invoke it, what constraints apply, and how to verify success via the receipt hash, while leaving return-shape details to the output 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?

The input schema already has 100% description coverage, so the baseline is 3. The prose adds context about payment and idempotent retries, but most parameter-level meaning (opaque blob, dev-mode wallet, idempotency key) is already present in the schema properties; the description does not add substantial parameter semantics beyond it.

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 action and object: 'Register a dead-man's recovery configuration for your AI agent,' naming the resource (recovery blob + quorum rules) and the scope (storage and review). This clearly distinguishes the tool from the price/history/verification siblings even without inspecting their schemas.

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?

The description gives clear operational context: it states the payment requirement, endpoint, v1 scope, and explicitly warns that no quorum tooling, triggers, or automated recovery exist yet. It does not name alternative tools, but the sibling set is unrelated and the usage boundary is otherwise explicit.

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

All agent-embassy 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.