MCP has been gaining a lot of traction and generating a lot of buzz in the AI scene. Let's start with the basics.

What is MCP and why was it created?

MCP is a protocol, a set of standards that defines a singular, common way for AI to communicate with external tools and services.

It is made up of clients and servers. In this case, clients can be something like the ChatGPT or Claude app, but can also something like the Cursor editor. Generally the client is what you as the end user interact with. The server is whatever tool you are trying to integrate with the AI client.

Say you want to integrate Asana with Claude. You would take the Asana API, and you would create "tool definitions" for the various actions you'd like the AI to be able to take in Asana on your behalf. Say, reading the list of projects, tasks, creating or updating tasks, etc.

The magic of MCP is that this tool definition is standardised. Without MCP, you would need to create bespoke integrations for each platform (if they even let you). With MCP, you create this server, and suddenly hundreds of the MCP clients out there can use it.

So, what's the problem?

The big picture

Whenever you think about one-size-fits-all solutions, you know, there's got to be some kind of a catch, right? There generally are compromises being made in order to have a single solution that covers all use cases, things like: complexity, a limited set of functionality, constraints.

Think about it. MCP needs to work with every kind of AI tool. It'll work everywhere, but is it the best possible integration story for any given tool or platform? Is an Electron app the best possible integration for any platform? Is a React Native app? It's better than writing custom code for each platform, for the developers, and for the end users, its better than no integration. But, when you have the capacity, you could do better for any given platform.

Protocol changes

One big problem with MCP is that the protocol is a moving target. Since its introduction, it's undergone several changes, some of which break existing integrations.

This causes fragmentation, both on the server side and on the client side. Clients support often only a subset of MCP, and they might not support all server types or work with updated variants of the protocol. The servers might again not support the flavour of the season MCP spec.

Concretely, these are the things that have changed:

• Remote servers moved from SSE to Streamable HTTP, with support now fragmented across clients meaning servers need to implement both, including one that is already deprecated (SSE)
• Auth is a mess. It started with simpler oAuth but moved to dynamic client registration which is not very standard and not widely supported by oAuth libraries and services

Varying client support

Clients pick and choose which bits of the MCP protocol they want to support, and also which flavour of it.

Until a few days ago, OpenAI did not even support MCP fully. If even giants like that are fatigued by the moving target, you can imagine the story doesn't get much better with other clients.

Concretely, dynamic client registration is the current thing and many clients don't yet support that, most servers don't either. Both OpenAI web connectors and Claude remote MCP on web expect different auth systems to be followed. This creates a big headache for server creators who need to work with increased complexity to support the different auth types, or choose to not support the older or newer variant and explain to their customers why their MCP server doesn't work on one or the other client.

Authentication

Deserves its own section.