Your agent needs to send a transactional email, chase down a bounce spike, or pull last week's delivery stats from Mailgun. Mailgun now gives you two ways in: an official open-source MCP server it publishes on GitHub, and the REST API your backend has probably called for years. They are not interchangeable. They cover different slices of the account, they run in different places, and, unusually, they lean on the exact same credential. Here is how to pick, and what stays your problem either way.
These are the two objects under comparison. You have almost certainly used the REST API. You may not have run the MCP server, so start there.
Mailgun maintains an open-source Model Context Protocol (MCP) server, published to npm as @mailgun/mcp-server under Apache 2.0. It is OpenAPI-driven: at startup it parses a bundled Mailgun OpenAPI spec and registers a curated allowlist of endpoints as MCP tools, generating each tool's input schema with Zod.
One detail dominates every deployment decision: the server runs locally on your machine and communicates over stdio. Mailgun does not currently offer a hosted version. Auth is a Mailgun API key passed as the MAILGUN_API_KEY environment variable, with MAILGUN_API_REGION selecting us or eu.
The Mailgun REST API is the full account surface: sending, domains and DNS/DKIM, mailing lists, suppressions, templates, routes, webhooks, analytics, IP pools, API key management, and account settings. Most endpoints are scoped to a sending domain in the path, for example /v3/{domain}/messages.
Authentication is HTTP Basic Auth: username api, password your API key. There is no OAuth option. The base URL is region-specific: US requests use one host, EU requests another, matched to where your domain lives.
The MCP server exposes a workflow-oriented subset. The REST API exposes the whole thing. The gap is not a bug; it reflects what the server was scoped for.
The table below covers the actions that matter most for email agents. Values are Yes, Limited, or No.
The server annotates every tool with a Mailgun product tag: send, validate, optimize, or inspect. Its security model is deliberate: it exposes read and update operations but registers no delete operations, so a stray prompt cannot clear a suppression list or drop an API key. That is a real safety property for interactive use, and a real ceiling for automation that must delete.
Destructive and administrative work lives in the API only. Clearing bounces, deleting complaint records, rotating DKIM keys, creating and revoking API keys, managing the account IP allowlist, and setting custom sending limits are REST operations with no MCP tool behind them. If your agent's job is account hygiene or key lifecycle, the MCP server is not the surface for it.
Most tools in this series force a choice between OAuth and API keys. Mailgun does not. This changes the whole analysis.
The MCP server and the REST API both authenticate with a Mailgun API key. The server injects MAILGUN_API_KEY into outbound requests; the API expects the same key over HTTP Basic Auth. There is no consent screen, no token exchange, no refresh cycle, because there is no OAuth. Picking MCP over the API does not move you onto a different credential model.
Mailgun does offer some scoping through key types. A primary account API key performs full CRUD across all domains. Domain sending keys are restricted to /messages, /messages.mime, and /events for a single domain. Paid plans add roles such as admin, basic, sending, and developer. These are set at key creation, not derived from whoever is invoking the agent.
Because scope is a property of the key, not the caller, a multi-tenant agent cannot express "act as this customer" through Mailgun auth alone. You either share one powerful key across tenants, which is a cross-tenant risk, or you provision a key per tenant and manage them yourself. What the tenant can do, the agent should do, and no more; Mailgun's key model does not enforce that boundary for you. For a deeper look at why static credentials create systemic risk, see OAuth vs API Keys for AI Agents: Why Static Credentials Break in Production Systems.
The maintenance surface differs sharply because one path is a local process and the other is a raw HTTP contract.
The server manages tool schemas, OpenAPI parsing, and Zod validation. You own the process: it runs on the operator's machine over stdio, so it is a natural fit for desktop and IDE clients and an awkward one for a backend service. It performs no client-side rate limiting; each tool call is a direct Mailgun request, and you inherit Mailgun's server-side limits as raw errors.
You own everything: base URL selection per region, the domain-in-path convention, pagination, retries, error handling, and rate-limit backoff. You also own key lifecycle, since the API is where keys are created, scoped, and revoked. That is more code, and more control over versioning and failure behavior for deterministic pipelines.
The server can narrow its own surface with product tags through MAILGUN_MCP_TAGS or a --tags flag, using OR semantics, so a validation-only workflow need not load send tools. That is coarse, per-process scoping, not per-user scoping. Schemas also move when Mailgun updates the bundled spec and republishes; the REST API lets you pin behavior and migrate on your own schedule.
The split follows from where each runs and what each omits, not from a general preference for one style.
This is the part the path choice does not solve, and the reason this comparison belongs on an agent-auth blog rather than a general dev site.
A primary Mailgun account API key can send from any domain, read every log, and modify account settings. It does not expire on its own, and it is not tied to a human session. Whether that key sits in an MCP client's config or in your API client's environment, its compromise is a compromise of the entire Mailgun account. That is the blast radius you are managing. Understanding credential ownership across agent tool-calling patterns is critical before you ship.
A B2B email agent serving many customers is the norm, not the exception. Each customer has their own Mailgun account or their own scoped key. That is N keys to store encrypted, rotate on a schedule, and revoke the moment a customer offboards. A shared key works in a single-tenant demo and quietly becomes a cross-tenant liability the second a second tenant arrives. The challenges of moving from single-tenant to multi-tenant tool calling auth are worth understanding before you hit them in production.
Scalekit's Mailgun connector holds each tenant's Mailgun key in an encrypted token vault and resolves it per connected account on every tool call, so the key never enters the agent process or the model context. The same infrastructure works whether you reach Mailgun through the API directly or through an MCP endpoint; the path decision does not change what you need at the credential layer. For the mechanics, see the token vault for agent workflows and access control for multi-tenant AI agents.
Scalekit exposes the full Mailgun REST surface as prebuilt, LLM-ready tools (259 of them at last count), delivered with per-tenant credential isolation. The flow is discovery, then scope, then execution. First, install and initialize the client.
Register the Mailgun connection once in the dashboard and paste the API key for the tenant you are onboarding. In code, resolve the tenant to a connected account. Because Mailgun is API-key based, the account is active as soon as the key is configured; there is no OAuth link step.
The agent should not load all 259 tools. list_scoped_tools returns only the tools the current identifier's connected account is authorized to call, in Anthropic's native format. Surface reduction is the lever for tool-calling accuracy and token cost, not better prompting.
Claude picks the tool; your code executes it through Scalekit bound to the same identifier. Every call runs with that tenant's key, and the key stays in the vault.
The same connected-account, scoped-tool, execute-tool pattern works in TypeScript and with LangChain, Google ADK, Mastra, CrewAI, and the Vercel AI SDK. For patterns on how tool calling auth production problems surface across frameworks, see agent tool calling auth production problems, patterns, and anti-patterns.
The official Mailgun server is local, single-key, and single-account. That is exactly the shape a production multi-tenant agent cannot use. A Virtual MCP server closes the gap.
You define a Virtual MCP server once per agent role and select which connections and tools it exposes. Before each run, Scalekit mints a short-lived session token scoped to a specific user's connected accounts. One server definition serves every tenant; the endpoint is static, the identity is not. There is no MCP server to deploy, host, or maintain.
A raw connector can surface dozens of tools; a summarizer needs one. Virtual MCP enforces least privilege at the tool level, so the agent sees only the tools you explicitly allow, not everything Mailgun exposes. That shrinks the blast radius if a prompt goes wrong and keeps the tool surface small enough for reliable selection.
Every downstream tool call is attributed: who authorized it, which agent ran it, which tool executed, and what came back, exportable to your SIEM. For an email agent that can send on a customer's behalf, that audit trail is the difference between "a message went out" and "this tenant's agent sent this message under this key." Agent tool observability is what separates a running agent from one you can actually trust.
If an operator is in the loop and the work is read-heavy exploration of a single account, run Mailgun's official MCP server; it is quick to wire into an AI client and its delete-free surface is a genuine safety feature. If your agent is headless, high-volume, destructive, or multi-tenant, build against the REST API, where the full surface and key lifecycle live.
Most production email agents will lean on the API path, because sending on behalf of customers is inherently multi-tenant. The credential problem is identical either way: one static key is the whole account, and isolating N of them is infrastructure you build or adopt. That is the part worth getting right before the agent ships.
Browse the Mailgun connector on Scalekit and the full connector catalog, or size it against the pricing page.
For patterns to build from, see the outbound prospecting agent, the support ticket automation agent, and the email to calendar agent, or explore all agent use cases.
Building a Mailgun agent and want another set of eyes on the auth model? Join the Scalekit community on Slack, or talk to us for help wiring it up.
