MCP (Model Context Protocol), Explained

The problem MCP solves

Before MCP, connecting a model to the outside world meant hand-rolling an integration per application. Each app defined its own tool schemas, its own auth handshake, and its own way of streaming results back into the context window. Nothing was reusable: the connector you wrote for a chat app could not be dropped into an IDE or a batch agent without a rewrite.

MCP reframes this as a protocol problem. Instead of M applications each integrating N systems (M times N bespoke connectors), you build N servers and M clients that all speak the same protocol. A new data source ships one server and instantly works in every host; a new host speaks MCP once and gains every existing server. This is the same architectural win that USB or LSP delivered: a stable interface that decouples producers from consumers.

Host, client, and server

MCP has three roles. The host is the application the user actually interacts with, Claude Desktop, an IDE extension, or your own agent runtime. Inside the host runs one MCP client per connection. Each client maintains a dedicated, stateful session with exactly one MCP server. The server is a separate process or service that exposes capabilities: it wraps a database, a SaaS API, a filesystem, or an internal tool.

• Host: owns the model, the conversation, and the security boundary; decides which servers to connect and what the model is allowed to invoke.
• Client: a per-server connector inside the host that handles the MCP handshake, capability negotiation, and message passing.
• Server: publishes tools, resources, and prompts; runs with only the credentials and scope you grant it.
• The model never talks to a server directly. The host mediates every call, which is where you enforce approval, logging, and policy.

The three primitives: tools, resources, prompts

An MCP server exposes capability through three primitives, and knowing which is which shapes how you design a server.

The distinction matters for control. Tools are the powerful, potentially side-effecting primitive, so they carry the most scrutiny. Resources are how you feed data in without giving the model a lever to change anything. Prompts let a server ship a tested workflow rather than hoping the user phrases a request well.

Transports: stdio vs HTTP, local vs remote

MCP separates what is exchanged (the protocol, JSON-RPC messages) from how it is carried (the transport). Two transports dominate, and the choice tracks whether the server is local or remote.

• stdio: the host launches the server as a local subprocess and talks over standard input/output. Ideal for local tools, developer machines, and filesystem or CLI access. No network, low latency, trust derived from the fact that it runs as the local user.
• Streamable HTTP (with Server-Sent Events for streaming): the server is a remote service reached over HTTP. This is how you run a shared, centrally hosted server that many users connect to, and it is where authentication and network security become first-class concerns.

Tool descriptions drive routing, and scoping keeps it safe

The model decides which tool to call almost entirely from the tool's name, description, and input schema. Those descriptions are not documentation for humans, they are the routing signal for the model. Vague or overlapping descriptions cause the model to pick the wrong tool, pass malformed arguments, or call nothing at all. Treat tool-description quality as a core reliability lever: state what the tool does, when to use it, what each argument means, and when NOT to use it.

• Give each tool a single, clear responsibility; avoid two tools whose descriptions could both plausibly match a request.
• Describe arguments precisely with types and constraints in the JSON Schema so the model fills them correctly.
• Expose the smallest useful set of tools. More tools mean more routing ambiguity and more context spent listing them.
• Apply least privilege: a server should hold only the scopes it needs. A read-only reporting server should not carry write credentials, so a prompt-injected instruction has nothing dangerous to reach.

Authentication: delegated tokens, not secrets in prompts

Remote MCP servers authenticate with standard web auth. The specification builds on OAuth 2.1, so the host obtains a delegated access token on behalf of the signed-in user and the server enforces that user's permissions at the data layer. This is the correct pattern for multi-user, access-controlled systems: the server acts as the user, sees only what that user is allowed to see, and never relies on the model to police access.

• Never place API keys, passwords, or long-lived secrets in prompts, tool arguments, or resource text. The model does not need them and the context window is not a vault.
• Prefer per-user delegated tokens (OAuth) so authorization is enforced by the downstream system, not inferred by the model.
• Scope tokens narrowly and rotate them; a token minted for a reporting server should not unlock admin actions.
• Keep authorization decisions server-side. The model can be tricked; your access-control layer cannot be talked out of a permission check.

MCP vs direct function-calling, and when to use it

MCP does not replace the model's tool-use (function-calling) mechanism, it standardizes and packages it. With raw function-calling you define tool schemas inline in your application and wire the execution yourself; it is the right choice for a small, fixed set of app-specific tools that no other application will ever reuse. MCP is the right choice when you want those tools to be portable, independently deployed, and shared across hosts and teams.

{
  "name": "search_tickets",
  "description": "Search the support ticketing system by keyword, status, or assignee. Use for questions about existing tickets. Do NOT use to create or modify tickets.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Keywords to match in title or body." },
      "status": { "type": "string", "enum": ["open", "pending", "closed"] }
    },
    "required": ["query"]
  }
}