What Is an MCP Server? A 2026 Technical Guide

If you've spent any time in AI engineering channels lately, you've watched MCP go from a niche Anthropic proposal to something OpenAI, Microsoft, Google, and the Linux Foundation all signed onto in about 13 months. The acronym is everywhere. The clear explanations are not.

This guide skips the marketing definitions. You'll get a plain-English answer to what MCP is, how the host/client/server model actually works, what the four primitives do, and when MCP is the right call versus function calling or RAG. We'll also cover what the NSA's May 2026 advisory means if you're not a federal agency, and how to vet a server before you install it.

What MCP is, in one paragraph (and the USB-C analogy that finally makes it click)

Picture this: you want Claude Sonnet 4.6 to read a Postgres database, post a Slack message, and update a Linear ticket. Before MCP, that meant three custom integrations against three separate APIs, each with its own auth flow, schema quirks, and maintenance tax. With MCP? One protocol. Three off-the-shelf servers you plug in.

Model Context Protocol (MCP) is an open standard that lets any AI assistant talk to any external data source, tool, or service through one shared protocol. Think USB-C for AI. One port, many devices. Your laptop doesn't need a custom cable for every monitor, drive, or dock. Your LLM shouldn't need a custom integration for every tool.

The N×M problem MCP solves

Without a shared protocol, connecting N tools to M AI clients means building N times M bespoke integrations. With MCP, the math collapses to N + M. Each tool ships one server. Each client speaks one protocol. The combinatorial nightmare goes away.

Origin: Anthropic, November 2024

Anthropic introduced MCP in November 2024, with engineers David Soria Parra and Justin Spahr-Summers leading the design (per the Anthropic announcement). By December 2025, MCP was donated to the Linux Foundation's newly formed Agentic AI Foundation, co-founded with OpenAI and Block. That handoff matters. It signals MCP isn't a single-vendor play, and the spec now evolves through neutral governance instead of one lab's roadmap.

How MCP actually works: hosts, clients, servers, and JSON-RPC

MCP has three roles. The host is the app the user opens (Claude Desktop, Cursor, your in-house agent UI). The client is the protocol component inside that host, one per connected server. The server is a separate process exposing tools, resources, prompts, and sampling to whichever client connects. One host can spin up many clients, each talking to its own server.

Every message is JSON-RPC 2.0. Requests, responses, notifications. That's it. If you've wired up a language server before, the shape will feel familiar.

Transports: stdio, Streamable HTTP, and the late-2025 SSE deprecation

In practice you pick between two. stdio runs the server as a child process and pipes JSON-RPC over stdin/stdout. Zero network setup. It's what desktop hosts use by default. Streamable HTTP is the modern remote transport: a single HTTP endpoint that upgrades to a stream when the server needs to push. It replaced the older HTTP+SSE transport, which was deprecated in the 2025-03-26 spec revision and shouldn't be used for anything new.

One more thing if you're scaling: the 2026-07-28 release candidate makes the core protocol stateless, dropping the initialize handshake and the Mcp-Session-Id header. That removes a real headache for anyone running MCP servers behind a load balancer.

Quick verdict: stdio for local dev, Streamable HTTP for remote production, plain SSE for nothing new.

The four MCP primitives: Tools, Resources, Prompts, and Sampling

MCP defines four primitives. The cleanest mental model: four control planes, sorted by who decides when each one fires.

Tools (model-controlled)

The model picks these. Tools are schema-defined functions with typed inputs and outputs, like track_order(order_id) or a GitHub server's create_issue(repo, title, body). The LLM reads the schema, decides the tool fits the request, and proposes a call. The host should then ask the user to approve execution. Tools are the loudest primitive, and the one server authors lean on too hard.

Resources (application-controlled)

The host application decides. Resources are read-only data exposed via URI, say db://orders/schema or file://repo/README.md. They're passive context, not invocations. Think attachments the client pulls in to ground a conversation. This is the most underused primitive in the wild, which is a shame, since it's often the safer way to give a model context without handing over write access.

Prompts (user-controlled)

