KeyID agent-kit: 27 MCP tools that give an MCP client a real mailbox

The gap agent-kit fills: an agent with no return address

An MCP client can read files, run shell commands and query databases, but it has no address of its own. Anything that expects an email counterpart, from a signup confirmation to a support thread, is out of reach. agent-kit closes that gap by wrapping KeyID.ai's email service in a stdio MCP server and exposing 27 named tools. The README frames the pitch in one line: give Claude, Cursor, or any MCP client a real email address, free, with no signup. The target user is someone already running an MCP client who wants message handling inside the same tool loop, not a separate script. The identity tools are the entry point. keyid_provision registers the agent and returns an address; keyid_get_email reports the currently active one. Everything else assumes that step has happened.

Twenty-seven tools, grouped by what they touch

The tool list is not one flat send-and-receive pair. It splits into seven groups. Identity and auth covers provisioning and address lookup. Messages covers keyid_get_inbox, keyid_send, keyid_reply, keyid_forward, keyid_update_message and keyid_get_unread_count. Threads and drafts adds keyid_list_threads, keyid_get_thread, keyid_create_draft and keyid_send_draft. Settings holds auto-reply, signature and forwarding getters and setters. Contacts is three tools: list, create, delete. Webhooks is three more: list, create, and keyid_get_webhook_deliveries for delivery history. Lists and metrics covers keyid_manage_list for allow and block lists plus keyid_get_metrics for usage queries. The breadth is the interesting part. Vacation responders, signatures and forwarding rules are usually configured in a web UI by a human. Here they are tool calls, which means an agent can change how its own mailbox behaves mid-conversation. That is also the risk surface: an agent that can set forwarding can redirect its own mail.

The transport is stdio JSON-RPC, and the mailbox is not local

agent-kit speaks MCP JSON-RPC over stdio, protocol version 2024-11-05, per the README. That is the standard local-server shape: the client spawns the process and exchanges messages on standard input and output. There is no local mail store described. Every tool call is a request to KeyID.ai, whose base URL defaults to https://keyid.ai and can be overridden with KEYID_BASE_URL. Authentication is an Ed25519 keypair passed as hex in KEYID_PUBLIC_KEY and KEYID_PRIVATE_KEY. That design has a clear consequence: the messages are on KeyID's infrastructure, not on your disk. A self-hosted mail server keeps the data under your control and asks you to run and secure it. agent-kit inverts that. You get a working address in one command and accept that the mailbox is a remote service you reach through a keypair. For an agent doing low-stakes correspondence, that trade is reasonable. For anything regulated, the data residency question is unanswered in the README.

Getting it running: two commands and four environment variables

Install is npm install @keyid/agent-kit or yarn add @keyid/agent-kit. For Claude Desktop, the README gives a claude_desktop_config.json block that registers a server named keyid, runs it with npx @keyid/agent-kit, and passes KEYID_PUBLIC_KEY and KEYID_PRIVATE_KEY through env. For any other MCP client, the same process runs directly: npx @keyid/agent-kit, or with an existing keypair, KEYID_PUBLIC_KEY=abc123 KEYID_PRIVATE_KEY=def456 npx @keyid/agent-kit. Four environment variables are documented. KEYID_BASE_URL defaults to https://keyid.ai. The two key variables are marked auto-generated when absent, which is the part worth pausing on. If the server generates a keypair on first run and nothing writes it to a stable location, then the identity is tied to wherever that process put it. The README does not say where an auto-generated keypair is stored or how to retrieve it. Copy the hex values out of the process environment on first provision, or supply your own pair from the start.

Where the documentation goes quiet

Several operational questions have no answer in the supplied material. Sending limits per address are not stated. Deliverability is not discussed, so whether mail from a KeyID address lands in spam is unknown. The webhook tools exist, but the README does not say whether inbound mail pushes to a webhook or whether an agent must poll keyid_get_inbox, and that choice changes the architecture of anything built on top. Key rotation is absent from the tool list: there is no rotate or revoke tool, and no documented procedure for replacing a compromised KEYID_PRIVATE_KEY. The example conversation shows a clean loop, check inbox, then reply by message_id, but it does not show error handling for a send that bounces or a reply to a message that no longer exists. The licence is listed as MIT in the README while the repository metadata shows no licence, so the file may simply be missing from the tree. Treat MIT as the stated intent and confirm the LICENSE file is present before you depend on it.

agent-kit against running your own SMTP and IMAP path

The obvious alternative is not another MCP email server. It is wiring the agent to a mailbox you already control, either through an existing provider's API or through IMAP and SMTP with a library. That approach keeps the messages in an account you own, uses an address with history and reputation, and does not add a third party to the path. The cost is integration work: you write the send, fetch, threading and contact handling yourself, and you manage credentials for the mail account. agent-kit's difference is that it arrives as a finished tool surface. Threading, drafts, contacts, auto-reply, forwarding, allow and block lists are already named tools, and provisioning is a single call. The trade is control for speed. If your agent needs to use an address your team already reads, agent-kit is the wrong shape, because the address it provisions is a KeyID address, not yours. If you need a fresh, disposable address for a bounded task, the finished surface is the point.

Maintenance cost and what the version number tells you

The package is at v0.2.0, released 2026-03-13, the same day as the last push to main. A 0.x version with a release and a push on the same timestamp is a project still settling, and the tool count of 27 is large relative to that maturity. Every tool is a surface that has to keep working against KeyID's API, so upgrades carry a real chance of a renamed argument or a changed response shape. Pin the version in your MCP client config rather than running npx against the latest tag, because npx @keyid/agent-kit with no version resolves to whatever is current at spawn time. The dependency footprint is the counterweight: the server is JavaScript, installed from npm, and the README describes no database, no daemon and no local state beyond the keypair. That is a cheap thing to run. The licence question is the one to close first. The README says MIT, the repository metadata shows nothing, and MIT without a LICENSE file in the tree leaves the grant ambiguous for anyone redistributing the package.

Editorial conclusion

Adopt agent-kit if you are wiring an MCP client to a disposable or low-stakes mailbox and want the tool surface without building a mail integration yourself. Do not adopt it if the mailbox has to survive a lost keypair, if you cannot accept an external service holding the messages, or if you need delivery guarantees the README does not describe. Before connecting anything real, verify three things against the live service: whether a provisioned address can be recovered after KEYID_PRIVATE_KEY is gone, what the actual sending limits are per address, and whether incoming mail triggers a webhook or requires polling keyid_get_inbox.

Official sources

1. Issues
2. KeyID-AI/agent-kit on GitHub
3. Project website
4. README
5. Releases