herrenlos for AI agents: the Intent API and MCP server

The same cross-chain swap engine that powers the herrenlos app is also exposed for automated callers — AI agents, assistants, and scripts. The point isn't to let a bot trade on its own; it's to let an agent do the gathering work — compare routes, build a swap — and then hand the result to a person's wallet to sign. The Agents page is the quick-start; this post is the shape of it.

Two front doors, one engine

There are two ways in, and both talk to the same routing engine:

• MCP server — for MCP clients like Claude Desktop or Cursor. Add it once and the client discovers the tools automatically.
• REST API (/api/v1) — call it directly from any language, no setup. Read-only quote, supported, and health are safe to call freely.

Either way you're quoting and routing across the same providers the app uses — Chainflip, LI.FI, Squid, 0x, OpenOcean, Rango, ChangeNOW, and SwapKit — ranked by best executable output.

What the MCP server is

The MCP server is a thin, stateless stdio wrapper over the Intent API. It exposes five tools:

• list_supported — the exact, case-sensitive chains, assets, and which providers are executable.
• get_quote — compare routes and pick the best executable one (read-only).
• create_intent — turn a chosen route into a signable intent (for EVM sources, EIP-712 typed data).
• execute_intent — get back the thing to act on: an unsigned transaction, or a deposit address (with a memo when one is required).
• get_status — poll an intent until it completes.

Today the MCP server is self-hosted — you run the mcp/ package locally, or as the bundled Docker sidecar alongside a self-hosted app. A hosted, remote MCP endpoint for easier discovery is planned; until then, if you want zero setup, the REST API works right now.

What an agent can do — and what still needs a wallet

An agent can do all of the read-and-build steps: discover what's supported, quote routes, create an intent, fetch the execute payload, and track status. What it cannot do is move money.

The user's own wallet is what signs the EIP-712 intent (on EVM source chains) or funds the deposit address (on chains like Bitcoin). A typical flow looks like this:

1. Discover — list_supported for the exact chain/asset strings.
2. Quote — get_quote to compare and choose a route. Read-only.
3. Create intent — create_intent returns an intentId (and, for EVM, typed data to sign).
4. User signs — the person's wallet signs the typed data. Deposit-address chains skip this.
5. Execute — execute_intent returns an unsigned transaction, or a deposit address (+ memo).
6. The human acts — the user's wallet broadcasts the transaction, or sends funds to the deposit address. The agent never does this step.
7. Track — get_status until it's done.

Safety posture

The design has one rule that everything else follows from: the server never signs and never broadcasts, and it holds no keys and no funds.

execute only ever returns signable data for a wallet to sign, or a deposit address for the user to fund. Your agent's job is to gather inputs and hand that data to the user's wallet — never to ask for, accept, or transmit a private key or seed phrase.

That's the whole custody story: there isn't an agent-controlled account, because there can't be one.

Honest limits

A few things worth knowing before you build against it:

• LI.FI is quote-only here — it can appear in a quote but can't back a create_intent. Choose a route whose executable flag is true.
• Intents expire (around 15 minutes by default). If one lapses, create a fresh one, and re-quote if a lot of time has passed.
• Rate limits apply, shared per-IP across /api/v1. On a 429, wait the Retry-After seconds before retrying, and poll status gently.
• It's beta, and the surface is deliberately small: quote, build, execute-payload, track. No autonomous trading, no custody, no moving funds on a user's behalf — those aren't limitations to be worked around, they're the point.

To wire it up, start on the Agents page — it has copy-paste MCP config, the full endpoint table, and a machine-readable OpenAPI spec — and check the roadmap for what's shipped and what's next.