Model Context Protocol

Why

Without a shared standard, connecting M AI clients to N external tools requires building approximately M times N custom adapters, because every client-tool pair needs its own integration code. MCP solves this by defining a single open protocol that each side implements once: every client speaks MCP, every server speaks MCP, so the total work drops to M plus N implementations. Bandwidth compression is not part of MCP's purpose; it standardizes the message format and lifecycle, not the wire efficiency. MCP does not remove authentication; in fact the specification recommends OAuth 2.1 and bearer tokens for remote servers. A universal query language is also unrelated; MCP defines how tools, resources, and prompts are discovered and invoked, but the actual query logic stays inside each server. The USB-C analogy from the specification captures the idea: just as USB-C gives one port for many devices, MCP gives one protocol for many AI integrations. This standardization benefits developers (less integration code), AI applications (broader ecosystem), and end users (more capable assistants).

Why

With three AI clients and three external systems, the naive approach builds 3 times 3 equals 9 custom integrations. MCP reduces this to 3 plus 3 equals 6 implementations: each AI client implements MCP once (3 clients), and each external system exposes an MCP server once (3 servers). Any client can then connect to any server through the shared protocol. Bundling all systems into a single monolithic server would defeat the composable, modular design that MCP encourages; each server is an independent program with its own capabilities. Embedding external logic into the client contradicts the entire client-server separation that MCP defines. Caching all data locally is not what MCP does; it provides a real-time protocol for context exchange, where servers expose live resources and tools. The M plus N benefit is the primary economic argument for MCP: it turns a quadratic integration problem into a linear one, just as USB-C standardized peripheral connections. This composability means a new AI client or a new external system only needs one more implementation.

Why

The MCP specification explicitly states that MCP focuses solely on the protocol for context exchange and does not dictate how AI applications use LLMs or manage the provided context. This separation of concerns is a deliberate design decision: MCP defines how to discover, request, and deliver tools, resources, and prompts, but leaves the AI application free to decide what to do with them. The claim that MCP specifies prompting strategies is false; prompt templates are exposed by servers for user-driven invocation, but the model's internal prompting is outside MCP's scope. MCP has nothing to do with model training or fine-tuning, which are entirely separate processes. The restriction to local file-system access is also wrong; MCP supports both local servers via stdio and remote servers via Streamable HTTP, enabling network connections to services like Sentry or Slack. The protocol is transport-agnostic by design, meaning the same message semantics work across different communication channels.

Why

MCP follows a precise client-server architecture with three distinct participants. The host is the AI application that users interact with, such as Claude Desktop or VS Code. For each MCP server it connects to, the host creates a separate MCP client instance. Each client maintains a dedicated connection to exactly one server. For example, when VS Code connects to a Sentry MCP server and a filesystem MCP server, it creates two separate client objects, each with its own connection. A shared connection pool contradicts this one-client-per-server design. The claim that all three are the same component is incorrect; each has a distinct role and responsibility. The reversed definitions of client and host are also wrong; the host is the user-facing application, not the client. This architecture means a host can simultaneously connect to many servers through multiple clients, combining specialized capabilities. Local servers typically serve a single client via stdio, while remote servers can serve many clients via Streamable HTTP.

Why

The MCP architecture specifies that the host creates one MCP client for each MCP server it connects to. With two servers configured, Claude Desktop creates exactly two client instances: one dedicated to the filesystem server and one dedicated to the Sentry server. Each client maintains its own independent connection. A shared multiplexing client would violate the one-to-one client-server relationship that the architecture mandates. A coordinator client is not part of the MCP architecture; the host itself manages the set of clients. The claim that no clients are created is incorrect because MCP clients are the protocol-level components that enable server connections, distinct from the host. The official documentation uses this exact example: VS Code connecting to Sentry and filesystem servers, instantiating a separate client for each. Local servers like the filesystem server use stdio transport, while remote ones like Sentry use Streamable HTTP, but each still gets its own client regardless of transport.