What this changes for your product
The feature clears review
There is no path from the tool surface to a signature, so the risk your security team is assessing is a quote request rather than an unbounded transaction.
An agent that doesn't guess
Statuses, errors, and partial outcomes are published as decision procedures, which is the difference between an agent that survives a demo and one you can leave running.
Minutes to a working prototype
The hosted server is a config paste with no installation, so you find out whether the product idea works before you have staffed it.
Lower cost per agent run
The LI.FI CLI returns the same capability in compact text rather than raw JSON, which spends fewer tokens on every call in a loop.
The tools are read only. The boundary is where signing happens.
Why the usual approach stalls
Giving an agent on-chain capability usually means giving it a signer, and a signer is a permanent liability. Anything that reaches the agent’s context, including a token name it read off a page, is now one reasoning step away from a transaction. A bad trade is the smaller problem. The larger one is that you can’t put a ceiling on how bad one could be, which is the version of the question a risk owner has to answer before you launch. The narrower problem underneath is that most APIs are designed for a developer reading documentation, not for a model choosing between branches. An agent hitting an ambiguous status value or an undocumented error has nothing deterministic to fall back on, so it guesses, and a guess in an execution path is a bug you find in production.Where signing happens
The hosted MCP server exposes cross-chain routing as tools an agent discovers and calls: chains, tokens, quotes, allowances, status. Every one of them is read-only. The server doesn’t sign and doesn’t broadcast. A quote comes back as an unsigned transaction request, and signing it happens outside, in your own wallet infrastructure, under your own rules. Setup is a config paste, not an integration:Without a key the server runs on a public rate limit of 200 requests every two hours, which is enough to build against and not enough to run on. A key raises it to 200 requests a minute.
Written to be read by a model
The rest of the agent surface exists because agents consume documentation differently from people. There is a machine-readable index of the docs without the HTML around it, a discovery file so a host can find the capability on its own, and a full API specification. More usefully, the parts an agent has to get right are published as decision procedures rather than prose.Five-call recipe
The minimum ordered sequence covering discovery through confirmation.
Decision tables
Deterministic branching for every status a transfer can return: keep polling, treat as success, treat as a different asset delivered, treat as refunded, stop and report.
Error playbooks
Each failure mapped to its cause, whether a retry is appropriate, and what to say to the user.
What to decide before launch
Which addresses your signer will act for
Which addresses your signer will act for
Enforce it at the signer rather than in the prompt. A prompt can be talked out of a rule, and a signing policy can’t.
Spend limits per agent, per session
Spend limits per agent, per session
An agent that can request a quote of any size will eventually request one, and the only place that becomes harmless is the layer the agent can’t reach.
What a partial result means to the agent's plan
What a partial result means to the agent's plan
A transfer that completes with a different but related asset delivered is a success at the protocol level and may be a failure at the plan level, and the agent needs that distinction encoded rather than inferred. See Partial completion.
Whether the agent may retry, or has to ask
Whether the agent may retry, or has to ask
Both answers work. What doesn’t work is an agent that retries a funding action without recording that it did.
Where to start
Point an MCP-compatible host at the hosted server and ask it to price a cross-chain move. That takes a minute and tells you more about the shape of the integration than any amount of reading. Then build the signing side, which is the part that stays yours: address policy, limits, and approval.MCP server overview
Hosted setup, available tools, and rate limits.
Agent integration
The call sequence, decision tables, and error playbooks.
Available tools
Full reference for every MCP tool.
Execution workflows
Approvals, execution, and status recovery for an agent loop.
Talk to the LI.FI team
Bring your agent’s call volume and the flows you want it to run. We scope an API key and the limits that fit.