> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Ship Agent Execution Without Handing Over a Signer

> Ship cross-chain execution in an agent product without handing the agent a signer.

Most agent products that touch on-chain execution die in review, not in development, because giving an agent a signer creates a liability nobody wants to sign off on. LI.FI's agent surface is read-only by construction, so the capability ships and the signing authority stays inside infrastructure you already control.

## 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](https://docs.li.fi/cli/overview.md) returns the same capability in compact text rather than raw JSON, which spends fewer tokens on every call in a loop.

![An agent calling read-only LI.FI tools, receiving an unsigned request, and a signing boundary before your own signer](https://mintcdn.com/lifi/PmU0d85L8IwCXHK-/images/use-cases/agent-execution-boundary.png?fit=max\&auto=format\&n=PmU0d85L8IwCXHK-\&q=85\&s=92fb9adf848883be114853acb733c50f)

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](https://docs.li.fi/mcp-server/overview.md) 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.

> [!WARNING]
>
> That single design choice is what makes the rest safe to reason about. A prompt injection that reaches the agent reaches a quote request. It doesn't reach a transaction.

Setup is a config paste, not an integration:

```json theme={"system"}
{
  "mcpServers": {
    "lifi": {
      "type": "http",
      "url": "https://mcp.li.quest/mcp"
    }
  }
}
```

That works in any MCP-compatible host with no installation. See [Installation](https://docs.li.fi/mcp-server/installation.md) for host-specific setup.

> [!NOTE]
>
> 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](https://docs.li.fi/agents/overview.md) 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](https://docs.li.fi/agents/quick-start/five-call-recipe.md)**
>
> The minimum ordered sequence covering discovery through confirmation.

> **[Decision tables](https://docs.li.fi/agents/quick-start/decision-tables.md)**
>
> 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](https://docs.li.fi/agents/reference/error-playbooks.md)**
>
> Each failure mapped to its cause, whether a retry is appropriate, and what to say to the user.

LI.FI's capabilities are also published as pre-built agent skills on the main agent skill directories, so cross-chain execution can be added as a native capability instead of one you write.

## What to decide before launch

> **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**
>
> 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**
>
> 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](https://docs.li.fi/agents/workflows/partial-completion.md).

> **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](https://docs.li.fi/mcp-server/overview.md)**
>
> Hosted setup, available tools, and rate limits.

> **[Agent integration](https://docs.li.fi/agents/overview.md)**
>
> The call sequence, decision tables, and error playbooks.

> **[Available tools](https://docs.li.fi/mcp-server/tools.md)**
>
> Full reference for every MCP tool.

> **[Execution workflows](https://docs.li.fi/agents/workflows/execution.md)**
>
> Approvals, execution, and status recovery for an agent loop.

> **[Talk to the LI.FI team](https://docs.li.fi/introduction/integrating-lifi/partnership-opportunities.md)**
>
> Bring your agent's call volume and the flows you want it to run. We scope an API key and the limits that fit.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.