Thursday, 18th June 2026
I have used MCP servers every now and then in the past, but they have never saved me much time. Last week, however, I got real value out of them for the first time, and I want to share what I learned.
Using an MCP integration as a “glorified form-filling tool” for a service that already offers a purpose-built UI can be useful, but in my experience, it doesn’t meaningfully increase productivity. Instead, the key insight was to use not one but two MCP servers, from entirely different systems that were never designed to communicate, and to use the LLM to connect them.
In my case, I used the Mixpanel and Notion MCP connectors, together with Claude, to build new analytics dashboards in Mixpanel, based on the extensive documentation I had previously written in Notion about our analytics and new onboarding flow. That documentation, together with the implementation tickets, gave Claude enough context to build exactly the dashboards I needed, from only a clear but high-level description of what I wanted. The resulting dashboards only required minimal manual adjustments from me.
I came to see that MCP integrations are not really about interacting with a server in natural language. They’re the piping that an LLM can use to connect or glue together deterministic systems that weren’t designed to talk to each other. And the more services you can wire together in a useful way, the more value they can provide.
For this reason, they are a great tool for prototyping and for producing any stateful output or asset that can be reviewed and refined before it is used or shared. However, I’m a lot less convinced they’ll be useful for building enterprise workflows that automate business processes and need to be robust. At least to date, MCP servers can easily have breaking changes, aren’t versioned, and so on. And the more MCP servers are involved, the more fragile any workflow becomes.
Lastly, my practical advice for the product engineers tasked with building an MCP server is not to think of it as a wrapper around your API, but to ask yourself how to build an interface for your service that is maximally useful when combined with any other existing service, to enable unique and custom use cases for the user.