What Is an MCP Server

An MCP server is a standardized way for an AI application to reach outside its own walls, tools, files, databases, other services, without a custom-built connector for every single one. Anthropic's November 2024 announcement described AI systems as "trapped behind information silos and legacy systems" where "every new data source requires its own custom implementation. MCP's answer is to turn that N×M matrix into N+M: a client implements the protocol once, a server implements it once, and from then on any compliant client can talk to any compliant server without additional glue code.

Descope's guide on the protocol frames MCP as a layer built on top of function calling that standardizes it rather than discarding it, so developers aren't learning a new mental model from scratch. Building a server once lets every MCP-capable client pick it up without further work on either side. That's the structural promise the rest of this piece unpacks: not a clever trick for one vendor's assistant, but a shared contract that removes the repeated cost of connecting AI systems to the world outside them.

How MCP is governed today

Anthropic open-sourced MCP on November 25, 2024, and the protocol has since moved well past being an Anthropic project. By December 2025, Anthropic had donated MCP to the Agentic AI Foundation, housed under the Linux Foundation and co-founded by Anthropic, Block, and OpenAI, putting MCP under vendor-neutral governance. Descope's guide notes that Google, Microsoft, AWS, Cloudflare, and Bloomberg also backed the Agentic AI Foundation, which puts MCP about as close as the industry currently has to a shared standard for connecting AI systems to external data and tools.

That governance shift matters for anyone deciding whether to build on MCP. The adoption pattern outside the standards body backs this up: MCP clients now ship inside Claude Code, Cursor, and OpenAI Codex, which are exactly the tools where people building AI agents spend their working hours. Open governance plus daily use in the tools builders already have open is what makes the rest of this piece worth taking seriously as infrastructure guidance.

The four-part architecture: host, client, server, and JSON-RPC transport

MCP defines three roles that talk to each other over JSON-RPC 2.0, and getting clear on which role does what is the first real step toward using the protocol correctly. The server is the program doing the actual work, running either as a local subprocess over stdio or as a remote HTTP service, and it doesn't need to know or care which host happens to be on the other end of the connection.

That image clarifies what MCP is not doing: it is not replacing the REST API, database, or filesystem sitting underneath a server, it's wrapping it. The MCP layer supplies the schema an agent can read and handles the back-and-forth of a session, while the actual work, the HTTP call, the SQL query, the file read, still happens exactly as it did before MCP showed up. For a team that already has a working REST API, that means adopting MCP isn't a rewrite of the backend. It means adding a protocol-compliant wrapper around what already exists, one that any agent can discover at runtime instead of needing custom code written against it in advance.

That last point, runtime discovery, is the real architectural departure from a plain REST integration. One might ask what that buys a team in practice: the same piece of agent code can point at a completely different MCP server and still route correctly, because the server carries its own capability description with it at runtime instead of depending on the client to already know what it can do.

The three server primitives: tools, resources, and prompts

An MCP server exposes capability through three primitives, and they differ less in what they carry than in who gets to decide when they're used, a distinction that shapes how an agent built on top of them actually behaves. Most of what happens in production MCP deployments runs through tools, simply because tools are the thing an agent actually calls.

Resources work differently: they're application-controlled rather than model-controlled, covering files, database records, or API payloads, each one addressed by a URI. Developers Digest offers a compact way to keep the three straight: tools function as the model's hands, resources as its eyes, and prompts as its phrasebook. Anyone designing a server can use that split directly: if the model should decide to act, build a tool; if a human or the host decides what gets shown, build a resource; if what's needed is a reusable instruction template, build a prompt.

How the 2026-07-28 spec change affects servers

The biggest architectural change to MCP since it launched arrived with the 2026-07-28 specification, and it changes a basic assumption anyone who learned the protocol during 2025 is likely still carrying around: sessions are gone. Every request under the new spec is self-contained, and the protocol's core is now stateless rather than tracking a persistent session between a client and a server. Servers now have to implement a server/discover call, through which they advertise which protocol versions, capabilities, and identity they support, while clients are free to call it but aren't required to.

Where a server previously held a session open and pushed requests back to the client when it needed more information, that pattern is gone too. When a server needs additional input, a pattern called elicitation, it now returns an InputRequiredResult with a resultType of "input_required" and an inputRequests field, and the client responds by retrying the original request with the answers filled into inputResponses. That multi-round-trip exchange is what now stands in place of the older server-initiated request.

The payoff for production systems is concrete: a stateless core means a server can scale horizontally across ordinary HTTP load balancers, something the old stateful model actively worked against. List results such as tools/list now come back with a ttlMs and a cacheScope, and servers are expected to return tools in a consistent, deterministic order, letting a client cache a tool list across turns.

Transports: stdio for local servers, Streamable HTTP for remote ones

MCP runs over two transports, and which one a given server uses comes down to where that server actually lives, not a matter of taste. Streamable HTTP is the transport for servers running remotely, reached over HTTP. As of the 2026-07-28 spec, that HTTP transport runs statelessly too, replacing the older HTTP+SSE pattern that depended on a maintained session between calls. Developers Digest points out that anyone working through a tutorial based on the older stateful transport pattern is really looking at the same underlying mechanics, just described against an earlier, now-superseded version of the transport.

