A laptop showing Customer.io segments and a journey builder, linked by a connector to a friendly AI assistant

Customer.io MCP: Official Server, Generic API Tools

Yes — Customer.io ships an official MCP server, and it’s hosted by Customer.io itself. It’s a remote server you connect over OAuth, with separate US and EU endpoints, and it’s documented in Customer.io’s own docs rather than being a community project someone published to a registry. If you searched “Customer.io MCP” wondering whether the real thing exists yet: it does.

What makes it unusual is worth reading before you connect it. Most marketing-platform MCP servers hand the AI a fixed menu of tools — create contact, apply tag, start automation. Customer.io didn’t do that. It exposed its API surface instead, which makes it far more capable and slightly more dangerous, and changes how you should set it up.

Customer.io is one of many — the complete list of MCP servers covers every app that ships one, grouped by category.


What Customer.io’s MCP server actually exposes

Model Context Protocol is the open standard that lets an AI client — Claude, ChatGPT, Cursor — talk to an outside app through a shared interface. Customer.io’s implementation gives the AI the full Journeys UI API and CDP Data Pipelines API, routed through a small set of generic tools rather than one tool per action:

  • cio_prime and cio_schema — the AI loads Customer.io’s API reference and discovers which endpoints exist before it calls anything. It reads the manual first.
  • cio_read_api — every GET. Pull a customer profile, list segments, fetch campaign and broadcast metrics, inspect a journey.
  • cio_write_api — every POST/PUT/PATCH. Create a segment, build a campaign, send a newsletter, update attributes.
  • cio_delete_api — every DELETE, kept deliberately separate.
  • cio_skills_list and cio_skills_read — Customer.io-authored guidance for specific tasks, so the model follows the platform’s own conventions instead of improvising.

The practical consequence: if Customer.io’s API can do it, the MCP server can probably do it. That’s a much wider surface than the fixed-tool approach ActiveCampaign took with its MCP server, and it means the interesting work is real — “build me a segment of everyone who hit the paywall twice this week but never started a trial” is a request the AI can actually satisfy against live data, because it can read your actual attributes and event names first.

How to connect it, and the defaults you should leave alone

There’s nothing to host and no API key to paste for the MCP path. Point your client at the endpoint for your region:

  • US: https://mcp.customer.io/mcp
  • EU: https://mcp-eu.customer.io/mcp

Getting the region wrong is the single most common setup failure across every Customer.io integration, MCP included — EU workspaces are on separate infrastructure and the US endpoint simply won’t see your data.

Authentication is OAuth against your own Customer.io login, so the connection inherits your role and permissions rather than granting blanket workspace access. Customer.io’s docs walk through ChatGPT, Claude, and Cursor specifically; if you’re wiring it into ChatGPT, the ChatGPT MCP server setup guide covers the client side.

Three defaults ship conservative, and they’re conservative for good reason:

  1. Read scope only, out of the box. Write and delete are approved separately, on purpose.
  2. Editing live campaigns and segments is disabled by default. An AI that can PATCH an active journey is an AI that can change who receives what, tonight.
  3. Sensitive data access needs admin approval on top of the user’s own permissions.

The temptation is to switch everything on so the assistant stops asking. Resist it on a production workspace. A generic cio_write_api tool with an approving model behind it is a much bigger blast radius than “create contact” ever was.

The credential path you’ll need anyway

Even with MCP connected, most real Customer.io automation runs on the plain APIs — and the credential model trips people up because there are two of them with different auth schemes:

  • Track API — HTTP Basic auth using your Site ID and API key, base64-encoded as site_id:api_key. This is the identify-and-track side: writing people, firing events, updating attributes. Base URL https://track.customer.io/api (https://track-eu.customer.io/api in the EU).
  • App APIBearer token auth with scoped keys you generate yourself. This is the management and messaging side: transactional email, push, campaign and segment data. Base URL https://api.customer.io/v1 (https://api-eu.customer.io/v1 in the EU). Note that the App API doesn’t use the Site ID at all — pasting one in is a frequent 401.

Both live under Account Settings → API Credentials, and App API keys are scoped, so generate a narrow one per integration rather than reusing an admin token everywhere.

What Customer.io already does, and what it doesn’t

