MCP Is Becoming the Context Plane for Coding Agents — Which Means It Is Also Becoming the Failure Plane

MCP is having the kind of moment every infrastructure layer eventually gets: it has become boring enough to be useful and popular enough to be dangerous. The Model Context Protocol started life as a cleaner way to connect AI assistants to tools and data. In practice, especially for coding agents, it is becoming something more consequential: the context plane.

That is the right ambition. A coding agent that cannot inspect the current repository, read live documentation, check CI, query Sentry, pull a SonarQube finding, or look up an internal policy is not really working in your environment. It is role-playing as an engineer from a pasted excerpt. The problem is that every context plane also becomes a failure plane. Once MCP servers sit between agents and the systems that matter, teams inherit a familiar set of production problems: permission boundaries, observability, token budgets, registries, rollback, and audit trails. We have seen this movie before. It usually starts with “developer productivity” and ends with an access-control matrix nobody owns.

InfoWorld’s May 25 piece captures the useful version of the trend. Zuplo’s early-2026 State of MCP report found that 63% of MCP users adopt MCP servers to access data sources such as documentation or knowledge bases. That is the signal. MCP adoption is not only about letting an agent click buttons. It is being pulled by retrieval: giving the model current, scoped, structured context instead of dumping an oversized prompt into the window and hoping the right facts survive attention.

The connector is becoming the control surface

The examples are already concrete. Context7 gives agents up-to-date documentation. Filesystem servers expose local directories. Sentry servers surface production issues and errors. SonarQube servers expose security findings. Multiplayer can provide user-session data. GitHub’s MCP server gives repository search and direct file access. Each of those sounds harmless in a demo. In a real organization, each one is a permission decision with a token bill attached.

That is why the quotes in InfoWorld land. Pendo CEO Todd Olson frames MCP as a way for an agent to determine what context it needs and fetch it in real time. Sonar’s Edgar Kussberg compares it to how engineers actually work: they move across repositories, dashboards, CI systems, documentation, and security reports rather than answering from memory. WaveMaker’s Venugopal Jidigam argues that MCP replaces large prompt dumps with scoped context assembled at runtime. All true. Also incomplete unless the runtime has guardrails.

The engineering win is obvious. Prompt stuffing is a bad architecture disguised as convenience. It burns tokens, hides stale assumptions, and gives the model a haystack when it needs a file, a failing log, or a schema. MCP offers a standard place to put retrieval and tool access, which means teams can stop rebuilding one-off connectors for every agent. In fast-moving codebases, that freshness can matter more than model choice. A weaker model with the exact failing CI log may beat a stronger model hallucinating around yesterday’s README.

But standardizing retrieval does not automatically make retrieval safe. It standardizes the place where safety has to live.

Token bloat is the friendly warning sign

The first failure mode most teams will notice is not a breach. It is cost and latency. The New Stack has already covered MCP token bloat, and InfoWorld points to the same concern: ballooning portfolios of servers can substantially increase LLM inputs. Tool descriptions, schemas, discovery metadata, irrelevant context, and duplicated capabilities can eat the window before the agent does any useful work.

That sounds like an optimization issue, but it is really an architecture issue. If a developer installs 25 MCP servers locally, each advertising a catalog of overlapping tools, the model now has to reason through a noisy menu before touching the task. This is how “more context” turns into worse behavior. Context engineering is not context hoarding. It is deciding what information is reachable, when it is fetched, in what shape, and under which budget.

Bloomberry’s analysis of 1,400 MCP servers found a 232% increase over six months, from August 2025 to February 2026, with read operations outpacing writes by roughly 2:1. That ratio is healthy: MCP is still mostly acting as context plumbing before it becomes action plumbing. It also means the governance conversation should happen now, while most deployments are still read-heavy. Once write tools become common — file edits, ticket updates, deployments, database mutations — the cost of sloppy server sprawl goes up sharply.

Read-only does not mean risk-free

The tempting mistake is to treat read-only MCP servers as safe by default. They are safer than write-capable tools, but not safe. A repository server can expose proprietary code. A Sentry server can expose customer identifiers and stack traces. A SonarQube server can reveal vulnerability details. A user-session tool can carry sensitive behavior into a prompt. If the agent then summarizes that context into another agent, stores it in memory, or sends it to an external model, the system has moved data across boundaries even though no single tool call looked dramatic.

This is where MCP overlaps with the larger agent-security checklist. Teams need identity-aware access checks, not just API keys shared by a bot account. The agent should not be able to retrieve data the supervising human could not access. Tool calls should be logged with enough detail to answer what category of data was retrieved and why. Registries should define approved servers, owners, scopes, and emergency disable paths. If a server starts leaking cost, producing irrelevant context, or broadening access, the rollback mechanism should not be “tell everyone to uninstall it.”

The official MCP authorization guidance has improved, and that matters. Consent and authorization are now first-class protocol concerns rather than afterthoughts. But protocols do not enforce your org chart. Implementation does. A neatly documented OAuth flow still fails if every agent shares an overpowered service account or if tool outputs are shoved into traces without redaction.

For practitioners, the right adoption path is boring and effective. Start with a small registry of approved MCP servers. Separate read tools from write tools. Prefer scoped responses over entire files or giant docs. Measure token overhead per server and per tool definition. Add budgets: max context size, max tool calls, max depth, max cost per run. Require auth passthrough where possible. Log retrieval at the run level so an incident reviewer can reconstruct which context shaped the answer. And keep the humble option open: if a direct API, CLI, or static integration is simpler and safer than MCP, use it. Standards are useful. They are not trophies.

The bigger evaluation lesson is that coding-agent quality is no longer just model quality. Two agents backed by the same model will behave differently if one can retrieve current repo state, production errors, architectural docs, and security findings while the other survives on pasted snippets. Retrieval quality is runtime quality. Bad retrieval makes agents slower, more expensive, and more confidently wrong.

MCP is becoming the context plane for coding agents because the need is real. Engineers do not work from memory; agents should not either. But context is access, access is risk, and risk needs owners. The teams that win with MCP will not be the ones with the largest server zoo. They will be the ones that treat context like production infrastructure: scoped, observable, budgeted, reversible, and boring enough to trust.

Sources: InfoWorld, Zuplo State of MCP, Bloomberry MCP server analysis, The New Stack, Model Context Protocol authorization docs, GitHub MCP server