MCP's Netscape moment

MCP's anniversary

The Model Context Protocol turned one a few weeks ago. What started off as a way to give Claude access to files on my computer has become the de facto standard for agents to interact with the world.

By introducing a common protocol for tools and context, MCP turned ad‑hoc integrations into infrastructure. Implement MCP once, and an agent can take actions on my behalf in GitHub, Google Drive, Slack, Notion, and more.

By setting a standard that was adopted by the leading AI apps, MCP unshackled agents and moved us past simple chat interfaces.

To many, MCP is overhyped for a protocol that is still in its infancy. To become ubiquitous, it needs better UX, stronger security, and better discoverability.

2026 will be MCP's Netscape moment.

Supported by many, adopted by few

MCP has been adopted by the leading labs and frameworks. Recently, Anthropic donated MCP to the Linux Foundation, reducing vendor lock-in risk and addressing long-term governance concerns.

from Anthropic's blog

However, MCP adoption has largely been limited to developers. Three factors explain this:

• Developers are the most likely to experiment with new infrastructure.

• Until recently, adding an MCP server required manually generating and managing API keys.

• Agentic capabilities are most mature in coding environments, where developers already work.

Today, there are more than 16,000 MCP servers but only around 300 clients. This disparity reflects a simple reality: developers are eager to expose their products to LLMs, but product builders struggle to make MCP useful enough for end users.

The path to ubiquity

If the leading labs and the thousands of developers have adopted MCP, why isn't it mainstream yet?

The answer depends on who you are.

For MCP server developers: discoverability and distribution

MCP requires users to manually integrate servers.

This means my mum needs to know that a GitHub MCP server exists, what it enables, and how to connect it to her preferred AI client. This is not realistic for the average internet user.

There has been progress. Cursor introduced one-click client connections. 11.ai probes users to connect MCP servers during onboarding. The official MCP Registry now centralises servers, improving discovery.

The watershed moment for distribution is OpenAI's App SDK. Its ambition is to become the default UI through which AI interacts with the external world, exposing MCP-powered capabilities to chatGPT's 800M WAUs. In that sense, OpenAI is attempting to standardise UI in the same way MCP standardised tool access.

For app developers: reliability and poor DX

When builders first hear about MCP, they expect it to work reliably out of the box. Anyone who has built with MCP knows it's brittle.

Most MCP servers are thin API wrappers that expose tens of tools without clearly defining what each tool does, when it should be used, or how it should be composed. Tool descriptions are often too sparse or too narrow, forcing clients to rewrite them.

Exposing hundreds of tools and schemas directly in the context window leads to context bloat. More input tokens make models slower, more expensive, and often less reliable. Both HuggingFace and Anthropic have mitigated this by invoking tools through code sandboxes rather than raw prompting.

Some of these issues are protocol-level growing pains. MCP evolved quickly over the past year, with breaking changes, multiple transport options, and under-explored features like sampling and roots. Until recently, long-running tasks and multi-step workflows were impossible because the protocol lacked asynchronous support.

Many of these issues are now being fixed as MCP becomes battle-tested. Others are not protocol problems at all, but ecosystem ones.

For users: UX, security and observability

In early 2025, MCP was effectively unusable for non-technical users. Connecting to a server meant manually creating API keys or trusting remote servers with access tokens. Most MCP clients were desktop-only.

Security was also immature. Audits and scans surfaced issues such as unauthenticated servers, prompt injection risks, and over-permissioning. Many of these have since been patched, but they slowed adoption.

More fundamentally, MCP has no notion of an account. There is no user-level cockpit to connect servers, manage permissions, or audit how AI apps access data. Connections are handled per app, with each client independently deciding how to implement security, observability, and access control.

For users, this means no portability across apps, no unified view of data access, and no policy-based control. For enterprises, this is a blocker.

This is not a failure of the protocol. Standards define interfaces, not user experience. But it does explain why MCP has not yet crossed the chasm.

My perspective

MCP is young, but it's on track to become a foundation of the new internet.

I'm extremely excited about what it enables. At the same time, I'm cautious. User control remains weak, security is often bolted on, and many implementations lack product discipline. These gaps are easier to fix early than later.

With friends, I spent a few weekends trying to address some of them.

Nexus is an MCP proxy. Users connect their MCP servers once, then reuse them across apps by connecting Nexus directly. Nexus runs locally to reduce the risk of leaking access tokens and uses OpenEdison to limit data extraction. To fight context bloat, we added keyword-based tool search, making Nexus 93% more token-efficient than a naïve MCP setup. We also added logging, so users can see which tools were called, when, and by whom.

In the new year, you can expect to see Mio ship more around MCP.