Your agent needs to send email through Mailtrap: the order confirmation after checkout, the password reset, the test run you inspect before a launch. Mailtrap ships an official MCP server and a full REST API, and at a glance they look like two routes to the same destination. They are not. They deploy differently, they isolate users differently, and one of those differences decides whether your agent survives its second tenant. Here is how to pick.
Both paths call the same backend and carry the same kind of token. What differs is where the code runs and what it was built for.
Mailtrap distributes its official MCP server as the open-source mcp-mailtrap package, maintained by Mailtrap. It first shipped in April 2025 and is still pre-1.0 (v0.9.0 as of September 2026). It runs as a local process: your MCP host, such as Claude Desktop, Cursor, or VS Code, launches it and talks to it over standard input and output. There is no remote URL to point an agent at.
Authentication is a static API token supplied through an environment variable, MAILTRAP_API_TOKEN, alongside MAILTRAP_ACCOUNT_ID for most read operations. The token does not expire. It is the same credential you would use against the REST API, sitting in a config file instead of a request header.
The Mailtrap REST API is a standard HTTPS interface authenticated with an API token, sent as either the Api-Token header or Authorization: Bearer. Tokens have no expiration date and are reset manually; a token can be scoped to specific resources with access levels. Official SDKs exist for Node.js, Python, Ruby, PHP, Elixir, and Java.
The surface is broad: transactional and bulk sending, sandbox testing, templates, sending domains, suppressions, stats and email logs, contacts and campaigns, inbound email, and account management. It is the full surface that both the MCP server and Scalekit's connector wrap.
For a Mailtrap agent, three things matter: what it can do, how it authenticates, and what you operate in production. Coverage turns out to be the least interesting of the three.
The email actions line up across all three paths. The differences are structural, not functional, so a capability table is most useful when it also shows the operational rows.
The rows that separate the paths sit at the bottom of that table: where the code runs, whose credential each call carries, and whether every send is attributable. That is the real comparison for an agent, and it is why coverage rarely decides anything here.
This is where Mailtrap breaks from the usual MCP-versus-API story. With Notion, Slack, or GitHub, the MCP path forces browser-based OAuth and the direct API lets you choose. Mailtrap offers no OAuth for third-party apps, so both paths present the same static API token.
On the MCP path, that token lives in the host config as an environment variable. On the API path, you attach it to each request. Same credential, same permissions, different place it sits. A non-expiring token in a config file is the credential you least want to leak, because nothing retires it on its own.
You can narrow a Mailtrap token to specific resources, but that scopes it to a project or a domain, not to an individual end user. Both paths hand you a token per configuration, not a token per user. In a multi-tenant agent, that distinction is the whole game, and it is exactly the gap Scalekit's connected-account model is built to close.
On the MCP path, you run and supervise a local subprocess inside each host, and you manage the single token it carries. Because the server is local and single-token, it fits a developer's own machine well and a shared backend poorly.
On the API path, you own the full stack: request construction, pagination, retries, error handling, and the entire token lifecycle. Since Mailtrap tokens never expire, rotation and revocation are entirely your responsibility; there is no expiry to lean on.
Observability is the quiet cost on both paths. Mailtrap's own logs show the account a token belongs to, not the end user an agent acted for. If ten customers share one token, the log shows one account, and the send that mattered is indistinguishable from the rest.
Use the official Mailtrap MCP server when:
Use the Mailtrap REST API directly when:
Strip away the transport and both paths leave the same gap: a Mailtrap token still has to be stored, resolved to the right user, and revoked when access ends. Neither path does that for you.
The MCP server binds one token per config, so every run authenticates as that account. The API lets you pass a different token per request, but only if something resolves the right token for the current user first. With fifty customers you have fifty Mailtrap tokens to keep straight, and the path you picked does not keep them for you.
Because Mailtrap tokens never expire, there is no natural point at which a leaked or stale token stops working. When a customer churns or an employee leaves, someone has to find and reset every token tied to that relationship. A token generated months ago and left in a config keeps sending until you kill it. This is the same structural risk described in secure token management for AI agents at scale.
Scalekit's Mailtrap connector stores each user's Mailtrap token in a token vault, resolves it per identifier at call time, and keeps credentials out of the agent runtime. The same infrastructure works whether you call tools directly or expose them through a Virtual MCP endpoint, so the MCP-versus-API decision stops touching your auth layer.
Scalekit exposes Mailtrap as a single API connector, using Bearer Token auth with 92 prebuilt tools. There is no separate Mailtrap MCP connector to choose between; you get MCP-shaped access when you want it through a Virtual MCP server. The walkthrough below is Python with the Claude SDK, and it runs discovery, then scope, then execution.
Create a connection named mailtrap in the Scalekit dashboard first, and set SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET. The connection_name in your code must match the connection you created, or tool calls resolve to nothing.
Because Mailtrap uses a token rather than OAuth, you attach each user's Mailtrap API token to their identity once, instead of running a browser consent flow.
Before the agent runs, ask Scalekit for the tools this user's connected account can call. You get back Mailtrap tools scoped to that identity, already in the schema shape Claude expects, rather than a flat catalog of everything Mailtrap can do.
Pass those tools to Claude and run the tool-use loop. When Claude calls a tool, execute it through Scalekit with the user's identifier, and Scalekit resolves that user's Mailtrap token, makes the call, and returns the result.
Every send in that loop runs against the user_123 Mailtrap token, resolved at call time; the agent code never sees the credential.
The official server exposes over 100 tools, and an email agent needs maybe five. Loading all of them costs tokens on every turn and gives the model more ways to pick the wrong one. A server with 40 tools at roughly 200 tokens each burns about 8,000 tokens before the agent does any work, and Mailtrap's surface is larger than that.
A Scalekit Virtual MCP server lets you define one endpoint that exposes only the Mailtrap tools this agent role needs, for example mailtrap_send_email and mailtrap_list_email_logs, and nothing else. One server definition serves every user; each run gets a short-lived session token scoped to that user's connected account, so there is no MCP server for you to deploy or host. This is part of why MCP can be significantly more expensive than CLI without careful tool scoping.
Because every call runs through a connected account tied to an identity, Scalekit records which user each Mailtrap action ran for. For a tool that sits at the end of the chain, that answers the question raw API logs cannot: did the agent send that password reset as customer A's account or customer B's, and who authorized it. The reasoning behind that model is in the posts on agent tool observability and audit trails for agent auth.
The choice tracks one question: who is your agent sending on behalf of?
If the agent is yours, running in your editor against your own Mailtrap account, the official MCP server is the fastest route. Install it, point it at a token, and send from Claude Desktop or Cursor in minutes.
If the agent sends on behalf of customers, each with their own Mailtrap account, the single-token local server does not fit, and the raw API leaves you to build storage, rotation, and revocation for non-expiring tokens by hand. Put a per-user connected-account layer under either path; that is the part that must be production-grade, whether you call tools directly or through MCP. Understanding credential ownership across agent tool-calling patterns helps clarify why this layer matters.
Recommended Reading: MCP vs APIs: how are they different
Start with the connector, scope it to your agent, then check the numbers before you scale.
Read the Scalekit Mailtrap connector docs for the full tool list and setup, see what the connected-account model unlocks on the AgentKit product page, and review the pricing page before you move to production.
For patterns that lean on transactional email, look at the outbound prospecting agent, the support ticket automation agent, and the incident response agent.
Building a Mailtrap agent and want a second pair of eyes on the auth model? Join the Scalekit community on Slack, or talk to us for immediate help.
