While AI agents and automation are rapidly changing how we work with data, not every innovation fits every use case. Model Context Protocol (MCP) is a great example: it enables powerful natural language interactions with tools — but it’s not a universal solution. For non-technical stakeholders, MCP can unlock self-service capabilities that were previously out of reach. For technical analysts, however, it may feel more like a shortcut than a solution. In this post, I’ll explore where MCP truly adds value — and where traditional methods still win.

What is MCP and why does It matter?

Model Context Protocol (MCP) is an open interface that allows AI agents like Claude Desktop to interact with local tools, APIs, or scripts using structured metadata. Think of it as a layer between the user’s intent and the real action.

With MCP, stakeholders can type:

“Create a segment of users who started but didn’t finish an application.”

…and get a real CJA segment created behind the scenes — without clicking through complex UI steps. I tried that by using FastMCP (as MCP Server) and Claude Desktop (as interface). It’s pretty straight forward and works as expected.

But while MCP unlocks new capabilities, it’s also important to recognize where it fits — and where it doesn’t.

“MCP is helpful — but not for every use case.”

And I couldn’t agree more. MCP is a powerful protocol, especially when the interface — not the capability — is the bottleneck. But for someone with technical experience, using an AI agent might feel like adding friction, not removing it.

Let’s look at where MCP shines — and where it doesn’t.

1. Not ideal for technical analysts and developers

“As a technical analyst, I don’t want to use it.”

That’s completely valid. If you already live in Postman, use Python notebooks daily, or have direct access to Adobe APIs, you don’t need an AI assistant to run your analysis. In fact, using MCP may feel like asking a butler to go get the ingredients — when you’re perfectly capable of cooking the meal yourself.

MCP often abstracts too much for advanced users:

• It hides the API structure and naming
• It can’t surface nuanced errors clearly
• It may limit the depth of the logic you want to define
• And the back-and-forth with an agent may slow down your workflow

Bottom line: If you already know the system inside-out, agents are not a productivity boost — they’re a detour.

2. Ideal for non-technical stakeholders

“Great to have an agent that does testing for you.”

Now here’s where MCP delivers magic.

Imagine a product owner asking:

“Can you check if the marketing tag is firing correctly on the new signup page?”

Instead of opening DevTools, inspecting the network tab, and sifting through logs, they just type into Claude:

“Test if the marketing tags fire correctly on the signup form.”

Behind the scenes, an MCP agent wired to Playwright does the testing — and Claude responds with:

The signup form triggers signup_start and conversion_success. No JavaScript errors found. Tracking is working as expected.

No need to learn Debug Mode. No need for technical dependency. That’s what we mean by self-service.

MCP allows stakeholders to perform actions that were previously locked behind technical knowledge. That’s a real enabler.

3. Problematic for junior analysts

“It’s bad for juniors — they need to learn the stuff the old-school way.”

Exactly. There’s a risk in over-reliance on agents, especially for those just starting out.

If junior analysts never write an API call, never debug a request, or never navigate the data model themselves, they’ll struggle once the agent hits a wall.

Agents might give the “what”, but not the “why”.

That’s why we must balance enablement with education. Maybe your role as a senior analyst becomes one of guidance:

• Help juniors learn how things work under the hood
• Teach them to read API docs and debug with tools
• Encourage critical thinking and validation of results

Let AI assist — but don’t let it replace foundational understanding.

	Non-Technical user	Technical user
Senior	Self-Service Enabler	Prefers Full Control
Junior / Beginner	Needs Guardrails & Clarity	Needs Structured Learning

MCP as a driver for Self-Service strategy

“If you give stakeholders the right agents, they can do things on their own.”

And this is where MCP aligns beautifully with a modern analytics enablement strategy.

At CSS, with our move from Adobe Analytics to Customer Journey Analytics (CJA), the flexibility and power increased — but so did the complexity. That’s why our self-service strategy includes:

• Clear documentation and learning paths
• Use-case-driven templates and workspaces
• And in future: agent-driven workflows via MCP

With MCP, you can offer stakeholders pre-defined interactions:

• “Create a segment where product = X and action = purchase”
• “Check if tracking works on landing page Y”
• “Generate last week’s KPI summary for department Z”

These are no longer support tickets or manual analyst tasks — they’re agent-powered self-service routines.

Build the right toolbox of MCP tools, wire it into Claude Desktop or another agent platform, and you’ve got yourself a lightweight internal assistant — tailored to your business.

But … agents are only as smart as the system beneath

While agents powered by Model Context Protocol (MCP) offer exciting possibilities for self-service, their effectiveness depends entirely on the groundwork that supports them. They’re not plug-and-play magic — they rely on a solid foundation beneath the surface. First, the infrastructure must be in place: clean, accessible data, reliable APIs, and well-defined access rights form the technical bedrock. But infrastructure alone isn’t enough. There also needs to be a shared understanding of the data: documentation, governance, and consistent naming help stakeholders ask meaningful questions in the first place.

From there, automation and tooling play a critical role. Whether it’s prebuilt scripts, segment builders, or testing flows, these tools are the real hands doing the work behind the scenes — agents simply coordinate them. Only when all of this is in place can the agent layer shine, turning natural language prompts into safe, useful, and actionable outcomes.

Without this full ecosystem — infrastructure, governance, tools, and then intelligence — agents will either fail silently, produce incorrect outputs, or worse, give stakeholders a false sense of confidence. MCP isn’t a shortcut for skipping foundations. It’s a way to scale the value of that foundation across more people.

Next steps: Build your own MCP tool catalog

If you see the potential of MCP in your organization — especially for scaling self-service — the next step is to move from experimentation to enablement at scale.

Here’s what we’re working on next (and what you might consider too):

1. Define common use cases

Start by identifying repeatable tasks that stakeholders often request:

• “Create a segment for X”
• “Test tracking on Y”
• “Generate report for Z”
• “Check if component A exists in workspace B”

Also check which API’s you are currently using, or which API’s are available within your tool stack. These are your candidate tools.

2. Build an MCP tool catalog

Think of it as your internal “app store” for Claude (or any other agent).
Each tool should include:

• A clear name and description
• Required input prompts
• Backend logic (API call, script, etc.)
• Access rules (who can use it)

3. Test and iterate with stakeholders

Roll out gradually:

• Start with power users
• Gather feedback
• Improve tool prompts and coverage

Agents are only as useful as the tools behind them.

4. Document, train, and scale

As with every good self-service initiative:

• Document how to use the agent
• Explain what each tool does
• Train business teams on prompt writing
• Encourage feedback to improve relevance

---

By investing in a well-maintained MCP catalog, you’re not just embracing automation — you’re laying the groundwork for sustainable, scalable analytics collaboration.

Conclusion: The right tool for the right user

MCP is not a replacement for analysts — it’s a bridge for stakeholders. It doesn’t replace critical thinking or data strategy — but it helps others take action when those skills aren’t available.

Used well, it accelerates workflows and democratizes access. Misused, it risks creating shallow understanding and dependency.

The key to success lies in this mindset:

• Empower stakeholders to act.
• Enable analysts to go deep.
• And educate juniors to grow beyond the agent.

That’s how MCP becomes more than just a protocol — it becomes a foundation for smarter, scalable analytics operations.