Mailchimp MCP vs API for production-ready AI Agents

TL;DR

• Mailchimp's only official MCP server is for Mailchimp Transactional (Mandrill), exposed at ^{https://mandrillapp.com/mcp} with 9 tools that mirror the Transactional API. The Marketing API (audiences, campaigns, automations, reports) has no official MCP server; every Marketing MCP on the registries is community-built.
• The official Transactional MCP authenticates with a static Bearer API key, not OAuth. That key is account-level: no per-user identity, no scopes, no per-user revocation. This is the inverse of the usual "MCP equals OAuth" assumption.
• The Marketing API supports two auth methods: an account-level API key (HTTP Basic) and OAuth 2.0 for acting on behalf of other users. Mailchimp Marketing OAuth access tokens do not expire and there is no refresh token, so revocation detection matters more than refresh logic.
• For a multi-tenant B2B agent, OAuth on the Marketing API gives you one non-expiring token per user to store, isolate, and revoke. Neither path stores, isolates, or revokes those credentials for you. That is infrastructure regardless of which path you choose.
• Scalekit's Mailchimp connector handles the per-user OAuth flow, vaulted token storage, and revocation for the Marketing API, so the MCP-versus-API decision does not change your auth infrastructure.

Your agent needs to read and write Mailchimp. You go looking for the MCP server, and the first surprise hits before you write a line of code: Mailchimp ships an official MCP server, but it is the Transactional (Mandrill) MCP, not a Marketing API MCP.

The campaign, audience, and automation surface your agent probably wants lives in the Marketing REST API, which has no official MCP server at all. So the real decision is not "MCP or API," it is "which Mailchimp product does my agent touch, and what does that leave me to build."

Here's how to pick.

What Mailchimp MCP and Mailchimp API actually are

Mailchimp MCP (Transactional only)

The official Mailchimp MCP server is part of Mailchimp Transactional, the product formerly known as Mandrill.

It runs at https://mandrillapp.com/mcp over Streamable HTTP, and you authenticate by passing a Transactional API key as a Bearer token in the Authorization header.

The tool surface mirrors the Transactional API: checking account status, building templates, describing and listing API endpoints, diagnosing failed sends, and a generic call_api tool. It is configured client-side in Claude Desktop, Claude Code, Cursor, or VS Code.

Mailchimp API (Marketing and Transactional)

Mailchimp exposes two distinct REST APIs.