Here’s where most “connect your AI to your marketing tool” posts get sloppy, so let’s be precise: Customer.io is already event-driven. That’s the entire product. Event-triggered campaigns fire the moment a matching event lands in your workspace, segments update as attributes change, and reporting webhooks push delivery, open, click, and bounce events back out to you in real time. Nobody needs a third-party tool to make Customer.io react to an event it already knows about.

Two real gaps sit on either side of that.

The MCP server itself has no triggers.

MCP has no trigger mechanism and no scheduler. Its own Triggers and Events working group opens by conceding that clients learn about server-side changes by polling, and that work is still listed as on the horizon rather than shipped.

So the MCP connection is an excellent way to interrogate and build — draft a campaign, audit a segment, pull last week’s numbers — and not a way to make anything happen on its own.

And the money events usually don’t originate in Customer.io. Trial ending, payment failed, and going quiet are the three lifecycle moments with actual revenue attached, and all three are born somewhere else — Stripe, your product database, your analytics. Customer.io reacts to them beautifully once they arrive as track events, which means someone has to build and maintain that pipe. Then its response is messaging: an email, a push, an in-app. The follow-through — flag the account in the CRM, open the task for the CSM, post it to the right Slack channel, check whether a human already reached out — happens in other tools that Customer.io doesn’t reach into.

These assistants can run on a schedule now — ChatGPT Scheduled Tasks and Claude Cowork both do unattended work on a timer. What none of them do is fire on an event: nothing starts because a record changed, a message landed, or a deadline passed. The schedule is the trigger, and the gap between "every hour" and "the moment it happens" is where the work falls through.

Wiring the events that pay, across apps

That cross-app reaction is where Carly fits alongside Customer.io rather than against it. Carly connects to Customer.io natively plus ~260 other apps, and anything else with a public API through your own key — paste them into Carly at carlyassistant.com/integrations. Its workflows are event-triggered, so they start when something happens in any connected app, not when you open a chat.

Concretely, for the three events that matter:

  • Stripe reports a failed payment → fire the track event into Customer.io so the dunning campaign runs, and flag the account in your CRM, and post to #billing with the invoice link and the customer’s plan.
  • A trial hits day 11 of 14 with no key action taken → pull the usage signal, push the attribute into Customer.io so the right journey branch picks them up, and draft the personal nudge from the AE for approval.
  • An account goes quiet for 21 days → summarize what they last did, check whether anyone already emailed them, and open a task on the owner rather than firing another automated email into silence.

Non-AI steps — the moving, matching, and routing between apps — are free and unlimited. The AI steps, the drafting and summarizing and deciding, start at $35/month.

Customer.io’s official MCP server is genuinely one of the better ones, and worth connecting if you spend time building segments and campaigns by hand. It is a way to work on your Customer.io workspace faster. Getting the events that matter into it, and acting on them everywhere else, is a different job.

FAQ

Does Customer.io have an official MCP server? Yes. Customer.io hosts and maintains its own remote MCP server, documented at docs.customer.io. It connects over OAuth at https://mcp.customer.io/mcp (US) or https://mcp-eu.customer.io/mcp (EU), and exposes the Journeys UI API and CDP Data Pipelines API through read, write, and delete tools you approve independently.

Do I need an API key for the Customer.io MCP server? No. The MCP server uses OAuth against your Customer.io login and inherits your role and permissions. API keys — the Track API’s Site ID plus key, or a scoped App API bearer token — are for direct API integrations, and you’ll find both under Account Settings → API Credentials.

Can the Customer.io MCP server trigger a campaign automatically? Not by itself. MCP has no trigger or scheduler, so nothing fires because a customer did something. Customer.io’s own event-triggered campaigns handle that natively once the event reaches your workspace. Reacting across apps — Stripe, your CRM, Slack — needs a workflow tool with event triggers.

What’s the difference between the Track API and App API keys? The Track API uses HTTP Basic auth with your Site ID and API key base64-encoded together, and handles identifying people and sending events. The App API uses a scoped bearer token, needs no Site ID, and handles transactional messaging plus campaign and segment management. EU workspaces use -eu variants of both base URLs.

Ready to automate your busywork?

Carly schedules, researches, and briefs you—so you can focus on what matters.

See what people say

"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.

Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.

On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."

Gus Ibrahim, Founder & Director, IHR