MCP sucks, mostly 

Yesterday I paired with one of our engineers as part of our pairing-and-sharing internal AI initiative. I wanted to show him how a manager uses AI. My goal was to automate something I do every Friday: I pull data out of our project management system, drop it into a tab in a Google Sheet, and run a few calculations. We had 30 minutes to get it done. It seemed possible!

It was not possible.

The MCP for the project management tool couldn't see my saved reports, so we tried recreating them by sharing my filters. But filters weren't supported. That's how we ended up paginating 800 projects and still getting the wrong answer. Google Sheets, btw, doesn't have a useful MCP either—it can create a new sheet but can't write into a tab on an existing one. I had a Claude-in-Chrome backup plan, but if you've ever written browser automation, you know how that ends. Also, our 30 minutes were up. We accomplished nothing.

While that was failing, we kicked off Claude Code in the background to clean up some Sentry issues. By the time our pairing was over, two PRs were ready for review. This side quest had very different, and more satisfying, results. The difference was less about the vendor than it was the shape of the integration. Sentry's CLI was something Claude Code could drive, the way I'd drive it myself on the command line. The project management MCP was a catalog of endpoints pretending to be tools.

Tool calls are the false idol most MCPs are still chasing, including ours when we started. Wrapping your API as tool calls feels like the obvious move. We found that adds huge complexity and results in sad users. The fix isn't more tools, it's giving the agent something it can use the way a human would.

We figured this out the hard way when we launched our first MCP in April 2025. It supported read-only queries against your workspace. Then we added tools, one per endpoint. The experience failed spectacularly. Every capability we added needed its own tool, and the more we shipped, the worse the model got at picking the right one. One customer hit a wall trying to set up a simple newsletter, and showed us a 90+ back-and-forth of Claude Cowork messages that went nowhere.

Around the same time, we went all-in on OpenClaw-like systems internally. Within three weeks we had forty-something internal instances. The pattern that worked was: read / write / search / execute with one intelligent agent at the center, not a million tools floating around it. (Matthew Newhook, our CTO, wrote up the why here)

That architecture is what our in-product agent runs on, and on May 4 we shipped MCP v2 on top of that same foundation. Same agent, same primitives, same context about your workspace and your goals.

One of our product managers was testing our MCP v2 to build a brand-aligned campaign for his slop app. He was expecting generic “build a campaign" energy. Instead, our MCP found his style guide files already sitting in a directory, built him a full design system in his Customer.io workspace, generated a reusable component library, and composed the email templates from those components, all on-brand in just a few minutes. The end product was closer to his actual brand than our prior website scraper had ever produced. He didn’t need to tell the agent to look for those files and use them as a basis for a component library. It had the right primitives and figured it out.

That's the difference between a tool catalog and an agent. That's why MCPs mostly suck when they’re tool-based. With our v2 architecture, we're finally delivering on the promise. And the customer with the 90+ message exchange? We gave them early access to the new MCP. He told Claude Cowork, “You now have new tool access for Customer.io, what can you do” and the MCP took it from there. It set up the entire email and automation he was trying to create.

If it can be done by a human, an agent should be able to do it. That’s the principle we're holding ourselves to. Tell yours to give it a try: Hey Claude, set up the Customer.io MCP