Feeling behind on MCP? Here’s what three insiders shared at MXP San Francisco.

At MXP San Francisco, three executives who've shipped MCP products joined us for an honest conversation that didn't sound like most vendor panels. No polished talking points about the agentic future. Just the reality of what it's actually like to build with MCP right now: what's working, what isn't, and what they wish they'd done differently.

On stage for the MCP discussion: 

The first thing that stood out was how reactive each company's MCP journey actually was.

Customer.io launched their MCP server in April 2025. Paul said it came from two places: an internal marketing team that was increasingly AI-savvy and "begging" for a way to work inside Claude, and a clear sense that the industry was moving in that direction. 

Their first version was read-only. They shipped it and immediately felt the gap between where they were and where customers wanted to go.

"We shipped our MCP and immediately fell behind. That feeling has not gone away, but I've come to appreciate it." 

OneSignal's story was almost the opposite. Ellen said they were actively fighting the urge to build MCP. It didn't match their typical go-to-market focus. Then a customer built it for them. "They said, we love the platform and we want to use it through MCP, so here you go, please build it." That pushed it onto the roadmap.

Francis described HG Insights’ approach as building primarily to learn, getting it into customers' hands to see what they'd actually do with it, rather than shipping to a predetermined use case. One of their biggest learnings: there are a lot of tinkerers. People who want access to the MCP, who are excited about the ecosystem, but whose willingness to pay doesn't necessarily follow. "MCP is kind of a stepping stone to something much bigger around agents," Francis said. "That was a pretty significant learning after six to nine months."

The through-line: nobody had a master plan. Everyone was reacting, and learning faster than they were building.

This was the sharpest insight of the session, and it came up in multiple forms throughout the conversation.

Francis made the case directly: wrapping an API in MCP is trivial. Any engineer can do it. The actual value of the MCP protocol, the part that's genuinely hard to replicate, is the ability to embed subject matter expertise into the tool itself. Through prompts, resources, and context that help the LLM understand not just what to do, but why and how. 

"If you just ship a technical tool, it really isn't going to help your customers that much," Francis said. "The beauty of the MCP protocol is the prompts, the resources. All of that is basically a way for you to condense your subject matter expertise into a tool."

Paul connected this directly to Customer.io's actual competitive position. They were about to sign a six-figure deal with a vendor when they realized they could build the same thing themselves in a couple of days using AI. That made them paranoid. If they could do it, couldn't their customers do it to them? The technology had been commoditized, but something else hadn't.

"The premium on the MCP technology is gone. But the premium on the insight isn't." 

The insight: proprietary data signals, complex integrations, years of understanding how campaigns perform. None of that gets replicated over a weekend. That's where Customer.io focuses now.

Francis pushed this further into positioning territory. The CFO problem is real: the idea that an engineer could build a functional version of your product in a weekend is now lodged in every budget conversation, whether or not it's true. The response can't be features. "We can't sell on features and capabilities anymore. We really have to shift on subject matter expertise that we've embedded... That's really what you're paying the software for."

That’s the question "quietly freaking out every PM in the room." If users are accessing your product through Claude or ChatGPT and never logging into your interface, how do you retain them? What are you even building?

Ellen gave the most grounded answer. When OneSignal looked at what customers actually wanted, the majority weren't asking for maximum flexibility to build everything themselves. They wanted something that works, which she summarized as: 

"It hasn't been our experience that they only want to be accessing OneSignal through MCP."

Francis pushed back on the framing itself. The question of UI vs. no UI is a technology-first question, and it's the wrong starting point. 

Use cases should drive the format decision. His analogy: early Tesla cars replaced every physical knob with a touchscreen, which was technologically impressive. But a knob for the temperature that's always in the same place doesn't require you to look at it. A touchscreen does. "What seems like a great technological feat isn’t necessarily a great user experience."

The point: When the whole point is spotting a trend or detecting outliers, a visual interface does what text can't. The form factor should follow the job to be done, not the hype cycle.

