Before MCP, connecting an LLM to external tools meant writing a one-off integration for every combination of model provider and service — a Slack integration for GPT-4, a different one for Claude, a third for Gemini. Anthropic introduced the Model Context Protocol in November 2024 to solve exactly that N×M integration problem with a single standard. It has since become the de facto protocol for connecting AI to the real world, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams — the Python and TypeScript SDKs alone see roughly 97 million monthly downloads (SitePoint).
In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, making it a vendor-neutral, community-governed standard rather than an Anthropic-controlled one (SitePoint) — a meaningful move for adoption, since competitors were understandably wary of building on a rival's proprietary protocol.
Architecture: host, client, server
MCP follows a client-server architecture with three distinct roles (MCP docs):
- Host — the AI-facing application the user interacts with, such as Claude Desktop or an IDE like Cursor. The host manages connections to one or more MCP servers and mediates between the user, the model, and available tools.
- Client — the connector inside the host that maintains a 1:1 connection to a given server.
- Server — exposes tools, resources (data), and prompts to the client over a defined transport.
┌─────────────┐ ┌────────┐ ┌─────────────┐
│ Host (IDE, │──────│ Client │──────│ MCP Server │
│ Claude,etc)│ │ │ │ (tools/data) │
└─────────────┘ └────────┘ └─────────────┘
Transport mechanisms
Two transport modes cover the practical deployment spectrum:
- Stdio transport — standard input/output streams for direct process communication between local processes on the same machine, giving optimal performance with no network overhead. Good fit for local tools (filesystem access, local databases).
- Streamable HTTP transport — HTTP POST for client-to-server messages with optional Server-Sent Events for streaming, enabling remote server communication and standard HTTP authentication (bearer tokens, API keys, custom headers) (SitePoint).
What changed in the 2026-07-28 specification
The most recent major spec revision brought MCP closer to how the rest of the web operates: a stateless protocol core, multi round-trip requests, header-based routing, cacheable list results, authorization hardening, and a formal extensions framework (MCP Blog). The framing from the MCP team itself is direct — this update is "a major step toward making agent infrastructure work like the rest of the web: stateless, cacheable, routable, and globally scalable" (MCP Blog).
Practically, statelessness matters for anyone running MCP servers at scale: a stateless core means you can load-balance across server instances without sticky sessions, which was a real operational headache in earlier spec versions.
MCP vs. plain function calling
MCP is not a replacement for function calling — it's a standardized transport and discovery layer built on top of the same underlying mechanism. Where raw function calling requires you to hand-write and hard-code a tool catalog per integration, MCP servers advertise their tools, resources, and prompts dynamically, so any MCP-compatible host can discover and use them without custom integration code. The tradeoff is a larger attack surface, covered below.
The security picture is worse than most teams assume
This is the part of MCP adoption that gets underweighted in the rush to add "an MCP server" to a product. Across 2,614 tested MCP implementations, 43% were vulnerable to command injection and 82% use file operations prone to path traversal (Practical DevSecOps). More strikingly, 24-25% of MCP servers have no authentication at all (Practical DevSecOps), and 50% of MCP builders cite security and access control as their top challenge (Practical DevSecOps).
| Risk | Prevalence | Impact |
|---|---|---|
| No authentication | 24-25% of servers | Anyone who can reach the server can invoke tools |
| Command injection | 43% of tested servers | Arbitrary command execution via tool arguments |
| Path traversal-prone file ops | 82% of servers | Unauthorized file read/write outside intended scope |
| Tool poisoning via hidden instructions | Structural risk | Model follows attacker instructions embedded in tool metadata |
Tool poisoning and hidden prompt injection
The most MCP-specific attack vector is tool poisoning: tool descriptions visible to the AI model but not displayed in the user interface can carry hidden adversarial instructions, which establishes prompt injection as a structural risk baked into MCP's design, not just an implementation bug (Practical DevSecOps). A malicious or compromised MCP server can describe a tool in a way that looks benign to the user but instructs the model to exfiltrate data or take unintended action — and because the model reads the full tool description as context, it has no inherent way to distinguish "legitimate tool documentation" from "instructions injected by an attacker."
Warning
Related research demonstrates that even the function-calling mechanism underlying MCP tool invocation can itself be manipulated by adversarial input to alter which tool gets invoked or with what arguments — meaning prompt injection resistance has to be designed at the model and orchestration layer, not assumed away by the protocol (arXiv).
Practical mitigations
- Authenticate every server connection. Given a quarter of servers ship with no auth at all, explicit bearer token or API key auth should be a non-negotiable deployment checklist item, not an assumed default.
- Scope tool permissions narrowly. A filesystem MCP server should be scoped to a specific directory, not the whole filesystem; a database server should use a read-only credential unless writes are explicitly required.
- Audit tool descriptions from third-party servers before connecting them, specifically looking for instructions embedded in metadata that wouldn't be visible in a typical UI review.
- Validate and sandbox file operations given the high rate (82%) of path-traversal-prone implementations — don't trust that an MCP server you didn't write validates paths correctly.
Actionable takeaway
MCP has genuinely solved the integration fragmentation problem it set out to solve, and the 2026-07-28 spec update makes it a more serious piece of scalable infrastructure than its 2024 origins suggested. But the security data is unambiguous: a meaningful share of MCP servers in the wild today have no authentication and are vulnerable to command injection or path traversal. If you're deploying or connecting to MCP servers in production, budget real security review time — narrow permission scoping, mandatory authentication, and tool-description auditing — before treating "it's MCP-compatible" as equivalent to "it's safe to connect."
Sources: SitePoint: MCP Complete 2026 Guide, MCP Blog: The 2026-07-28 Specification, MCP Docs: Architecture Overview, Practical DevSecOps: MCP Security Vulnerabilities, Practical DevSecOps: MCP Security Statistics 2026, arXiv: MCP Threat Modeling and Tool Poisoning
Get new posts as they publish
No spam — just the next post, straight to your inbox.