Give OpenClaw agents an email inbox
OpenClaw takes a TypeScript extension file rather than an MCP server. Drop one file in ~/.openclaw/extensions/ and every agent gets native Anjal tools.
OpenClaw is the odd one out on this list, and in a useful way. Every other client here connects to Anjal over MCP. OpenClaw loads TypeScript extensions from a directory at startup, so the integration is a file you own rather than a server you point at.
That is more code than claude mcp add, and you get something back for it: the tools are yours, so you can name them, narrow them, and refuse to expose the ones you do not want an agent to have.
Connect it
Copy the extension to ~/.openclaw/extensions/anjal.ts and set MYAGENTMAIL_KEY in OpenClaw's environment. The full file is in the OpenClaw extension KB article; the shape is:
// ~/.openclaw/extensions/anjal.ts
import type { ExtensionApi } from "openclaw/extensions";
const API = "https://anjal.app/v1";
async function mam(method: string, path: string, body?: unknown) {
const r = await fetch(`${API}${path}`, {
method,
headers: {
"X-API-Key": process.env.MYAGENTMAIL_KEY || "",
"Content-Type": "application/json",
},
body: body ? JSON.stringify(body) : undefined,
});
if (!r.ok) throw new Error(`mam ${method} ${path} → ${r.status}: ${await r.text()}`);
return r.json();
}
export function register(api: ExtensionApi) {
api.registerTool({ /* send, list, reply, create inbox … */ });
}
OpenClaw loads any .ts file in that directory at startup, so there is no registration step and no restart dance beyond restarting OpenClaw itself.
The trade, stated plainly
What you give up compared with MCP: you hold an API key in an environment variable rather than going through OAuth, and you maintain the file when our API adds something you want. There is no dynamic tool discovery, so a new Anjal endpoint does not appear in OpenClaw until you add it.
What you gain: the tool surface is exactly what you wrote. Our MCP server exposes 47 tools, which is right for a general assistant and too much for a narrow agent. In an extension you register four, or three, or only send_message and list_messages, and nothing else is reachable even if the model asks for it. For an agent you are deploying rather than chatting with, that is a real advantage.
Which key to put in the env
Not your tenant master key. Use a workspace-scoped wk_ key: it reaches one workspace and cannot list, read or send from any other, or see that any others exist. Your plan gives you one workspace per inbox, so a workspace per agent is usually affordable.
If a single agent only ever needs one mailbox, an inbox key (ak_) is narrower still and cannot leave that inbox at all. Choose the smallest thing that does the job, and remember that an env var in a long-lived process is easier to leak than an OAuth token you never see.
What to register
The four that cover most agent loops:
| Tool | Endpoint |
|---|---|
| Send | POST /inboxes/:id/send |
| List messages | GET /inboxes/:id/messages |
| Read a thread | GET /inboxes/:id/threads/:threadId |
| Reply in-thread | POST /inboxes/:id/reply/:messageId |
Reply matters more than it looks. Anjal writes Message-ID, In-Reply-To and References for you, so a reply arrives as a continuation in the recipient's client rather than as a new conversation. If you hand-roll a send instead of using the reply endpoint, you lose that.
Add POST /inboxes/:id/drafts when anything the agent writes should be read by a person before it goes out. For an agent running on someone's machine unattended, that should be most things.
The inbound side
Whatever your extension returns from list_messages goes into the model's context, and it was written by a stranger. Anjal screens every inbound message on the ingest path and quarantines what it judges hostile before it can be read, and an agent cannot release its own quarantine. We publish the architecture and not the rules.
That is a floor, not a boundary. Agent safety sets out what detection cannot do and the three rules that hold, of which the load-bearing one is: decide which senders may trigger which tools, and enforce it in your extension code rather than in the prompt. An extension is a good place to do that, because you own the code path.
Cost
Starter is $5/month for 2 inboxes and 6,000 emails. Developer is $15/month for 10 inboxes and 20,000 emails. Extra inboxes are $2/month each. 7-day trial.
Next
- The full extension file
- Connect Anjal to Claude Code if you would rather have MCP
- Agent safety
Extension shape from our own OpenClaw KB article, last reviewed 2026-09-28.
Other clients
- One command, then sign inClaude CodeConnect Anjal to Claude Code with one command. Your coding agent gets a real inbox it can read, reply from and thread, plus a calendar, over MCP.
- Add, then log inCodexConnect Anjal to OpenAI Codex with codex mcp add and a login. Your agent gets a real inbox it can read, reply from and thread, plus a calendar.
- One JSON entryCursorConnect Anjal to Cursor by adding one entry to mcp.json. Your editor's agent gets a real inbox it can read, reply from and thread, plus a calendar.
- Org admin adds it onceDevinAdd Anjal to Devin from the MCPs tab or with devin mcp add. An autonomous engineer that can receive mail can report in, and get itself past a signup wall.
- One connector, OAuthLovableAdd Anjal as a custom MCP server in Lovable's Connectors. Chat connectors are on by default on every plan, so it is one URL and an OAuth click.
- Two clicks, no fileReplitAdd Anjal as an MCP server in Replit's Integrations page. Two clicks, no config file, and it works across every project on your account.
Setup last verified 2026-09-28. Clients change their config formats; if a command here is wrong, tell us at kamal@send.anjal.app.