How MCP Servers Enabled Claude to be my Command Center
There's something I've always loved about working in lifecycle marketing: there is always something new to learn. Early in my career, I leaned hard into email strategy—deliverability, metrics, bounce reasons, spam thresholds, best practices. No matter what I was working on, there was always another layer to go deeper on. I can't fully explain the psychology behind why that energizes me, but it does. Genuinely.
The past year, though, has felt different. Like I've learned more in twelve months than in several years combined—and I'm still just scratching the surface. I'm surrounded by colleagues who are far more technical than I am, and instead of feeling intimidated, I want to go further. I want to understand how to ship PRs. I want to work in my terminal. I want to stop just voice-transcribing into tools and start actually building with them.
That shift started when I first heard the term MCP server.
Breaking Down a Concept I Didn't Fully Understand Yet
When I encounter a new concept I don't fully understand, I have a ritual: I talk through it out loud to myself and diagram it. FigJam, Miro, a whiteboard—whatever's nearby. It helps me translate abstract ideas into something I can actually hold.
When I first encountered MCP servers, that's exactly what I did. The way I came to understand it: an MCP server is a new way for tools to integrate, where the data that lives inside each tool stays housed there—but connections are formed so that data can be accessed across boundaries. No more manually copying information between platforms. No more context-switching just to pull a number or look up a profile.
I was learning about this because Customer.io, where I work as a Product Marketer, was preparing to launch their own MCP server. The marketing angle was straightforward: you could connect tools like Claude to access your customer data living inside Customer.io—segments, attributes, event history, all of it—without ever leaving your AI interface.
What That Actually Unlocked for Me
Even though I'm a bit different from our core ICP (which tends to be an Email Marketer, Growth Marketer, or Lifecycle Marketer), I immediately started experimenting.
With the Customer.io MCP server connected to Claude, I could suddenly do things like:
Identify top users of our product
See how many emails they were sending
Understand how many segments they were creating and how they were using the product
And from that data, I could build something meaningful—full interview scripts, detailed account profiles, behavioral summaries—all inside Claude, without having to manually pull CSVs or ping data teams. The MCP server helped me synthesize and unlock data I hadn't thought to access before, and it genuinely changed the way I think about user data entirely.
The Evolution from Read-Only to Full CRUD
When Customer.io first launched its MCP server in April 2025, it had some natural limitations. It could read data—but it couldn't write, override, or delete. It lacked full CRUD capabilities (Create, Read, Update, Delete).
At the time, that was completely fine. Read access alone was transformative enough.
But fast forward a year, and the expectations have shifted significantly. When you open a tool with any kind of AI agent today, you expect it to be able to take action—not just read. You want it to create. You want it to make changes in the tools you've connected to via MCP. Full CRUD isn't a nice-to-have anymore; it's table stakes.
I'll be honest: a year ago, I was hesitant about this. The idea of an AI taking action on my behalf felt like a big leap. A lot of people felt that way. But I've since come around—because I've seen what it actually enables.
The Light Bulb Moment: Updating Onboarding Emails at Scale
Here's the moment that really crystallized this for me.
I was wearing the Lifecycle Marketer hat—reviewing our onboarding sequences for a specific product feature. We had recently made significant improvements to that feature, but the onboarding emails hadn't been updated. Some copy still referenced "coming soon" functionality that was now very much live. The tone was future tense when it should have been present tense. The framing was outdated.
Five years ago, that would have meant pausing the campaigns, opening each email individually in a browser tab, reviewing every sentence, identifying what was stale, rewriting it, running it through approvals, coordinating with teammates. Meaningful work—but also slow, draining, and deeply manual.
That is not how I handled it this time.
Acting as a Guide, Not a Doer
Instead, I opened Claude and provided two things: a Notion document outlining the feature improvements, and a link to the campaign containing the three-email onboarding sequence.
Then I approached it the way I'd approach working with a capable junior colleague: with clear communication, explicit expectations, and context grounded in best practices. The same skills that make you a good mentor are the same skills that make you effective when working with an LLM:
Communicate clearly and specifically
Outline your expectations upfront
Share relevant background, constraints, and best practices you'd want applied
I'd be lying if I said it was instantaneous. I approved multiple tool calls. I answered clarifying questions. I watched Claude's animated logo signal that something was happening behind the scenes. There was back and forth.
But at the end of that process, Claude provided a summary of exactly what had changed—email by email.
What Changed (and Why It Mattered)
Here's what was updated across the three-email sequence:
Email 1: The welcome paragraph was rewritten. Test prompts were swapped out with introductions to new capabilities. The early access framing of the feature was dropped entirely.
Email 2: Subject lines were updated. Body content was reframed from future tense ("here's what you'll be able to do") to present tense ("here's what you can do now"). FAQs sprinkled across the sequence were updated to reflect current functionality.
What would have taken hours of careful, focused editing—cross-referencing documents, rewriting copy, reviewing for consistency—was done collaboratively and at speed. And I moved from being the person doing all of that work to being the person reviewing and approving it.
That's a fundamentally different way of working.
Claude as My Command Center
Here's where I've landed after a year of leaning into this: Claude is my command center.
I spend the majority of my working day inside it. I rarely touch the UI of other tools directly. Instead, I ask Claude to facilitate tasks toward specific strategic outcomes—and via MCP server connections, it can actually do that across the tools in my stack.
I'm aware that some of my engineering colleagues have declared MCP servers "dead" in favor of in-house agents and other architectures. Maybe they're right at the infrastructure level. But from where I sit—as a non-technical marketer who cares deeply about efficiency and impact—MCP servers are reaching their pinnacle for people like me.
There are things MCP servers offer that in-house agents simply can't replicate. The ability to stay inside one interface while reaching across your entire tool ecosystem. The ability to combine context from multiple sources and execute on it. The ability to move from being the person doing the work to being the person guiding it.
What This Means for Lifecycle Marketers
If you're an Email Marketer or Lifecycle Marketer reading this, here's my honest take:
You don't need to be technical to benefit from MCP servers. You need to be curious. You need to be willing to think about your work differently—less as a series of tasks to complete, and more as a set of outcomes to direct.
The skills that already make you good at your job—understanding your audience, communicating clearly, knowing what "good" looks like—those are exactly the skills that make you effective at working with AI tools. They translate directly.
A year ago, I didn't have the trust or the framework to work this way. Today, I can't imagine working any other way.