MCP Ultimately Leads to Closed Gardens

The Model Context Protocol (MCP) has been advertised as a step toward a more connected and open Internet, where AI agents can seamlessly interact with various services and APIs. However, beneath this promising facade lies a fundamental flaw that I believe will ultimately lead us toward more closed ecosystems rather than the open Internet we were promised. The evidence lies plain and simple in how OAuth is implemented within the MCP framework.

To understand why this matters, we need to first look at how OAuth was designed to work. OAuth exists for good reason. It provides a secure, standardized mechanism for applications to access user data with explicit user consent. In the traditional OAuth flow, any consuming application must obtain its own client ID and client secret through a specific registration process with the service provider. This isn't just for bureaucracy. It's a crucial security feature. Once an application has these credentials, it can only obtain access tokens when users explicitly authorize it. Importantly, if a vendor decides to block a specific application, they can do so because the application is uniquely identified through its token and client ID.

This system has proven its worth in practice. When accessing Google services, for example, applications are subject to strict approval processes where they must undergo security testing to obtain access to sensitive user data. This creates accountability and ensures that only vetted applications can access valuable user information.

But MCP takes a fundamentally different approach. Under MCP, OAuth is implemented implicitly. You can still obtain temporary access credentials, but without the need for client ID and client secret to be present in the consuming application. Why? Because the MCP server controls that information, not the consuming application or AI agent. This might seem like a simplification, but it's actually a significant departure from OAuth's security model.

This shift has already created security concerns that some security teams have obviously begun to recognize. Take Asana, for instance. They've developed their own MCP server, but this server cannot be accessed by just any MCP consuming client. It's only accessible by Claude and ChatGPT only. In other words, Asana has explicitly opted in to be used as an MCP by these two specific clients. Other clients won't have much luck gaining access.

The contrast with Notion, they've decided to allow everyone to consume their MCP. This raises serious questions about whether this decision has gone through any security vetting at all. It's simply dangerous and circumvents the entire purpose of having OAuth application registration features in the first place. Why maintain a secure application approval process when users can access more powerful APIs (like full-text search which has been lacking in the official Notion API) via MCP without any approval or vetting whatsoever?

This brings me to my central concern. What Asana and other vendors have done is not fundamentally different from an iOS app developer opting into Apple's App Store. It's essentially a self-registration process, and while there are no fees at present, the underlying dynamic is remarkably similar, just less explicit. Vendors are choosing which clients can access their services, creating a gatekeeping mechanism that determines who gets to play in their ecosystem.

When you think about it from this perspective, the authentication story that surrounds MCP, especially for the most valuable services on the Internet, isn't really about creating an open Internet at all. Instead, it's about creating what are essentially Anthropic and OpenAI's app stores. Service providers are making conscious decisions about which AI platforms they want to support, creating exclusive partnerships that mirror the closed ecosystem dynamics we see in mobile app stores.

This is my fundamental concern with MCP's trajectory. Despite its promise of openness and interoperability, the practical implementation creates new forms of digital gatekeeping. Rather than democratizing access, MCP is establishing new intermediaries like the major AI platform providers, who become the arbiters of which applications and services can connect with each other.

The irony is obvious. In trying to create a more connected AI, we may have inadvertently created new walls. The question now is whether we recognize this pattern early enough to course-correct, or whether we're destined to trade one set of closed gardens for another.