2026-07-21 4 MIN READ

The Multi-Server Marketer: Orchestrating Claude Across Iterable and the MCP Ecosystem

In my earlier posts, I laid out the fundamentals of the Model Context Protocol and walked through what a single-tool workflow looked like with a CLI-driven assistant. Since then, I've moved my own day-to-day tooling over to Claude Code, and that migration surfaced a question worth architecting around: what changes when your AI assistant isn't just talking to one system, but reasoning across several at once?

Iterable's MCP server is still the anchor of that workflow. But the real unlock isn't the server itself—it's what happens when Claude treats it as one node in a larger, composable graph of tools.

1. Getting Claude and Iterable Talking

The Iterable MCP server ships as an npm package, and wiring it into Claude Code is a single command:

claude mcp add iterable -- npx -y @iterable/mcp

Under the hood, this runs over stdio—no long-lived service to babysit, no open port to secure. Claude Code spawns the server as a subprocess, hands it your API key, and from that point forward you're issuing natural-language instructions instead of clicking through campaign dashboards. The same package works with Claude Desktop, Cursor, Windsurf, and Gemini CLI, which matters more than it sounds: your MCP configuration isn't locked to one vendor's assistant. If you switch tools—as I just did—the integration comes with you.

2. Permissions Are the Architecture, Not an Afterthought

What I appreciate most as an architect is that Iterable didn't bolt security on after the fact. The server ships with everything disabled by default, and you opt into capability tier by tier:

  • User PII — read access to emails, phone numbers, and custom profile fields
  • Writes — create, update, or delete templates, lists, catalogs, and campaigns
  • Sends — trigger live messages and campaigns (and it requires Writes to even be reachable)

That staged model is the difference between "an AI that can answer questions" and "an AI that can act," to borrow Iterable's own framing from their MCP server announcement. It also means the risk conversation with your security team is short: you can hand Claude read-only access to interrogate campaign performance for weeks before you ever consider granting it the ability to send. The permission boundary is explicit, auditable, and yours to set—not something you have to trust the model to self-police.

3. Claude as the Orchestration Layer, Not Just the Interface

Here's where it gets interesting. Iterable's MCP server is one of dozens now available—GitHub, Slack, filesystem access, data warehouses, observability platforms. Claude doesn't just talk to one of them at a time; it can hold several MCP servers in context simultaneously and reason across the boundary between them.

That's a structurally different capability than a single-purpose integration. A Zapier-style automation connects System A to System B along one predefined path. Claude with multiple MCP servers connected can improvise the path: it reads intent from your prompt, decides which tools are relevant, and chains calls across systems that were never designed to know about each other.

Concretely, on a given week I might have Claude Code holding three MCP servers in context at once: Iterable, GitHub, and a warehouse connector. None of those three products have any idea the others exist. Claude is the thing that does.

4. A Real Multi-Server Workflow

Here's a workflow that would have taken a ticket, a Slack thread, and two dashboards a year ago—now it's one prompt:

"Check GitHub for any open issues tagged 'email-rendering' from the last week. Cross-reference them against Iterable campaigns sent in that window. If any flagged campaigns went out during an open issue's timeframe, pull their click-through data and summarize whether the bug likely affected performance."

Claude uses the GitHub MCP server to pull the issue list, the Iterable MCP server to pull send history and metrics, and does the correlation itself—no export, no manual join in a spreadsheet. This is the same "source → warehouse → activation" mental model I've mapped out visually in this site's Integration Sandbox, just executed conversationally instead of by dragging nodes. The architecture is identical; only the interface changed.

Conclusion: From Assistant to Architect

Iterable reported that 90% of their customers are already leveraging AI agents somewhere in their marketing programs—so the question most teams face now isn't whether to adopt agentic tooling, it's how many systems that agent should be allowed to see at once.

My answer, after living inside this workflow for a few months: as many as you can wire up safely, because the value compounds. One MCP server makes Claude a faster operator of a single tool. Several, orchestrated together, makes it something closer to a junior architect—one that can trace a problem across your entire stack instead of just the corner of it it's plugged into.

If you haven't set this up yet, start with the Iterable MCP Server on GitHub—the README covers setup for Claude Code, Claude Desktop, and most of the other major clients. Then go find the second MCP server for a tool you already use daily. That's where the real architecture begins.