The user triggers these. Prompts are reusable instruction templates that show up as slash-commands or menu items in hosts like Claude Desktop. A "weekly sales report" prompt that fills in the date range and target channel is a typical shape.

Sampling (server-initiated, now deprecated)

Sampling let a server ask the client's LLM for a completion mid-task, handy for things like a data-pipeline server summarizing a detected anomaly. The 2026-07-28 spec deprecated it. New servers should call an LLM provider API directly instead of routing back through the client.

MCP vs function calling vs OpenAPI vs RAG vs LangChain tools (the comparison nobody writes)

Every AI integration approach answers a different question. Here's how MCP stacks up against the alternatives you're probably already using.

The comparison table

Which one belongs in your stack

Probably several. MCP is the only cross-vendor protocol on the list, but it doesn't replace the others. Function calling is still how the model picks what to invoke. MCP standardizes what's on the menu. RAG handles retrieval-heavy reads. OpenAPI keeps powering the services underneath. Reach for MCP when the same integration needs to work in Claude Desktop today and a custom agent next quarter, without rewriting the glue twice.

The MCP ecosystem in 2026: who adopted it and what you can plug in

MCP went from single-vendor proposal to multi-host standard in about 13 months. Anthropic launched it in November 2024. OpenAI signed on in March 2025 (Sam Altman announced it on X). Microsoft wired MCP into Azure and shipped a Playwright server the same year. Google DeepMind followed. By December 2025, the spec was donated to the Linux Foundation's Agentic AI Foundation.

Hosts that speak MCP

On the model side: Claude Opus 4.7, Sonnet 4.6, and Haiku 4.5; ChatGPT on GPT-5 and GPT-5.5 (MCP Apps support landed September 2025); Gemini 3.1 Pro via DeepMind. On the tooling side: Cursor, VS Code, Zed, Replit, Sourcegraph, and Windsurf. If your stack touches any of these, you can plug in a server today.

Reference servers worth knowing

The launch shipped servers for Google Drive, Slack, GitHub, Git, Postgres, Puppeteer, Filesystem, Fetch, and Memory. Read those first before writing your own. For governed enterprise rollouts, Databricks Agent Bricks ties MCP servers into Unity Catalog so permissions follow the data.

SDKs and the discovery surface

Official SDKs exist for TypeScript, Python, C#, Java, Go, Kotlin, and PHP. The TypeScript SDK is the busiest, north of 12,000 GitHub stars. For discovery, you have the official MCP Registry and the community directory mcp.so, which lists 21,833+ submitted servers as of 2026. That number is also your supply-chain problem. More on that next.

Security: what the NSA's May 2026 advisory actually says (in plain English)

On May 20, 2026, the NSA's Artificial Intelligence Security Center published a 17-page Cybersecurity Information Sheet (U/OO/6030316-26, PP-26-1834, Version 1.0) on MCP risk. The headline point is sharper than most coverage made it sound: MCP inverts the usual client-server pattern. Servers query data and execute actions on the client's behalf, which opens attack paths existing playbooks don't cover.

The five risks the NSA names

1. Prompt injection through tool descriptions. The text your agent reads to decide which tool to call is itself untrusted input.
2. Tool poisoning. A malicious server impersonates a trusted one and answers in its place.
3. Arbitrary code execution, mapped to CWE-77, CWE-78, CWE-94, and CWE-95. CVE-2025-49596 in MCP Inspector is the canonical example, patched in v0.14.1.
4. Unverified task propagation across chained servers, where one server's output becomes another's instruction.
5. Lookalike tool attacks, where a registry entry mimics a popular server's name.

What you should actually do about it

The NSA recommends filtering outbound proxies or enterprise DLP between agents and external MCP endpoints, sandboxing servers, enforcing message integrity checks, filtering outputs, and running regular local MCP scans. The shorter version: don't install servers from unvetted directories in any environment that touches production data. Assume every server can read everything your agent can read. Architecturally, it can.

How to evaluate an MCP server before you install it

