The Technical Limits of MCP: Missing Authentication, Tool Sprawl, and Stateful Connections

A security team went looking for the front door on thousands of MCP servers and kept finding it unlocked. When Astrix Security examined 5,205 MCP-server repositories on GitHub, only about 8.5% used OAuth; the majority relied on long-lived static secrets, and a slice required no credentials at all (Astrix Security). The reflexive reading is that developers are careless. The more interesting reading — the one that actually explains the pattern — is that the protocol told them this was fine.

A Protocol Built for a Trusted Room

The Model Context Protocol is a thin coordination layer, not a security framework. Its base is JSON-RPC 2.0 with stateful connections and capability negotiation, organized around three roles: a MCP Host (the application), an MCP Client inside it, and one or more MCP Server processes exposing tools. The architecture quietly assumes everything in this arrangement already belongs together — that the room is trusted before anyone walks in. Read the current ratified specification (2025-11-25) closely and the protocol guarantees almost nothing about security on its own.

What are the technical limitations of the Model Context Protocol?

The limits worth your attention are not bugs to be patched. They are consequences of three deliberate design choices, and each one trades safety or efficiency for simplicity.

First, authorization is specified as optional. The base protocol enforces no authentication; security is something you add, not something you get. Second, every tool a server exposes is described in natural language and injected into the model’s context on every turn, so capability scales linearly with cost. Third, the protocol is stateful — a session is a living connection, not a sequence of independent requests, which makes it awkward to scale and brittle when networks misbehave.

A common mental model says the opposite: “MCP added OAuth, so MCP servers are secure now.” That sentence conflates two different things. The specification gaining an authorization layer does not mean any given server uses it. The capability exists in the document. Adoption lives in the wild, and the wild looks very different.

When the Specification Says Authentication Is Optional

The cleanest way to understand the security situation is to read what the specification actually requires versus what it merely permits. The current revision describes a real authorization model: when a server chooses to authenticate, it acts as an OAuth 2.1 resource server, clients MUST implement PKCE with S256, and Resource Indicators (RFC 8707) bind a token to its intended audience (MCP Spec). That is a sound design. The catch is the word “when.”

Why do so many deployed MCP servers lack authentication and security?

Because the base protocol does not force the issue, and the most common transport actively discourages it. HTTP transports SHOULD conform to the authorization model; the local STDIO transport SHOULD NOT, because it is expected to pull credentials from the environment instead. Optional was the default, so most servers were built without it.

The field data makes the gap concrete. In Astrix Security’s survey of 5,205 GitHub repositories — roughly 19% of an estimated 20,000 — about 8.5% used OAuth, around 53% relied on long-lived static secrets like API keys or personal access tokens, and about 12% required no credentials at all; nearly 79% passed keys through plain environment variables (Astrix Security). One methodological caution matters here: that ~12% measures whether a server’s code declares credentials, not whether a running deployment is reachable without them. Separate scans of publicly exposed instances report higher no-auth rates, but they measure a different thing. Repository hygiene and deployment exposure are two distinct questions, and conflating them inflates the alarm.

The consequences are not theoretical. In a sample of popular implementations, the security firm Equixly found 43% vulnerable to command injection, 30% to server-side request forgery or unrestricted URL fetching, and 22% to path traversal or file leakage (Equixly). Treat those as percentages of a curated set of popular servers, not a census of the whole ecosystem — Equixly did not publish a total sample size. The pattern still holds: a protocol that treats authentication as opt-in produces a population where most participants opt out.

Not an oversight. A default.

Tool Sprawl and the Context Tax

The second limit is quieter because it never throws an error. It just makes the model slowly worse.

Every tool an MCP server exposes carries a name, a description, and a JSON schema. All of it is serialized into natural language and placed into the model’s context window so it knows what it can call. That description is not free — each tool costs roughly 200 to 500 tokens, and it is re-injected on every single turn of the conversation (The New Stack). Capability you never use is still capability you pay for, on every request, for the life of the session.

