> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useotto.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Empire Access Layer (EAL)
> Call Otto AI's x402 services from your own AI agent — Claude Code, Cursor, or any agent runtime. Bring your own x402 key and pay per call today; one-Safe auto-pay is coming. Your payer key stays on your machine and is never sent to Otto.
**Just want the copy-paste path?** The [Agent Quickstart](/getting-started/agent-quickstart) is the fastest way in: fund one wallet with USDC on Base, run one verified script, get your first paid result.
The **Empire Access Layer (EAL)** lets *your own* AI agent — Claude Code, Cursor, Codex CLI, or any agent runtime — call Otto AI's intelligence and tooling directly, paid per use in USDC. Instead of clicking through the [/app](https://useotto.xyz/app) dashboard, you wire Otto's [x402 service catalog](/acp-swarm/x402) straight into the agent you already work in.
There are two ways to pay:
| Path | What it is | Status |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| **BYO-x402** | Your agent uses your own funded x402 wallet to pay each call directly | **Live today** |
| **Funded pull (one Safe, auto-pay)** | Fund one user-owned Otto Safe once; after you activate Otto's unified permission, Otto fronts calls and reconciles their settled cost from the Safe until you revoke | **Coming — not yet enabled** |
The rest of this page covers the **live** BYO-x402 path with working steps, then the **coming** funded-pull vision (clearly labeled, with no steps that don't work yet).
***
## What EAL is for
Otto runs a swarm of agents exposing **81 paid HTTP endpoints** over the [x402 protocol](/acp-swarm/x402) — market intelligence, KOL sentiment, token security, yield discovery, AI research, image/video generation, and more. x402 is a pay-per-request standard: there are **no API keys**. Your agent makes a request, gets a `402 Payment Required`, pays a few fractions of a cent in USDC on-chain, retries with proof, and gets the data.
EAL is the on-ramp for builders and power users who want that catalog **inside their own agent**, not behind the dApp.
**EAL vs. the dApp:** the [/app](https://useotto.xyz/app) Mission Control dashboard is for human users clicking through guided mini-agents. EAL is for *your agent* calling Otto's services programmatically. Same underlying catalog, different front door.
***
## Connect your agent
Start with the hosted read lane to confirm the loop end-to-end. Its policy is **first call free, then pay per call in USDC (x402) — your agent brings its wallet.** The same wallet can then pay those ten intelligence tools through the hosted MCP or call the wider catalog through a direct x402 client.
### Lane 1 — hosted Otto Intel MCP (one free call, then x402)
No signup or API key. The first successful intelligence-tool invocation is free. Every later intelligence call requires a signed Base-USDC x402 payment from the calling agent's wallet; `otto_catalog` remains free and returns the complete live menu. Full detail, tool list and prices: **[Otto Intel MCP](/acp-swarm/otto-intel-mcp)**.
```bash theme={null}
claude mcp add otto-intel --transport http https://mcp.ottoai.services
```
```bash theme={null}
codex mcp add otto-intel --url https://mcp.ottoai.services
```
Customize → Connectors → **+** → Add custom connector → paste `https://mcp.ottoai.services`.
Add it to `~/.cursor/mcp.json` (or `.cursor/mcp.json` for a single project):
```json theme={null}
{
"mcpServers": {
"otto-intel": {
"url": "https://mcp.ottoai.services"
}
}
}
```
Settings → Security and login → toggle **Developer mode**. Then Settings → Plugins → **+** → paste `https://mcp.ottoai.services`.
After the taste, an unpaid tool result contains the route's machine-actionable x402 requirement. The agent signs it with its own wallet and retries the same tool with `x_payment`. The hosted service verifies and settles through the existing paid endpoint; it never receives the wallet's signing key.
### Lane 2 — pay-per-call (BYO-x402)
Two ways to pay, both from a wallet **you** fund and control.
* **Same ten tools through local stdio.** The local MCP server exposes the same ten intelligence definitions and signs each bounded Base-USDC payment from the dedicated wallet configured in that local process. Config below.
* **The wider catalog.** To call other routes, wire an x402 library into your own code (the `x402-fetch` snippet below). Routes that execute rather than read additionally require that route's own account and authorization setup — paying the x402 fee alone does not authorize an underlying trade.
```json theme={null}
{
"mcpServers": {
"otto-intel": {
"command": "npx",
"args": ["-y", "otto-intel-mcp"],
"env": {
"X402_PRIVATE_KEY": "${X402_PRIVATE_KEY}"
}
}
}
}
```
Use a fresh, disposable wallet funded only with the Base USDC you intend to spend, and expose its key only to the local MCP process. The key signs bounded Base-USDC payment authorizations locally and is never sent to Otto. Env-var syntax differs by client — Cursor expects `${env:X402_PRIVATE_KEY}` where the block above uses `${X402_PRIVATE_KEY}`.
***
## What a connected agent can and cannot do
What your agent can reach depends on which lane you connected, so the table says so explicitly.
| | Hosted MCP | Local MCP | Direct x402 client |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Can read** | Ten read-only intelligence tools plus the always-free `otto_catalog`; first successful intelligence call free, then x402 | The same ten intelligence tools through x402 | The catalog's read and query routes — market intelligence, KOL sentiment, token security, yield discovery, SEC and insider filings, tokenized equities, prediction markets, domain trust, web research |
| **Can spend** | The calling agent signs a per-call USDC payment after the taste; the hosted service holds no wallet | Signs a per-call USDC payment from the wallet you fund, capped by that route's price | Signs a per-call USDC payment from the wallet you fund, capped by that route's price |
| **Can execute a trade** | No | No | Not by paying. Execution routes exist on the catalog, but each needs its own account setup and authorization first — paying a fee never authorizes the underlying action |
| **Your payer key** | Stays in the calling agent's wallet; never sent to Otto | Stays in your local process; never sent to Otto | Stays in your client; never sent to Otto |
On **all three paying paths**, Otto receives your payer **address** and the signed payment authorization — that is what settles the call on-chain — along with the request itself. Your key is what never leaves your machine.
**True on every lane, without exception:**
* No Otto Intel MCP tool can place an order, move principal, or sign an arbitrary wallet message.
* Reference prices and scanner output are data — not executable quotes, not recommendations.
* Nothing here can pull from a funded Safe. That rail is built but **fenced**: see [Coming soon](#coming-soon-fund-one-safe-otto-auto-pays) below.
The catalog is **not** read-only in its entirety — alongside the intelligence routes it exposes execution routes for Otto's own trading surfaces. What the table pins down is that reaching those is a separate, deliberate setup step, never a side effect of paying for a read.
**Once provisioned, a client can sign without asking you each time.** That is the point of an agent, but it means the payer wallet — not a per-call prompt — is your real spending limit. Fund it with only what you intend to spend, keep it separate from any wallet holding principal, and rotate it if the machine is shared.
***
## BYO-x402 (live today)
In the "bring your own x402" model, **your agent pays each call from an x402 wallet you fund and control.** Your payer key never leaves your machine — you sign each micropayment yourself, or your agent runtime signs it with the key you provide. Otto serves the catalog and the `402` paywall, and receives your payer address plus the signed payment authorization, which is what settles the call on-chain.
This is the standard x402 flow, and it works against the **live** catalog right now.
### What you need
* An **x402-capable agent or client.** This includes Claude Code / Cursor with an x402 payment tool (for example via [Base MCP](https://x402.ottoai.services/otto.md)), or any client built with an x402 library (`x402-fetch`, `@x402/axios`, `@coinbase/x402`).
* A **funded wallet with USDC on Base** (Polygon and Solana are also supported). Prices vary by route, so read the live `402` challenge or catalog before paying. Use a dedicated, lightly funded wallet — never your main treasury.
### 1. Discover the catalog
Everything is discoverable live — no signup, no key request:
```bash theme={null}
# Human/JSON catalog of all live endpoints + indicative prices
curl https://x402.ottoai.services/otto-x402-catalog.json
# Machine-readable catalog for AI agents
curl https://x402.ottoai.services/llm.txt
# Standard x402 discovery document
curl https://x402.ottoai.services/.well-known/x402
```
### 2. See the paywall
Hit any paid endpoint without payment and you'll get a `402` describing exactly what to pay:
```bash theme={null}
curl -i https://x402.ottoai.services/crypto-news
# → HTTP/1.1 402 Payment Required
# (body describes the USDC amount + chain to pay)
```
### 3. Pay per call
Your x402 client handles this automatically: it reads the `402`, signs a USDC payment from **your** wallet on-chain, retries the request with the payment proof, and returns the data. With a library it's a single call:
```ts theme={null}
import { wrapFetchWithPayment } from "x402-fetch";
import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";
// Your own funded wallet — this key never leaves your machine and is never sent to Otto.
const account = privateKeyToAccount(process.env.X402_PRIVATE_KEY as `0x${string}`);
const wallet = createWalletClient({ account, chain: base, transport: http() });
const fetchWithPay = wrapFetchWithPayment(fetch, wallet);
const res = await fetchWithPay("https://x402.ottoai.services/crypto-news");
const data = await res.json(); // paid, settled, and returned in one call
```
In Claude Code / Cursor with an interactive x402 payment tool, the agent does the same thing through the tool's `initiate` / `complete` payment calls, and that tool prompts you to approve each spend. A client you provision with a key directly — the local MCP server above, or your own `x402-fetch` code — signs without prompting.
The BYO-x402 payment flow is **non-custodial**: Otto holds no keys and signs nothing on your behalf — **your** wallet signs each payment, and what reaches Otto is your request plus the payer address and signed authorization that settle it. The catalog itself carries both read/query routes and execution routes; execution requires that route's own account setup and authorization, so paying a fee never authorizes an underlying action by itself. Start with the cheap intelligence reads (`/crypto-news`, `/kol-sentiment`, `/token-alpha`) to confirm the loop end-to-end before scaling usage.
### Where to look next
* The full endpoint list, prices, and capability tags live on the [x402 Storefront](/acp-swarm/x402) page.
* Prefer on-chain USDC escrow with receipts and reputation for higher-stakes jobs? Use [`acp-cli`](/acp-swarm/acp-cli) instead.
***
## Things to ask once connected
These are **direct BYO-x402** examples — they name catalog routes, most of which are outside the hosted MCP's ten tools. Each route is live on the catalog right now. They are written to read, compare and check — never to place an order.
`Pull /crypto-news and /news-recaps, then /base-ecosystem-news. Give me what actually changed since yesterday, separate reporting from interpretation, and flag anything you could not corroborate across all three.`
`For this Base token, use its contract address with /token-security, /holder-analytics and /token-top-holders, and its symbol with /token-details. Tell me the concentration risk and what the security scan could NOT verify. Do not tell me whether to buy.`
`Compare /kol-sentiment and /tweet-search for this symbol against /token-alpha's price, news and futures data. Where does the social signal disagree with the market data? Call out anything that looks like coordinated posting.`
`Use /yield-alpha and /yield-markets for USDC on Base. Rank by risk-adjusted durability rather than headline APY, state each pool's main failure mode, and say which numbers are point-in-time rather than realized.`
`For this issuer ticker, read /insider-trades and /equity-smart-money. If I also give you a manager CIK or listed manager ticker, add /institutional-holdings for that manager. Separate observed SEC data from your interpretation, note amendment status, and say how stale each filing is.`
`Read /macro-regime, /market-risk and /funding-rates, then /pm-crypto for what prediction markets are pricing. Summarize where these agree and where they conflict — conflict is the interesting part.`
`Run /domain-age, /whois-lookup and /domain-report on this project's domain. Tell me what the current registration record and dates suggest, and what they cannot tell me.`
`Use /web-answer for a quick cited answer on this topic, then /web-search if I need to go deeper. Show the sources and mark anything you inferred rather than read.`
`Check /stablecoin-watch and /protocol-revenue-leaders. Rank by take-rate and 30d fee trend, then tell me what fee and revenue data alone cannot establish about a protocol's incentives.`
***
## Coming soon: fund one Safe, Otto auto-pays
The funded-pull path described below is **not enabled yet.** The headless login flow it would use currently returns a "not enabled" response in production. **Do not** expect to fund one Safe and have Otto auto-pay your agent's calls until this is announced as live. The **live** way to use EAL today is the BYO-x402 path above.
The friction in BYO-x402 is that your agent needs its own funded x402 wallet, and you top it up and manage it. The **funded-pull** model removes that:
* **Fund once.** You'd fund a single **user-owned Otto Safe** (the same [Safe7579 account](/introduction/safe7579-architecture) `/app` is converging onto) — and that one balance would power both the dApp *and* your agent.
* **Activate Otto's unified permission.** You'd sign **once** to install one non-expiring, unrestricted Safe permission for two named Otto runtime operators. Either operator can move funds or change Safe authority until you revoke the permission. The on-chain permission has no spending cap, target list, action list, usage limit, or expiry.
* **Your agent stays keyless.** Your agent would authenticate to your Otto account with a **scoped, revocable token** — **no on-chain key enters the agent's sandbox.** The token allows funded service calls only through Otto's application controls and outstanding-exposure ceilings; those software controls do not narrow the unified on-chain permission.
* **One balance, two front doors.** The same funded Safe would back both the [/app](https://useotto.xyz/app) dashboard and your external agent — fund in one place, spend across the empire.
This trades per-action signatures for broad delegated automation. Your wallet remains the sole Safe owner and the permission requires your signature to install, but the two Otto runtime keys have unrestricted session authority until you revoke it. Revocation removes that permission and known Otto allowances; it does not undo transfers or other durable changes already completed.
**Honest status:** the ownership and BYO-x402 pieces are live; the funded-pull billing rail is **built but fenced** — every enabling flag is off in production, and no funds move through it. We'll document the exact onboarding steps here the moment it's armed. Until then, use [BYO-x402](#byo-x402-live-today).
***
## Summary
* **Live today:** point your own agent at Otto's [x402 catalog](/acp-swarm/x402) and pay per call from your own funded x402 wallet (BYO-x402). Your payer key never goes to Otto; once a client is provisioned it can sign without prompting you, so the wallet's balance is your spending limit.
* **Coming — not yet enabled:** fund one user-owned [Safe](/introduction/safe7579-architecture) once and let Otto auto-pay your agent's calls after you install the non-expiring, unrestricted unified permission — keyless agent, one balance across the dApp and your terminal, controlled by revocation.