MCP Today: Protocol Limitations

Are you building a multi-user agent with MCP—or creating an MCP server? Read on, I will show you that MCP server locks agent to one user and one provider—and how to break through that limit.

How We Got Here—The Two MCP Specs

Before we dive into the limitations, here’s a recap of the two current MCP versions and how they’re used in the real world.

2024‑11‑05 (spec v1)

• Transports: stdio (local) and HTTP+SSE (remote, streaming).

• Typical deployments: One server per user. Popular with quick personal setups.

• Clients that speak this spec: Claude Desktop, Cursor, Windsurf, Cody, and most IDE plug‑ins.

• SSE Servers in the wild: Zapier AI Actions, Composio MCP—all expose HTTP+SSE endpoints tied to a single user’s secret key.

• Agentic Frameworks: Vercel AI SDK, Agno, LangChain, OpenAI Agents SDK, CrewAI (planned), and LangGraph all support v1 via stdio and/or SSE transports.

2025‑03‑26 (spec v2, latest)

• What changed: Introduces Streamable HTTP (optional SSE) and a formal OAuth 2.1 flow so a single server can serve many users.

• Current reality: As of April 2025, zero public clients ship v2; everyone is still on v1 transports. A few providers (including Cloudflare’s reference stack) have prototypes, but nothing is production‑ready. Agentic frameworks do not support v2 yet.

One Server, Two Roles

One of the biggest practical gaps in the MCP spec is role separation. In the v1 deployments the same person has to both configure the server (upload secrets, choose tools) and use those tools through their agent—because v1 never standardised authorization.

• Builder: Sets up the MCP server, connects external providers, stores credentials.

• End‑user: Interacts with the agent that calls the server to perform real work.

The latest spec version 2025‑03‑26 introduces the OAuth 2.1 flow so an MCP server can identify the respective end-users. That lets a single hosted server support multiple users while the builder role remains in control of which prompts, resources and  tools are exposed. Unfortunately clients have NOT embraced the v2 transport with auth flow as of April 2025, so the feature is stranded on paper.

Handling Multiple Providers

MCP ties each server to a single external service (API). That simplicity keeps the spec tidy, but it does have drawbacks.

• One server, one provider. Want Marketstack and Google Sheets? You’ll need to connect to two separate MCP servers. It may not be a huge issue, but a complexity shifts to the MCP client. The client has to maintain multiple SSE connections and manage separate configurations for every MCP server.

• A registry or generator to the rescue. If a provider hasn’t published an MCP server, you don’t always have to build one by hand. Community registries and generators can turn an OpenAPI spec into a runnable MCP server in minutes—lifting that burden from agent builders.

Public vs. Private MCP Servers: Know Your Options

The choice between a public or private MCP server depends on the tool access model:

• Public MCP Server: Best for user-specific tools (e.g., CRMs, personal calendars). Each user connects their own accounts, and the builder configures the integration.

• Private MCP Server: Suited for shared tools (e.g., company-wide search, shared Slack bots). Builders preload shared credentials, and all users can access tools instantly without individual setup.

Superface: One Server, Many Users & Providers

Superface proves an MCP server can overcome both constraints—single user and single provider. It runs as a stdio proxy connected to the Superface Hub, which can operate in either public or private mode:

• Public: Builders register and configure tools from multiple providers; end‑users supply their own credentials the first time a tool is called.

• Private: Builders preload shared, "commodity" capabilities (e.g., a company‑wide web‑search API, exchange‑rate feed, or Slack bot) together with service credentials. End‑users can then use those tools immediately—no personal secrets and still no Superface account.

Whether credentials are shared or user‑specific, they’re stored securely and isolated per user.

Built-In Benefits:

• Multi‑provider out of the box. A single instance can expose any mix of tools—Google Sheets, CRMs, payment APIs, or custom endpoints—under one URL.

• Multi‑tenancy. Each end‑user is isolated; builders configure integrations once and serve many users safely.

• Role separation baked in. End‑users simply grant consent the first time a new provider is needed—no Superface account is required.

For a hands‑on walkthrough, see the companion post Connect Claude to APIs with Superface.

Local-Only—For Now:

At Superface, we’re sticking with the local stdio transport for now—until key clients (Claude Desktop included) add support for the remote features introduced in MCP v2.

Where MCP Goes Next

MCP’s potential is clear, but the ecosystem must first embrace the v2 spec.

We’ll be watching as both the spec and its implementations mature; when these gaps finally close, MCP could well become the USB‑C port that connects AI agents to the entire tool landscape.

May 7, 2025 — Update

On May 1, 2025, Anthropic announced Claude Integrations—a new way to connect apps and tools to Claude Desktop and, more importantly, to Claude Web.

Claude now supports the SSE+HTTP transport protocol with OAuth-based authentication on the Max, Team, and Enterprise plans, with support coming soon to the Pro plan.