MCP Architecture: What Most Teams Get Wrong

MCP Is Not a Feature. It Is Infrastructure.

The Model Context Protocol has crossed 97 million monthly SDK downloads. That number means it has escaped the early-adopter phase and entered the phase where bad architectural decisions compound at scale. If you are still treating MCP as a convenience layer for connecting your LLM to a database, you are misreading what it actually is.

MCP runs a client-server architecture over JSON-RPC 2.0. The three-layer model, host, client, server, is not abstract. The host is your LLM application. The client lives inside it and manages connections. The server exposes the actual capabilities. Three core primitives flow through this stack: tools (executable functions), resources (data the model can read), and prompts (templated interaction patterns). Get this wrong and you do not just have a broken integration. You have a broken trust boundary.

Stdio Is Holding Your Architecture Hostage

Transport matters too, and most teams are still using stdio because it was easier to set up in 2024. Streamable HTTP is the production path now. It replaced the legacy SSE protocol for remote communication, and if you are deploying anything that needs horizontal scaling or lives outside a single process, you should have migrated already.

The Three Primitives Are Not Interchangeable

Tools get the most attention because they are the most legible: call this function, get a result. But resources and prompts carry equal architectural weight. A resource is a live data surface your model can pull from without requiring a tool call. A prompt is a pre-negotiated interaction contract between the server and the host. Teams that collapse everything into tools end up with bloated tool registries that confuse the planner and degrade routing accuracy. Separate the primitives. Use them for what they were designed for.

The Security Surface Nobody Is Talking About Loudly Enough

MCP's integration model is powerful precisely because it is open. That openness is also the attack surface. A misconfigured MCP server does not just leak data. It hands a capable model a set of executable tools with no validation layer in between.

One mitigation path in circulation uses MCPClient as a Python library wrapping the query interface, combined with a Flask endpoint to enforce validation at the boundary. The claim from this approach is a 90% reduction in security risk and throughput up to 1000 queries per second. These numbers lack methodology. Faster than what baseline? Measured under which query distribution? What constitutes a "security risk" in their metric? Treat these figures as directionally interesting, not as benchmarks you can cite in a design review.

Prompt Injection Turns Your Tools Against You

What is not in dispute: the threat model is real. Prompt injection through tool descriptions is a known vector. If your MCP server exposes a tool with a description field an attacker can influence, that description can instruct the model to misuse adjacent tools. The fix is validation at ingress, not trust in the model's judgment. Models are not security boundaries.

Chaining Tools Creates Compounding Exposure

MCP tool chaining is where the real capability lives and where the risk compounds. A workflow that searches GitHub, reads code, analyzes patterns, and opens issues is four sequential tool calls. Each call is a trust decision. If one step in that chain accepts unvalidated input from a prior step, you have a pipeline where a single poisoned upstream result can propagate through every downstream action.

NeuroLink claims to unify over 13 major AI providers through a single connection layer for workflows like this. The architecture is plausible. The validation of that claim is absent. What matters architecturally is the pattern: multi-provider chaining raises the question of which entity owns the trust boundary at each hop. If the answer is "the model decides," your security model is not a model.

Two Agent Types, One Conflation, Predictable Failures

The industry has a terminology problem that is causing real production failures. Persistent Context Agents and Stateless Decision Functions are architecturally distinct. Running them under the same evaluation framework produces metrics that mean nothing.

Persistent Context Agents, think Claude Code or Cursor, accumulate context across interactions. Their value is proportional to what they remember. You evaluate them on coherence over time, context fidelity, and how well they handle conflicting information across a long session. Stateless Decision Functions, think content moderation classifiers or loan underwriting models, receive structured input, produce one output, and retain nothing. You evaluate them on accuracy at volume, latency distribution, and error rate under load.

One SDK Definition Is Failing Both Systems

OpenAI's Agents SDK defines agents as "systems that independently accomplish tasks on behalf of users." That definition covers both types. The SDK does not distinguish between them. The result is that teams building stateless decision functions get pulled toward memory architectures they do not need, and teams building persistent agents underinvest in context management because the tooling does not force the issue.

If your evaluation strategy does not know which type of agent it is evaluating, your metrics are measuring the wrong thing, and you will not find out until production.

Continual Learning Lives at Three Layers

LangChain's framing of continual learning as a three-layer problem is the most useful mental model in this space right now. Model layer updates change weights. Harness layer updates change how the agent interacts with its environment. Context layer updates change the available data and task scope.

The practical implication: most teams that think they need to fine-tune actually need a harness or context layer update. Harness optimization, improving the decision-making loop structure, can reduce latency measurably without touching the model. Context expansion, growing the knowledge surface available at inference time, handles domain drift without retraining. Fine-tuning is expensive and slow. Exhaust the other two layers first.

LangChain's Numbers Are Unverified, Direction Is Sound

The 30% latency reduction and 25% knowledge graph expansion cited for these layers come from LangChain's own reporting. No independent validation. The direction is sound. The numbers are unverified.

What the Taxonomy Arguments Are Actually About

The classical Russell-Norvig taxonomy and the modern LLM-era taxonomy are not competing. The classical taxonomy explains the architectural logic. The modern taxonomy describes what is running in production. You need both because architectural logic tells you why a system fails, and the production taxonomy tells you which failure mode to look for first.

A reactive agent in the classical sense does not plan. A GPT-era tool-use agent may look like it plans but is actually doing next-token prediction over a reasoning trace. Understanding that distinction changes how you debug. When your agent gets stuck in a loop, the question is not "why is it not planning better." The question is "what in the context window is making the next-token prediction converge on the wrong action."

Market Growth Breeds Dangerous Complexity Fast

The AI agents market is projected to reach $52.62 billion by 2030, growing at 46.3% CAGR. That number is an invitation for bad tooling, overcomplicated architectures, and practitioners who learned the vocabulary without learning the plumbing. The teams that will ship reliable systems are the ones who can read the classical taxonomy and the modern one simultaneously, and know which lens applies to the failure in front of them.

Sources: Medium: AI Agents (April 6, 2026), Dev.to: LLM tag (April 6, 2026), Medium: Agentic AI (April 6, 2026), DEV.to (April 6, 2026), LangChain Blog (April 5, 2026)