What Is the Model Context Protocol (MCP)? Architecture Explained

The Problem MCP Solves

Every AI assistant becomes dramatically more useful the moment it can reach beyond its own weights — read your database, search your docs, file a ticket, run a query. Before the Model Context Protocol, every one of those connections was a bespoke integration: one plugin format for this assistant, a different function-calling wrapper for that one, and a pile of glue code you rewrote for every model you supported.

MCP, introduced by Anthropic as an open standard in late 2024, replaces that N×M integration mess with a single protocol. Build one MCP server for your system, and any MCP-capable application — Claude Desktop, Claude Code, IDEs, agent frameworks, and a growing list of others — can use it. The comparison people reach for is USB-C: one standardized port instead of a different cable for every device.

The Three Roles: Host, Client, Server

MCP's architecture has three parts, and keeping them straight makes everything else easy:

Host — the AI application the user actually interacts with: Claude Desktop, an IDE assistant, a custom agent. The host owns the model, the conversation, and the permissions.

Client — a connection object inside the host. The host creates one client per server it connects to. You rarely write clients; hosts ship them.

Server — the piece you build. A small program that exposes capabilities (a database, a filesystem, an internal API) in MCP's standard vocabulary.

One host can talk to many servers at once — a filesystem server, a Postgres server, a GitHub server — and compose them in a single conversation. The model doesn't know or care how each server is implemented; it sees a uniform catalog of capabilities.

The Three Primitives

An MCP server can expose three kinds of things. The distinction is about who controls the action:

Tools — the model acts

Tools are functions the model decides to call while reasoning: search_tickets, run_query, create_branch. Each tool declares a name, a description, and a JSON-schema for its arguments. The model reads those descriptions to decide when and how to call the tool — which is why writing clear, specific descriptions is the highest-leverage work in MCP server design.

Resources — the application provides context

Resources are data identified by URIs (file:///readme.md, notes://today) that the host can load into context. Think of them as read-only context the application chooses to attach, rather than actions the model takes.

Prompts — the user invokes templates

Prompts are reusable templates a server offers to users — a code-review checklist, a report-summary format — typically surfaced in the host's UI (slash commands, menus) and filled with arguments when invoked.

Most real-world servers today are tool-centric, but the three-way split keeps control explicit: model-controlled (tools), app-controlled (resources), user-controlled (prompts).

Transports: How Bytes Move

MCP messages are JSON-RPC 2.0. Two transports carry them:

stdio — the host launches your server as a subprocess and speaks over stdin/stdout. Zero networking, perfect for local servers (filesystem, local git, dev tooling). This is how Claude Desktop runs most community servers.

Streamable HTTP — the server is a web service; clients POST messages and the server can stream responses. This is the transport for remote, shared, or hosted servers, and it replaced the older HTTP+SSE design in the 2025 revision of the spec.

A useful rule: local and personal → stdio; remote and multi-user → HTTP. We build one of each in the next two parts.

What a Session Looks Like

Host starts server → capabilities negotiated → model sees tool catalog → model calls tool → server executes and returns content → model uses the result in its answer.

Concretely: you ask "how many signups yesterday?", the model sees a run_query tool from your Postgres server, calls it with SQL as arguments, gets rows back as text content, and writes the answer. The entire exchange is standard JSON-RPC — which is why any host can drive any server.

Security Model in One Paragraph

MCP servers run with real permissions against real systems, so hosts put a human in the loop: tool calls surface for user approval (Claude Desktop and Claude Code both prompt before executing), and servers should be treated like any other privileged code — least-privilege credentials, input validation, and careful thought before exposing destructive operations. Treat every tool description and result as part of your security surface: a malicious server can try to steer the model, so only install servers you trust.

---

Next in this series: we build a working MCP server in TypeScript and connect it to Claude — Part 2: Build an MCP Server in TypeScript.