The mcp.so directory listed 21,833+ community-submitted servers as of mid-2026. The NSA's May 2026 advisory (U/OO/6030316-26) flagged exactly this risk: the npm-era "curl pipe bash" install habit is creeping into AI tooling, where one rogue server can read your filesystem, exfiltrate tokens, or chain into other agents. Vet every server before you wire it to a host.

The 8-point vetting checklist

1. Publisher identity. A real org or maintainer, not a throwaway GitHub handle.
2. Open source and reviewed. Public repo, recent commits, answered issues.
3. Scopes requested. OAuth grants, filesystem paths, outbound network. Least privilege or walk away.
4. Isolation model. In-process with your host, or sandboxed in a container or subprocess?
5. Third-party endpoints. Does it phone home to a server you don't control? Log the destinations.
6. Registry status. Listed on the official MCP Registry, or only on an unverified directory?
7. Version pinning. Pin to an audited commit or release. No floating latest.
8. Manifest declared. Ships an MCPB bundle with manifest.json declaring tools, resources, and scopes up front.

One tool worth installing: MCP Inspector

MCP Inspector is the official debugger from the MCP team, roughly 10,000 GitHub stars. It runs the client UI on port 6274 and the proxy on 6277. Point it at a server and watch every JSON-RPC message before any production traffic hits it. Pair it with MCPB bundles (a ZIP plus manifest.json, analogous to .vsix for VS Code or .crx for Chrome) and you can audit declared capabilities before unpacking, not after.

Should you use MCP, function calling, or RAG? A decision flow

Three questions settle this. Skip the architecture debates.

The decision tree

First: does the agent need to do something, or just answer? If it's pure Q&A over documents, RAG is enough. Embed, retrieve, generate, done. Second: if the agent does take action, will the same integration get reused across more than one host (Claude Desktop, Cursor, your internal agent, a teammate's setup)? If no, native function calling has fewer moving parts. If yes, MCP earns its keep.

Now layer two more axes. Data freshness: a static handbook that updates monthly is RAG territory. A Jira board changing every minute needs MCP or function calling. Ownership: if you're the only one maintaining the glue code, function calling stays simple. If a vendor or community ships and patches the server, MCP wins on leverage.

Three honest scenarios

1. Internal knowledge base for 50 employees. RAG over your wiki, plus one or two function calls for "create ticket" and "page on-call." No protocol needed.
2. Coding agent in Cursor touching GitHub, Linear, and Sentry. MCP servers, full stop. Many tools, multiple hosts, shared maintenance: exactly what the protocol was built for.
3. Customer-facing booking assistant on one backend. Native function calling. A protocol layer here is overhead you'll regret.

MCP is the right answer more often in 2026 than it was a year ago. It's still not free. Every server you install is supply chain you now own. Pick deliberately.

MCP glossary: the terms competitors keep mixing up

One reason MCP conversations go sideways: people swap "client" and "host" like they're synonyms. They're not. Here's the vocabulary, locked down.

Host: the app you actually open and type into. Claude Desktop, ChatGPT, Cursor, VS Code with an MCP extension.

Client: a protocol-level component inside the host. One client, one connection, one server. A host with five MCP servers attached is running five clients.

Server: the process exposing tools, resources, and prompts. Runs locally on your machine or remotely behind an HTTPS endpoint.

Transport: the wire protocol carrying JSON-RPC messages. stdio for local, Streamable HTTP for remote. SSE is deprecated as of the 2025 spec revisions.

Primitive: a typed object the protocol defines. The four are Tools (model-invoked actions), Resources (app-attached context), Prompts (user-triggered templates), and Sampling (server-requested LLM calls).

Registry: a directory of available servers. The official MCP Registry launched in 2025. Community catalogs like mcp.so list 21,000+ entries.

MCPB bundle: a packaged server, ZIP plus manifest.json, built for easier distribution and security auditing.

Tasks extension: the late-2025/2026 spec addition for long-running, resumable server work. Hour-long jobs that survive disconnects.

MCP Apps: server-rendered UI surfaced inside the host, introduced in the 2026-07-28 release candidate. Servers can ship interface now, not just data.

Bookmark this. You'll need it the next time someone calls Cursor a "client."