Think of it as carrying the entire instruction manual into every room rather than the one page you need. Connect a dozen servers, each exposing a dozen tools, and a meaningful fraction of the context window is gone before the user types a word. Some clients refuse to let this grow without bound: Cursor caps the total at 40 MCP tools, regardless of how many servers are installed (demiliani.com). That cap is not arbitrary; it is a forcing function against a real failure curve.

The cost is not only spatial. As the menu of available tools grows, the model assigns probability mass across more candidates, and tool selection degrades — more suboptimal choices, more calls to functions that do not exist or do not fit. The geometry is the same one that governs any classifier: accuracy falls as you add poorly separated classes. The mitigation follows directly from the mechanism — deactivate the tools a session does not need, so the model chooses from a short, relevant list rather than a sprawling one.

If the model picks the wrong tool more often as you add tools, the failure mode is usually not a crash. It is a confident, plausible call to the wrong function.

Stateful Connections in a Stateless World

The third limit collides with how modern infrastructure prefers to scale. MCP sessions are stateful: capability negotiation happens once at connection time, and state lives in the connection, not the request. That is elegant for a single local process and inconvenient the moment you put a load balancer in front of it.

The transport story shows the protocol adjusting to this tension. The original HTTP+SSE transport had no concept of a session, so a dropped connection meant lost state and a broken reconnect. It was deprecated in the 2025-03-26 revision and replaced by Streamable HTTP, which uses a single endpoint and an MCP-Session-Id header to carry session identity across requests — and, notably, can also run statelessly behind a load balancer when a deployment needs to scale horizontally (ChatForest). The protocol did not abandon statefulness; it made statelessness a supported option for remote operation.

A separate, louder debate concerns the local STDIO transport. Researchers have estimated that around 200,000 deployed servers are exposed to a command-injection class tied to how STDIO handles its environment (The Register). That figure is a researcher’s estimate, not an audited vulnerability count, and Anthropic has reportedly characterized the STDIO behavior as expected rather than flawed. It belongs in the column of contested design tradeoffs, not settled CVEs — but it is exactly the kind of tradeoff that follows from a protocol optimized for the trusted local room.

Security & compatibility notes:

• SSE transport deprecated: The HTTP+SSE transport was deprecated in the 2025-03-26 specification revision and replaced by Streamable HTTP. Guides that call SSE “the” remote transport are stale.
• STDIO exposure (contested): Researchers estimate ~200,000 deployed servers are exposed to a STDIO command-injection class (reported April 2026); Anthropic has reportedly called the behavior “expected.” Treat it as a design-tradeoff debate, not an audited CVE.
• Authorization is opt-in: The base protocol enforces no authentication. The emerging OAuth 2.1 layer is optional, and “MCP added auth” does not mean a given server is authenticated.

What These Limits Predict

The value of understanding a mechanism is that it lets you forecast behavior instead of being surprised by it. Each MCP limit comes with a prediction you can check against your own stack.

• If you expose an MCP server over HTTP without enabling the authorization layer, expect it to be reachable by anyone who can route to it — the protocol adds no barrier you did not build.
• If you connect many servers and notice the model calling wrong or nonexistent tools, the cause is usually the size of the tool menu, not a model regression.
• If your remote sessions break on network blips, suspect a transport that lost session state — and check whether you are still on the deprecated SSE path.

As of May 2026, the emerging OAuth 2.1 standard is still an IETF draft, not a finalized RFC, so even the recommended authorization path is a moving target. That is not a reason to skip it; it is a reason to treat your integration as something that will need revisiting when the draft settles.

Rule of thumb: Assume an MCP server is unauthenticated and over-provisioned until you have verified otherwise — the defaults point that way.

When it breaks: MCP’s failure mode is silent rather than loud. An unauthenticated server does not warn you, a bloated tool list degrades selection without an error, and a stateful session that scales poorly fails only under load — so the limits surface in production, not in the demo.

The Data Says

MCP’s three limits are not defects layered on top of a sound design; they are the design, optimized for a trusted local environment and then stretched into untrusted, distributed ones. Authentication is optional, capability costs context on every turn, and state lives in the connection. Treat the protocol as a thin, permissive coordination layer — secure it, prune it, and scale it yourself.