// use case · agent-inboxes

Give your agents a real inbox.

Spin up an address per agent by API, hand it a Drin MCP key, and it sends, reads, searches and replies on its own threads — with no per-inbox meter. Fifty-four MCP tools, framework adapters for LangChain, CrewAI and n8n, and approve-by-reply for the sends that need a human.

Free sandbox to integrate · Production from $3/month

Pixel-art scene: a row of small pixel robot clerks each at its own pixel letterbox on a shared wall, cable rails running from a central pixel MCP hub to every station and mail flowing both ways with no meters anywhere, a human supervisor stamping one approval at the end of the row — over a pale-blue pixel sky.
// the job

Agents don't need a mailbox metaphor. They need a mailbox.

An agent that can email is far more useful than one that can't — it can follow up, chase a reply, file a ticket, confirm a booking. But that only works if it has a real address that receives, not a fire-and-forget send.

Drin gives each agent an inbox on your domain, created in one API call and operated over MCP. Because you're billed on email volume rather than per address, a fleet of a thousand agents doesn't blow up the bill — and the same account runs your product's transactional and marketing mail for the humans on the team.

Unlimited inboxes54-tool MCP serverNo per-inbox feeApprove-by-reply
#01 — How it works

An address, then a key.

Create an inbox with one POST — loop it for a fleet — then point any MCP client at Drin with an API key. The agent gets send, read, reply and search tools scoped to its own threads.

Read the docs
provision · then operate over MCP
# 1 · give the agent an address
curl -X POST https://api.drin.run/v1/inboxes \
  -d '{ "address": "scout@agents.yourapp.com" }'

# 2 · point the MCP client at Drin
DRIN_API_KEY=drin_k_…  npx @drin00/mcp

# → send · read · reply · search, on its own threads
#02 — What you get

The three that make it work.

DRIN · AGENT INBOXES — WHAT YOU GETSHEET OF 3
01.1An address per agent

POST /v1/inboxes makes an inbox on your domain. Loop it for a fleet — you're billed on volume, never per address.

01.2It operates the inbox

A 54-tool MCP server plus a CLI and framework adapters. The agent sends, reads, searches and replies without leaving its runtime.

01.3A human still launches

Wrap any send in approve-by-reply so the agent drafts and a person releases it — autonomy where it's safe, a gate where it counts.

#03 — Built from

The surfaces that power it.

Not a bolt-on — this job runs on the same platform as everything else you send and receive. One account, one bill.

#04 — Questions

Asked about agent inboxes.

Do I really get unlimited inboxes?+

You create as many inboxes as you need on your domain; billing is on email volume, not inbox count. There is no per-address fee — a fleet of agents doesn't multiply the bill.

Which agent frameworks work?+

The MCP server works with any MCP client (Claude, Cursor, Codex and more), and there are adapters for LangChain, CrewAI and n8n. There's also a CLI and coding-agent skills.

Can agents and my product share one account?+

Yes — that's the point. Your transactional mail, campaigns and every agent inbox live on one account and one bill.

How do I stop an agent from sending something it shouldn't?+

Use approve-by-reply: the agent prepares the send, Drin emails the draft to an approver, and a one-word reply releases it. The thread is the audit trail.

Every job Drin is hired for