KeyID agent-kit: 27 MCP email tools for Claude and Cursor

What agent-kit actually gives an MCP client

An MCP client such as Claude Desktop or Cursor can call tools, but it has no mailbox. The README frames the gap plainly: the package exists to "Give Claude, Cursor, or any MCP client a real email address. Free. No signup." The project is a server, not a library you import into your own agent loop. It speaks MCP JSON-RPC over stdio, protocol version 2024-11-05, and exposes 27 tools that map onto mailbox operations: keyid_provision to register an agent and get an address, keyid_get_inbox for fetching with search and filtering, keyid_send, keyid_reply, keyid_forward, thread and draft tools, auto-reply and signature and forwarding settings, contacts, webhooks, allow and block lists, and keyid_get_metrics for usage. The intended user is someone who already has an MCP host running and wants mail to appear inside it, not someone building email infrastructure. The README's example conversation shows the shape: the user asks the agent to check mail, the agent calls keyid_get_inbox, lists three messages with senders and ages, and then replies through keyid_reply using a message_id and body. Everything the agent does is a tool call; there is no separate SDK surface described.

How the MCP server talks to KeyID.ai

The architecture visible in the repository is a single Node entry point. package.json sets main to src/index.js and registers the same file as the keyid-mcp binary, and the published files array contains only src. That means the npm package is the server plus its tool definitions, nothing else. The README states the transport is MCP JSON-RPC over stdio, so the host spawns the process and exchanges messages on standard input and output rather than over a port. Every tool call is then resolved against the KeyID.ai API, whose base URL comes from KEYID_BASE_URL and defaults to https://keyid.ai. Authentication is a keypair: KEYID_PUBLIC_KEY and KEYID_PRIVATE_KEY are described as Ed25519 keys in hex, and both are marked auto-generated when absent. This is the design decision worth noticing. The MCP host holds no mail state; it holds a keypair and a base URL. If the API is down or the keys are wrong, the tools fail at call time, and the README does not describe a local cache, an offline queue, or a retry policy. The protocol version is pinned to 2024-11-05, which is what the README claims compatibility against.

Installing agent-kit and sending a first message

The package is on npm, so installation is a normal Node install. The README gives two equivalent commands:

npm install @keyid/agent-kit
# or
yarn add @keyid/agent-kit

For Claude Desktop the README instructs you to add an entry to claude_desktop_config.json, with the server launched through npx and the two key variables passed in env:

{
  "mcpServers": {
    "keyid": {
      "command": "npx",
      "args": ["@keyid/agent-kit"],
      "env": {
        "KEYID_PUBLIC_KEY": "...hex...",
        "KEYID_PRIVATE_KEY": "...hex..."
      }
    }
  }
}

After restarting the client, the keyid server should appear in the tool list, and the agent can call keyid_provision to register and receive an address. If you want to run the server outside a host, the README shows both the bare invocation and one with an existing keypair:

# Run directly
npx @keyid/agent-kit

# Or with existing keypair
KEYID_PUBLIC_KEY=abc123 KEYID_PRIVATE_KEY=def456 npx @keyid/agent-kit

What you should see on a bare run is a stdio process waiting for JSON-RPC input, not a prompt. Because the README says the keys are auto-generated when omitted, a first run without env vars will create a keypair, and you should capture it if you want the same identity on the next run. The README does not say where that generated keypair is written, so treat the first run as something to observe rather than assume. Once provisioned, ask the agent to check mail; it should call keyid_get_inbox and return a message list in the format shown in the README's example conversation.

Where agent-kit stops being the right tool

The server is a client of a hosted service, and the README is explicit that it is "Powered by KeyID.ai" and that the address comes from that provider. There is no documented self-hosted mode, no SMTP or IMAP configuration, and no local store of messages. If your requirement is that mail never leaves infrastructure you control, this package cannot meet it, because the only path described is HTTP to KEYID_BASE_URL. The second constraint is the keypair. KEYID_PRIVATE_KEY is an Ed25519 private key in hex, and the README's Claude Desktop example puts it in plaintext inside claude_desktop_config.json. Anyone who can read that file can act as the agent's mailbox. The README does not describe key rotation, revocation, or a secrets-manager integration. Third, the tool surface is broad: 27 tools including webhook creation and forwarding settings. An agent with all of them enabled can change how mail is routed, not just read it, and the README does not describe per-tool scoping or a read-only mode. If you want an agent that only summarizes an inbox, this is more capability than the task needs, and the extra tools are the part you would have to fence off yourself.

agent-kit compared with wiring your own MCP server

The real alternative is not another email product; it is writing the MCP server yourself against whatever mail API you already pay for. The difference is where the work sits. With agent-kit you install one npm package, paste two keys, and get 27 tools whose names and arguments are already defined, at the cost of depending on KeyID.ai and on the package's release cadence for fixes. With your own server you write the tool definitions, the JSON-RPC handling, and the auth against your existing provider, and you keep control of the data path and the tool list. That is more code, but it is also the only route if your provider is not KeyID.ai. The repository gives you a partial head start either way: src/index.js is the whole server, and package.json publishes only that directory, so reading it before adopting is a small job. Note also that the project name collides with unrelated things. A search for "agent kit" returns OpenAI's AgentKit and other toolkits, and the package here is specifically the KeyID MCP email server, not a general agent framework.

Maintenance, version 0.2.0, and the licence question

The last push to the default branch was on 2026-03-13, the same day v0.2.0 was released, so the repository is not archived but it has been quiet since that release. Treat the version number as a signal: 0.2.0 means the tool names, arguments, and env variables can still change between releases, and an MCP host config that pins npx @keyid/agent-kit without a version will pick up whatever is current. Pinning the package version in the config is the cheap way to avoid a silent tool-schema change. On licensing, the README ends with an MIT section and package.json declares "license": "MIT", while the repository metadata supplied for the project lists the licence as unknown. The README and package.json agree with each other, so the practical step is to confirm a LICENSE file exists in the repository before you depend on MIT terms for redistribution. Nothing here is legal advice, and the discrepancy is worth resolving with whoever handles compliance at your organisation rather than assuming either answer.

Editorial conclusion

Adopt it if you already run an MCP client such as Claude Desktop or Cursor and want an agent to read, send and file mail without building mail plumbing yourself. Avoid it if you need a self-hosted mail stack, an audited data path, or a provider you can swap without rewriting tool calls, because every one of the 27 tools calls KeyID.ai over the network. Before rolling it out, run npx @keyid/agent-kit with KEYID_BASE_URL pointed at a staging host, confirm which keypair the process generated, and check the licence file in the repository, since the README says MIT but the GitHub metadata lists no licence.

Frequently asked questions

Official sources

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