If a customer never logs into your UI because they're doing everything through MCP, how do you know it's working? How do you prove ROI?

The honest answer from the panel: it's hard, and pretending otherwise isn't useful.

Tool call volume is the obvious metric, but it’s also largely meaningless in isolation. As Francis explained, a raw count of calls to something like "view subscription status" tells you almost nothing about what the user is actually trying to accomplish. But if you're monitoring which prompts and resources are activating the richer elements of the MCP protocol, you can start to infer intent, such as:

"That will give you a lot more insight into what people are trying to do."

Ellen's approach was more qualitative: partner closely with customers, because interest and actual usage are not the same thing. The question to answer is whether MCP is genuinely simplifying workflows and delivering outcomes, not just whether people connected to it once.

Paul added a metric that surprised the room—deals. Customer.io is increasingly seeing MCP and AI functionality become a deciding factor in renewals and new business, even when the ROI is hard to quantify directly. "The metric there is we're closing a lot more deals based on winning them just on our feature set."

To their credit, nobody held back when asked where the MCP hype was going.

Though he still believes in it, Paul went first and didn't mince words: the MCP user experience right now is genuinely rough. Slow, unwieldy, hard to manage state across tool calls. 

Customer.io is building a durable foundation with a clean API surface, CLI, in-product agent, and MCP server stacked on top of each other. Even with all of that, the promise hasn't arrived yet. "You can see the tantalizing—it could be useful—and then feel that." His spicy take: MCP is a product, not a checkbox, and needs to be treated like one.

Francis offered a reality check on the discourse:

"Don't believe what you're seeing on LinkedIn or X. If you've solved even a single problem with MCP, you're way ahead of the curve." 

He had a name for it: ‘AI theater.’ Setups that look impressive until you ask what anyone's actually doing with them. The answer is often nothing. The field is still in its infancy. Security risks are real and largely unaddressed and what customers ultimately want isn't MCP. The MCP is just one way to get there.

Ellen's take was personal: she connected a bunch of MCPs, felt liberated, and stopped using most of her SaaS tools. Then her environment got messier and harder to maintain. Eventually she found herself going back to the products she pays for, because those products had built agents she found herself gravitating toward anyway. The lesson: Think of MCP as the entry point, not the finish line.

Francis's prediction: within a year, the conversation will have shifted from MCP to agents. Just like people stopped thinking about APIs once the SaaS applications built on top of them were good enough, the underlying protocol will fade into the background. "What we want is for the job to be done."

To close, Marissa asked each panelist what they'd change if they were starting from scratch today.

Paul: Don't bet on tool chaining. Chaining tool calls to share state across an MCP server is a path to pain: hard to manage and hard to debug. Customer.io went down that road early and changed course when it became clear the read/write/search/execute paradigm fit their product better. Starting from scratch, he'd skip the chaining entirely.

Ellen: Talk to your API cohort, not just your dashboard users. OneSignal historically focused on understanding customers who came into the product interface. The customers building on the API, a different profile with different needs, weren't getting the same attention. That's the cohort most likely to be building with MCP, and the most likely to tell you what they actually need.

Francis: Invest more in prompts and resources, and less in raw tools. The tools are relatively straightforward. The harder, more valuable work is embedding subject matter expertise, helping the LLM understand what questions your customers are actually trying to answer. And if you're going to invest in agentic workflows, think about whether MCP is really the right end state, or whether a CLI or API call, once the workflow is locked in, is actually more reliable.

"MCP is great to explore what's possible. Then once you have the workflow locked in, a CLI or API call is actually just as good."

Marissa closed the session with something worth repeating: the teams handling this shift best aren't the ones with the most certainty. They're the ones cutting through the noise, staying close to customers, recognizing that expertise is genuinely hard to replicate, and being honest about what they don't know yet.

If you feel behind on MCP, don’t worry. So does everyone building with it. To learn more about what Mixpanel's MCP server can do, read our Docs page or start here.