Dropping sessions at the protocol level doesn't mean an application built on MCP has to behave statelessly too. Responsibility for storing and managing that state moves to the application layer, backed by whatever a team already uses for that job, Redis, Postgres, S3. That's a cleaner split of responsibilities than the old design offered: the protocol handles discovery and invocation, and durability lives in infrastructure built for durability.

Security risks in MCP's design

MCP's usefulness and its risk come from the same source: giving a model the power to call tools and act on external systems opens an attack surface that security researchers and the NSA have both flagged directly. The Cloud Security Alliance, citing an original disclosure by OX Security, reported a systemic flaw in the MCP STDIO transport in which OS commands get executed without sanitization or validation, opening the door to remote code execution on any host running a vulnerable implementation. That's not the only gap: the protocol specification itself offers no built-in defense against tool poisoning, rug pull attacks, or cross-server tool shadowing, leaving those risks to whoever implements and deploys a given server. A scan found publicly accessible MCP server instances answering unauthenticated requests, a direct outcome of running servers without any isolation around them.

The risk profile has grown alongside the ecosystem itself. Empirical analysis of MCP tools found that the share classified as "action" tools, meaning tools that directly modify something in the outside world rather than just reading from it, rose from well under a third of all tools to nearly two-thirds between November 2024 and February 2026. Every one of those invocations is a potential trust boundary crossing, and because MCP interactions compose across servers, a single compromised server can cascade through an entire multi-agent workflow. That's a structural property of how MCP chains tool calls, not a hypothetical edge case someone dreamed up to sound cautious. The NSA's guidance reflects that structural read of the risk: it recommends treating any tool execution triggered through MCP as potentially high-risk, and using sandbox technologies, AppContainers on Windows, or seccomp, AppArmor, or SELinux on Linux, to isolate each tool's execution context from everything around it.

MCP servers must run in isolated execution environments, not on the host OS

The consensus among people actually running MCP servers in production, backed directly by the NSA's own guidance, comes down to one rule: an MCP server does not run directly on the host operating system, full stop. It runs inside an isolated execution environment built for that purpose. The reasoning follows straight from what MCP is built to do: it gives servers the ability to execute real actions, and a server that isn't sandboxed, while processing tool calls that may originate from untrusted input or from the model's own generated text, has a direct line to whatever the underlying system can do. That's not a misconfiguration waiting to happen in rare cases: it's a property of the design itself.

Docker containers and microVMs such as Firecracker are the isolation layers practitioners generally reach for when running MCP servers, and the NSA's own guidance specifically names seccomp, AppArmor, and SELinux as appropriate mechanisms for isolating a tool's execution context on Linux systems. For a team building agents that call out to MCP tools, deciding where and how those tools actually run deserves the same weight as the design of the agent's own logic. The execution environment for MCP tool calls has to be built for that job specifically, fast to spin up, isolated from the start, and capable of holding state across calls that may run far longer than a typical web request.

Practical server design: scope and splitting

Designing a good MCP server means choosing a coherent, bounded set of tools, not exposing every single operation the underlying system happens to support. Production deployments point toward a workable rule of thumb: a single server should expose somewhere between 3 and 10 tools. Smaller, clearly bounded servers with well-written tool descriptions tend to produce more reliable choices from the model.

Those descriptions carry real weight in practice, since the model relies on them to judge when a tool applies. Descope's guide treats this as one of MCP's core design principles: a server controls what the model is permitted to do, and that scoping keeps an agent operating inside defined boundaries. That scoping compounds in multi-agent setups too, since a tool that looks low-risk by itself can become considerably riskier once it's one link in a chain spanning several servers.

The choice between a local stdio server and a remote Streamable HTTP one should follow from the deployment context rather than whichever transport a developer happened to learn first. Local stdio servers fit development work, IDE integrations, and workflows built around a single user. Remote HTTP servers are the right call for multi-tenant production systems, for anything that needs to scale horizontally, and for any server meant to be shared across more than one client at once.

How MCP fits with other integration patterns

MCP doesn't replace REST APIs, SDKs, or agent-to-agent protocols, it sits alongside them, and knowing which tool fits which situation is what keeps a system from being over-engineered. The dividing line against REST comes down to whether the logic calling an endpoint is fixed in advance or decided at runtime. An agent fielding employee questions and deciding on its own whether to check the HRIS, the payroll system, or the applicant tracking system is a different case entirely, and that's where MCP actually earns its place.

Against an SDK, the comparison runs similarly. Against agent-to-agent protocols, MCP isn't competing at all. Descope's guide notes MCP complements the Agent2Agent protocol rather than overlapping with it: MCP governs how an agent reaches tools and data, while A2A governs how agents talk to each other, two separate layers of a system built from several cooperating agents.

The practical test for whether a given situation calls for MCP comes down to one question: is the agent itself choosing which capability to invoke, or has a developer already made that choice at design time? If the developer is making the call, a direct REST integration or an SDK is simpler to build and easier to scale. If the agent is making that call on its own, at the moment it's running, MCP is the right abstraction, because it puts the description of what's available on the server where the agent can read it, rather than locking that choice into the client ahead of time.