> ## Documentation Index > Fetch the complete documentation index at: https://docs.defiloops.com/llms.txt > Use this file to discover all available pages before exploring further. # Connect your own agent > Point an MCP client at DeFiLoops: read the catalogue with no sign-in, read your accounts after a wallet sign-in, and use your chat if you grant it **In short:** you run your own AI agent and want it to use DeFiLoops. Point any MCP client at `https://mcp.defiloops.com/mcp`. Without signing in, your agent can read the public catalogue. After a wallet sign-in, it can read your accounts. If you also grant the chat scope, it can talk to your DeFiLoops chat as you. Without the chat scope, nothing on this server can write, sign or spend. MCP is the Model Context Protocol, the standard way an AI client calls tools on a server. This server speaks the Streamable HTTP form of the specification dated 2025-11-25. ## Three levels of access | level | what you do | what your agent can reach | | - | - | - | | **Anonymous** | Nothing. Send a request with no token. | The public catalogue: operations, a search over them, the plan schema, the template agents, and agent listings and credentials. | | **Signed in** | Sign in with your wallet. | The anonymous tools, plus your own accounts: the list of them, deposit addresses, balances, lending positions and a quote you asked for. | | **Chat scope** | Sign in with your wallet and approve the chat scope. | Your DeFiLoops chat, as you. See [below](#the-chat-scope). | ## The anonymous tools These answer exactly what a plain call to the public gateway would answer. Any other tool, called without a token, answers `401` and the sign-in challenge. | tool | what it returns | | - | - | | `list_catalog` | Every operation, its networks, and whether an agent can call it. | | `search_catalog` | The callable operations that match a job in plain words, ranked by measured success rate, then slippage, then gas. | | `get_plan_schema` | The JSON Schema a plan document must meet. | | `list_templates`, `search_templates` | The plans on the shelf, with typed slots and limits. | | `get_agent_listing`, `get_agent_credential`, `get_credential_signer` | An agent's listing, a signed "listed" credential you can check offline, and the address that signs credentials. | ## Signing in Your agent signs in with a wallet signature. There is no password and no console login. 1. The client registers itself with the server and starts a standard OAuth 2.1 flow with PKCE. 2. The sign-in page asks your wallet to sign one message. The message names the client, the permissions it asks for and the networks it covers. Signing costs no gas and approves nothing. 3. The server issues a token that lasts one hour. It is not refreshed. Sign in again when it ends. The token opens this server and nothing else. A console login does not work here, and this token does not work on the console. ## One sign-in for every network One sign-in covers every network DeFiLoops serves, for your own accounts. This works for an ordinary key-held wallet only. A contract wallet stays limited to one network. ## Tokens tied to your client's key A token can be bound to a key your client holds, using the DPoP standard. A stolen token then fails without that key. The chat scope is issued only in this bound form. ## The chat scope The chat scope lets your agent use your DeFiLoops chat as you. It is the only way a connected agent can start anything. What your agent gets: | tool | what it does | | - | - | | `chat_send` | Sends a message. Without a conversation id, it starts a new conversation. | | `chat_status` | Reads the transcript, what was saved, and what the Start button would run now. | | `chat_build` | Presses the console's Build button. | | `chat_confirm` | Presses the console's Start button for one exact action. | | `chat_sessions` | Lists your conversations. | | `chat_stop` | Stops the turn in flight. | How it is held: * **Your wallet signed for it.** The message you sign names the chat scope. A read-only signature can never produce a chat token. * **It needs an ordinary wallet you already linked to your console login** with a signed proof. A contract wallet, or a wallet with no proven link, is refused when you sign in. * **A start needs a hash.** `chat_status` shows each action with a hash of the exact plan, network and account. `chat_confirm` refuses if anything changed, or if nothing is waiting. * **It is your chat.** Every message and action appears in your console chat history, marked as coming from MCP. The same limits apply as in the console. * **It is short.** Each call runs under its own narrow console session, which ends at most 12 minutes after it starts and is never extended. * **It is rate limited.** One message every 20 seconds, with a burst of three. A turn is refused while your credit balance is below zero. > [!WARNING] > > **The server cannot tell whether a person or your agent called `chat_confirm`.** > A client with the chat scope can start a run you have already discussed, with no > human press. Grant the chat scope only to a client you would trust with your > console session. The limits on [Your account and your keys](https://docs.defiloops.com/kernel.md) still bound > every run: the operations your account allows, the enclave's checks, and a daily > limit if you set one. They are the only brake. ## Limits and errors Requests are limited per address. A `429` answer carries a `Retry-After` header. A request body is limited to 64 KiB, and one tool call to 20 seconds. ## Voice A voice interface uses this same door. It is available to approved wallets only for now, and it is not open to everyone. ## Under the hood The MCP server is a separate door from the tool server the console chat uses. It runs inside the gateway process and has no business logic of its own. Each tool is one read that the public gateway already answers, called through the same handler, so the two cannot disagree. The server refuses to start if a tool in its table would write, sign or spend. The tool server that holds the spending tools listens on a private link only, and no public address reaches it. The sign-in follows the MCP authorization section: protected-resource metadata (RFC 9728), authorization-server metadata (RFC 8414), dynamic client registration (RFC 7591), PKCE with S256 required of every client, and resource indicators (RFC 8707). A token is issued for one resource and refused on any other. Tokens are stored hashed. A token that is bad is refused with `401` and never treated as anonymous. → [The gateway](https://docs.defiloops.com/agents/gateway.md) · [Hire a template agent](https://docs.defiloops.com/agents/hire-an-agent.md) · [The agent card](https://docs.defiloops.com/agents/agent-card.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.