Why architecture matters here
MCP architecture matters because it standardizes the messiest part of LLM integration. Every custom tool wrapper written in the past two years — the OpenAI Function Calling adapter, the LangChain tool spec, the Anthropic tools API — has its own semantics, its own security model, and its own authentication story. MCP replaces N different integrations with one.
Adoption is the driver. Once a company publishes an MCP server for its API, every LLM client can consume it: Claude Desktop, ChatGPT via connectors, Cursor, Cody, and many open-source clients. The integration effort collapses from per-vendor to per-provider.
Security is where MCP forces good design. The protocol distinguishes resources (read-only data), tools (actions with parameters), and prompts (templated workflows). Scopes and auth attach cleanly to each; audit is uniform. The architecture makes it hard to accidentally give an LLM more power than intended.
The architecture: every piece explained
Walk the diagram top to bottom.
MCP Client (LLM). The LLM host — Claude Desktop, ChatGPT with connectors, Cursor, a custom agent. The client decides which servers to connect to, initiates sessions, and passes tool calls between the model and the servers.
Transport. stdio for local process integrations (best for on-machine tools with no auth needed); SSE for HTTP-based servers with server-sent updates; HTTP for standard request/response. Choose based on deployment: stdio for desktop, SSE or HTTP for hosted.
MCP Server. The process that implements the protocol. It receives JSON-RPC messages, dispatches to handlers, and returns responses. SDKs exist in Python, TypeScript, Rust, and Go; most servers use one.
Capability Negotiation. On session start, client and server exchange capabilities. The server lists its resources, tools, and prompts; the client lists what it supports (sampling, roots, elicitation). Only mutually supported features are used.
Auth and Session. HTTP transports typically use OAuth 2. Scopes limit what the LLM can do through this session. Session state includes the authenticated user and any scoped credentials.
Resources. Named, read-only data exposed to the LLM. A file, a database record, a page from a wiki. Resources have URIs; the client subscribes to changes for freshness.
Tools. Named, invocable actions with JSON schemas for parameters and return values. Tools do things — read a database, send an email, run a query, create a ticket. The LLM decides when to call based on schema and description.
Prompts. Templated prompt workflows the client can invoke with parameters. Reusable prompts standardize how a task is described to the model. Prompts help maintain quality across clients.
Backend Systems. The systems the server actually talks to: databases, internal APIs, third-party services. The server is a translation layer between MCP semantics and backend specifics.
Safety Layer. PII scrubbing on responses, scope enforcement on tool calls, audit logging of every action. This is where security defenses live server-side; do not rely on the LLM to self-limit.
Registry. A publicly or internally cataloged list of MCP servers with descriptions, versions, and permissions. Discovery matters when you have dozens of servers.
End-to-end session flow
Trace a session. Claude Desktop starts and connects to configured MCP servers via stdio. For each, it sends an initialize message with client capabilities.
The server responds with server info and capabilities: "I offer 5 tools (query, insert, list, update, delete), 3 resource URIs (recent_events, current_config, health), and 1 prompt template (data_analysis)."
The user asks Claude a question that requires data. Claude decides to call the "query" tool with arguments {"table": "orders", "where": "date >= '2026-01-01'"}. Claude Desktop forwards the JSON-RPC tools/call message to the server.
The server validates the arguments against the tool's JSON schema, applies scope check (does this session have read on orders?), runs the query against the backend database, applies PII scrubbing on the result, and returns rows.
Claude reads the result, decides whether to make more calls or answer, and streams the response back to the user with citations to the tool call.
All of this is logged. If the tool fails, the server returns a structured error; Claude either retries with different args or reports the failure to the user.