MCP Needs a Browser (April 2026)

MCP has mass adoption. Anthropic reported over 10,000 public MCP servers and 97 million monthly SDK downloads as of early 2026. The protocol moved to the Linux Foundation, working groups are shipping spec updates, and every major AI provider supports it. Our systems can be connected.

But connected for whom? Mostly developers. MCP tool use has not broken into the mainstream because the consumer experience is still broken in three specific ways.

TL;DR: MCP needs browser-like simplicity across discovery, connection, and use. MCP Apps, now supported in ChatGPT, Claude, VS Code, and Goose, are the biggest step yet toward that future.

1. Discovery is still too hard

Imagine your parents searching for and connecting to the “Facebook MCP server.” The act of searching and the subject of the search are dealbreakers for non-technical users.

Even developers who know exactly what they want have to dig through fragmented registries. There is no Google for MCP servers. The 2026 MCP roadmap addresses this with MCP Server Cards, a standard for exposing structured server metadata via .well-known URLs so browsers, crawlers, and registries can discover a server’s capabilities without connecting to it. That’s progress, but it’s still early.

For now, the main discovery path runs through curated directories inside ChatGPT and Claude. OpenAI has rolled out partner connectors from Stripe, Notion, Linear, Google Drive, and dozens more. Anthropic’s Connector Directory has over 50 integrations across communication, project management, engineering, and finance. These directories are the closest thing MCP has to a search engine today.

MCP needs proactive connection embedded in the model, where the AI finds and connects to the right server without users needing to browse a catalog.

2. Connection has too much friction

Every time you visit a website, the browser handles the connection. No security popups, no JSON schema reviews, no approval chains. MCP server connection is the opposite: read a security notice, approve permissions, review tool schemas.

Seamless connection has real security implications, and the MCP roadmap reflects that. The 2026 priorities include enterprise-managed auth with SSO-integrated flows, gateway and proxy patterns for intermediary routing, and configuration portability so a server configured once works across different MCP clients.

The transport layer is also evolving. Streamable HTTP gave MCP a production-ready transport, but horizontal scaling, stateless operation, and session handling across server restarts all need work. The Transports Working Group is actively shipping spec updates to close these gaps.

MCP needs to make connection more like a browser than an app store. That requires sandbox protections and trust models built into the model providers themselves.

3. Use depends too much on the model

On a webpage, you click buttons and fill forms. The server controls the experience. With MCP tools, the AI model decides which API calls to make, in what order, with what parameters. Models are non-deterministic. They make mistakes. Would you wire rent money through a system where every action passes through a model that might get it wrong?

This is the problem MCP Apps were designed to solve. MCP Apps let tools return interactive UI components, dashboards, forms, visualizations, multi-step workflows, that render directly in the conversation. Users interact with deterministic, server-controlled interfaces instead of hoping the model sequences 15 tool calls correctly.

MCP Apps are now an official MCP extension supported across ChatGPT, Claude, VS Code, and Goose. The architecture uses two primitives: tools with UI metadata pointing to a resource URI, and UI resources served via the ui:// scheme containing HTML/JavaScript. The host renders these in a sandboxed iframe with bidirectional JSON-RPC communication.

This means server providers can own parts of the client experience. A payment processor can render its own checkout form. A project management tool can show its own Kanban board. The model still handles discovery and orchestration, but the interaction itself is direct-to-server and 100% deterministic.

Where we are now

When I first wrote this post in January 2026, MCP Apps had just launched inside ChatGPT, and Claude Connectors were a few months old. Since then:

• MCP Apps became an official protocol extension under the Linux Foundation, not just a ChatGPT feature
• Claude, VS Code, and Goose shipped MCP Apps support, making cross-host apps real
• OpenAI expanded to 50+ partner apps with write capabilities for services like Jira, Google Drive, and Notion
• Anthropic’s Connector Directory grew to 50+ curated integrations with custom connector support on paid plans
• The MCP spec added the Tasks primitive for reliable async agent communication
• Server Cards, enterprise auth, and transport scaling are active roadmap items with dedicated working groups

The gap between MCP and a real browser is still wide. Discovery is manual. Connection requires effort. Server-owned UI is still in its early iterations. But every one of these problems now has an active working group and shipping code behind it.

MCP Apps are the clearest signal of where this is heading: a world where connecting to an MCP server feels as natural as visiting a website, and interacting with it is as reliable as clicking a button.

Building MCP Apps today

If you’re building MCP Apps, sunpeak helps you build, test, and ship apps that work across ChatGPT, Claude, and other hosts from a single codebase. The sunpeak Inspector replicates the ChatGPT and Claude runtimes locally, so you can develop and run automated tests without paid accounts or manual 4-click refreshes. Get started with npx sunpeak new and pnpm dev at sunpeak.ai/docs.