MCP Needs a Browser

MCP isn’t the perfect protocol, but I’ll leave it to other people to complain about it. It has adoption and that is all that matters—our systems can be connected. Sometimes they are connected. But MCP tool use has not remotely broken into the mainstream. Why?

The consumer experience around MCP is horrendous.

1. Discovery: Imagine your parents proactively and willingly taking on the task of “connecting to the Facebook MCP server”, even through relatively simple UIs. The act of searching and the subject of the search are essentially dealbreakers for non-technical users.

   Even if users exceed the necessary technical bar, and even if users know exactly what they want done, they don’t know how to do it. They’re welcome to search the many lists of lists of lists of MCP servers, but it’s a lot of work and unlikely to surface trustworthy, stable results.

   For real, production MCP use today, we essentially rely on developers to proactively integrate MCP servers in the background so we can unwittingly use these servers via the web servers of products we’re already using. Imagine being able to use any given website only after a Google engineer found time & motivation to integrate it into google.com.

   MCP needs a search engine & proactive connection embedded in the model.

2. Connection: Imagine if, every time you went to a website, you had to read a security notice, a privacy notice, approve a terms & conditions popup, and review the structure of JSON payloads the website will be making. This has become more true over time as a consumer (thanks, EU), but the actual browser-server connection itself remains virtually permission-less. MCP servers are servers, not client-side applications. Connecting to a server should be as easy as entering a URL in the browser.

   Obviously, seamless MCP server connection has major security implications. The models & their MCP clients need to be architected to be more sandboxed and trust-less. Ultimately, the protection of the user & user data falls almost entirely within the purview of the model provider. They’ve got the users, the data, and the access to protect, and the new paradigms & architectures will have to flow from them.

   MCP needs to make connection more like a browser than an app store. This requires substantial protections built into the model.

3. Use: Imagine if, on a webpage, you had to manually trigger the correct sequence of API calls to deliver the proper user experience. With MCP, models are left with that impossible task. Invisible dependencies, edge cases, the permutations & combinatorics of all possible tool calls. Such a task is nontrivial even for relatively simple, newer products, let alone massive, complex, legacy systems and all of the unintuitive tech debt they’ve accrued.

   Further, imagine if, in using a webpage, every input to and output from that page had to pass through a model. Would you use such a webpage to wire rent money? Models are non-deterministic. They can be wrong (less and less over time, but they always will). In most systems, there’s at least one action that you want to be direct-to-server and 100% deterministic.

   MCP needs to let server providers own parts of the client within the model.

All of the fundamental blockers to MCP have one thing in common: they’re totally dependent on the model provider to implement. Fortunately, OpenAI is on the right track.

ChatGPT Apps bring MCP one step closer to having a “browser”, but it doesn’t go all the way. I suspect that this is the direction that we’re heading. As with all macro trends, it will take us a while to get there.

MCP is very young, ChatGPT Apps are younger, and the Apps of today are only weeks old. Everything will get a LOT better. We’re building sunpeak to help. https://sunpeak.ai is the ChatGPT App framework that helps developers quickstart, build, test, and ship ChatGPT Apps. Please star us on Github!