• The Marketing API (^{https://<dc>.api.mailchimp.com/3.0/}, currently version 3.0) covers audiences, contacts, segments, campaigns, classic automations, templates, and reports.
• The Transactional API (^{https://mandrillapp.com/api/1.0/}) covers event-driven single-message sending. Marketing API auth accepts an account-level API key over HTTP Basic, or an OAuth 2.0 access token for accessing another user's account. The Transactional API authenticates with a Transactional API key passed in the request body or header.

Comparing them where it matters for agents

What your agent can actually do

The capability gap here is not "the MCP exposes fewer tools than the API." It is a product-scope gap. The official MCP only reaches Transactional sending; the entire Marketing surface, the part most agents want, is API-only because no official Marketing MCP exists.

The marketing gap is the whole story

If your agent's job is email marketing, querying which campaigns performed best, growing an audience, scheduling a newsletter, the official MCP does not touch any of it. You either call the Marketing API directly or use a layer that wraps it.

The official MCP is the right object only when the agent's job is transactional sending: order confirmations, password resets, receipts.

The auth path each one puts you on

• The official Transactional MCP uses a static Bearer API key. There is no browser OAuth consent, which means it runs headless without a problem. The catch is what that key represents: a Mandrill API key carries full account access, with no scopes and no per-user identity. Mailchimp notes that to combine endpoint restrictions with MCP access, the key must have the "AI Agents" permission group enabled.
• The Marketing API gives you a real choice. An account-level API key, used over HTTP Basic, carries full account access with no scope restriction. OAuth 2.0 is the path for acting on behalf of other users: the user consents in the browser, you exchange the code for an access token, then resolve their data center prefix from the metadata endpoint.

Why non-expiring tokens change the multi-tenant math

There is a quiet but important detail in Mailchimp Marketing OAuth: access tokens do not expire, and there is no refresh token. That removes refresh-loop complexity, but it sharpens the revocation problem.

A token that never expires stays valid until the user explicitly revokes your app inside Mailchimp. Your agent has no expiry to lean on; it only learns of revocation by handling the failure on the next call. In a multi-tenant agent serving many users, that is one long-lived credential per user that you must be able to detect, isolate, and invalidate on demand. This is precisely the kind of challenge covered in depth in how to handle token refresh for AI agents.

What you own in production

The official MCP path hands you Mailchimp-maintained tool schemas and endpoint normalization for the Transactional surface, so you do not hand-write those schemas. What it does not hand you is identity: the API key is account-wide, so you own any per-user separation, key rotation, and the blast-radius problem of a single key that can do everything.

The direct API path means you own the full stack: request construction, the data center prefix resolution that trips up most first integrations, the 10-simultaneous-connection concurrency cap on the Marketing API, error handling, and the token lifecycle. The Marketing API is versioned at 3.0 and changes on a published cadence, which makes it a stable dependency for deterministic pipelines.

When to use MCP, when to use the API

Use the official Mailchimp MCP when:

• Your agent's job is transactional sending and diagnostics, and it lives in an interactive client like Claude Desktop, Cursor, or Claude Code where a developer pastes in the Mandrill key.
• You want Mailchimp-maintained tool schemas for the Transactional surface without writing them yourself.
• The agent is single-account or internal, where one account-level key with no per-user identity is acceptable.

Use the Mailchimp API directly when:

• Your agent does email marketing work: audiences, campaigns, segments, automations, or reports. There is no official MCP for this surface, so the API is the path.
• You are building a multi-tenant B2B product where each customer authorizes their own Mailchimp account and the agent must act as that user via OAuth.
• You need bulk operations, precise control over the data center prefix and concurrency limit, or a versioned contract you migrate on your own schedule.

The credential problem that exists on both paths

N credentials, no vault on either path

Both paths leave you holding a credential per user or per account, and neither gives you a vault, an isolation boundary, or a revocation flow. The official MCP gives you a Mandrill API key with full account reach and no per-user identity.

The Marketing API's OAuth flow gives you a non-expiring access token per user. In a multi-tenant agent, the B2B default, that is N credentials to store encrypted, isolate per tenant, and revoke when a customer churns or an employee leaves. This is a structural pattern explored in credential ownership across agent tool-calling patterns.

A token that never expires is a revocation problem

The non-expiring nature of Marketing OAuth tokens makes this worse, not better: there is no expiry forcing periodic re-auth, so a token leaked or orphaned eight months ago is still live. Detecting and invalidating it is on you.

The work is structurally identical whether you chose the MCP or the API; the credential type differs, the infrastructure required does not. Understanding the role of a token vault in AI agent workflows clarifies why this infrastructure is non-negotiable.

Scalekit's Mailchimp connector handles the OAuth flow, vaulted token storage, and revocation for the Marketing API, so the MCP-versus-API decision does not change your auth infrastructure.

Building on Mailchimp with Scalekit

What the connector covers and why it matters

Scalekit's Mailchimp connector targets the Marketing API surface, the surface with no official MCP, and ships roughly forty-five LLM-ready tools spanning audiences, members, segments, campaigns, classic automations, templates, and reports. The full list lives at the connector docs page.

Tool names follow a predictable pattern, for example mailchimp_campaigns_list, mailchimp_campaign_send, mailchimp_list_member_upsert, and mailchimp_report_get.

Token Vault: the credential never reaches the agent

The connector stores each user's Mailchimp credential in Scalekit's token vault, encrypted at rest and namespaced per tenant. When the agent calls a tool, Scalekit resolves the right credential server-side, calls Mailchimp, and returns the result. The credential never enters the agent runtime and never appears in LLM context.

For a provider whose OAuth tokens do not expire, this is the part that matters most: revocation is a single dashboard action, and the next call for that user fails closed without touching anyone else in the tenant.

Scoped tools, not a flat catalog

In a multi-tool or multi-tenant agent, the surface you hand the model decides accuracy. Before each run, you retrieve the tools the current user's connected account is authorized to call rather than loading the entire connector catalog. The agent receives only what is relevant for this user and this task, which both reduces token overhead and improves tool selection. This approach aligns with the broader principle of tool calling authentication for AI agents.

Discover, scope, and execute in code

The sequence is the same in every framework: retrieve the scoped tool surface for the user, hand those definitions to the model, then execute the tool the model picks. The Node.js example below uses the Anthropic SDK.

The connectionName you pass must match the connection name configured in your Scalekit dashboard; this is the most common integration error.

Exposing Mailchimp through a Virtual MCP Server

If you want an MCP-compatible framework or client to reach Mailchimp without writing a tool-calling loop, Scalekit's Virtual MCP Server gives you a scoped, per-user endpoint.

You create one MCP config per agent role with create_config, declaring which connections and which tools it exposes, then call ensure_instance per user to mint a pre-authenticated URL.

One server definition serves every user; each run resolves that user's vaulted credential.

The agent sees only the tools you explicitly allow, not everything the connector exposes.

A generated Scalekit Virtual MCP URL looks like https://yourcompany.scalekit.com/mcp/v3/servers/<server-id>. The MCP server configuration steps are documented with an end-to-end Claude managed agent example.

Audit logs for multi-tenant observability

Every Mailchimp tool call routed through Scalekit is logged: who triggered it, which tool ran, and what came back, tied to the user who authorized the connection rather than a shared key.

For a Marketing API integration where the underlying credential could otherwise be one account-level token shared across users, this is what keeps per-user attribution and audit accurate when a security review asks who changed an audience or sent a campaign. This kind of visibility is critical for audit trails in agent auth for B2B SaaS.

When a tool you need is missing

Scalekit's Mailchimp connector covers the Marketing surface, but if your agent needs a Mailchimp action that is not yet exposed, or a different tool entirely, you can request it. Reach the team through the Scalekit's Slack community or the Talk to us page.

Which one to build against

• If your agent sends transactional, event-driven email and runs in an interactive client, the official Transactional MCP at ^{mandrillapp.com/mcp} is the fast path, with the understanding that its API key is account-wide and carries no per-user identity.
• If your agent does email marketing work, audiences, campaigns, automations, or reports, there is no official MCP for that surface, so you build against the Marketing API directly or wrap it.

Either way, the credential problem is the same: a per-user or per-account credential that needs storage, isolation, and revocation, made sharper by Marketing OAuth tokens that never expire on their own. That is the part that needs production-grade infrastructure regardless of which path you are on. For a deeper look at why building OAuth internally for AI agents carries hidden costs, the architectural tradeoffs are worth reviewing.

Browse the Scalekit Mailchimp connector.