Something’s been bothering me lately surrounding the conversation of MCP servers. Everyone, seemingly, is talking about how MCPs are great, and we should be building MCPs, and adopting MCPs, and rethinking UIs with MCPs, becoming best friends with MCPs, getting married to MCPs, you know, the works.

Except they’re not good. Not yet.

If you’ve somehow been living in a cave and don’t know what the acronym of the month stands for, MCP is short for Model Context Protocol. Its a specification started over at Anthropic, designed to create a pluggable architecture for a bunch of concerns we see in things like Agents. One of its most simple value props: it lets you plug in tools to any agent (e.g. Cursor, Claude, etc), as long as they support the protocol. Hypothetically super powerful.

It started as a local server that operated primarily through stdio (standard input, as in piping to a unix socket). A bunch of rapid fire prototypes were built, mostly requiring you to wire up an access token from various cloud services, and boom, MCP was born. That experience kind of sucks though. The world does not off of asking users to go create access tokens, plug them into config files, and debug various running processes on your machine. It didn’t gain a ton of real world traction.

Fast forward a few weeks and MCP announced it would support two extremely important shifts:

1. A better streaming interface, making it easier for developers to incorporate the architecture in existing web environments.
2. Native OAuth support. This is arguably the most important iteration.

I have a belief system that software design largely doesn’t change, so when I saw they were going to support a native, wide-spread authentication flow, I knew there was potential. That combined with a better web spec, and some peers (e.g. Cloudflare) jumping on the super early bird bandwagon, led to shipping Sentry’s MCP. While I’m sure we were not the first, we’re certainly one of the first to support a real world production MCP server from an existing (ugh) enterprise business. We did that because the future of the architecture is compelling, and being able to plug something like Sentry into Cursor makes a lot of sense.

It made so much sense in fact that I decided I’d wing it and put on my YouTuber hat one evening:

If you’ve been following me on Twitter, or you’ve seen any of the videos I’ve published, you’ll note that there’s a huge swath of problems with the current implementation. I promise you, what you’ve seen from me publicly, I’ve barely touched on those problems.

First, OAuth barely functions today. Its not even yet supported by most consumers (e.g. Cursor), so we hack around it by using mcp-remote. Its a great proof of concept, but regularly the authentication breaks and you’re left wiping a random folder from your disk to force it to fix itself.

Lets say you actually get auth working. Great! Except its still not connecting, and none of the consumers give you a shred of detail on why. Some of them handle this better than others, but generally speaking, all of them break in a variety of ways. It’s at best, beta software. One common example of breakage is it will simply fail to connect. It believes (correctly or not) authentication is valid, but is still unable to connect to the service.

Or maybe if you’re really unlucky, it needs npx access (because you’re using mcp-remote) and it can’t figure out how to even launch that process. Even though you’re working on a Node application. Even though Cursor is half written in JavaScript. You probably just configured the JSON wrong tbqh. After all, there’s only one, two, three, an ever expanding number of ways you can configure MCP across clients.

Maybe you actually get it fully working and you can write a prompt that queries it, now you’re in for a fun surprise of infinite permission prompts combined with fairly regular incorrect tool calls. Don’t worry, the people working on the MCPs can fix that by giving more context in their tool definitions.

Oh wait, you’re using VS Code? If you were randomly debugging MCP in an earlier step, you might have the logs open and notice gpt-4o seems to have a 1024 character limit on tool descriptions and then just truncates it? We didn’t want any context anyways. Maybe we just create more dedicated tools to work around it. You know, instead of a search_sentry tool, we expose a search_errors, search_traces, search_logs and we simplify its ability to mess things up. Wow that actually works! Wait I have too many tools? Oh no its calling the wrong tool even more often now!

It must be good though, because companies you didn’t even realize still exist are even buying advertisements for it!

Hopefully you get the point.

Despite what many people on the internet would have you believe, MCP is not ready for mass consumption. Its a beautiful idea that is still very much in its infancy, and while you and I might be able to see what could be, its worth a reality check on what is.

Yours truly,
Someone who likes MCP
And has built an MCP server
Who actually builds technology for a living
While hating everything about hype waves