How does MCP (Model Context Protocol) work?

In detail

Three roles

The MCP architecture guide names three participants. The host is the AI application a person uses, such as an IDE, a desktop assistant or an internal agent. A server is a program that provides context or actions from one system, such as a file system, a ticket tracker or a database. The host creates one client for each server, and each client keeps a single connection to its server.

Block’s path into the protocol shows how the roles fit. Angie Jones says an engineer building an internal tool kept running into problems with models and tool calling. When Anthropic showed Block a draft of MCP, the team rebuilt that tool, Goose, as an MCP client and released it as open source. Each new system Block connected became another server Goose could use.

What a server can offer

The guide describes three core primitives a server exposes:

• Tools: functions the host can call to take an action or run a query, such as creating a ticket or searching a codebase.
• Resources: data the host can read for context, such as file contents or database records.
• Prompts: reusable templates that structure an interaction, such as a review checklist.

Each has a way to discover what is available (for example tools/list) and to use it (tools/call for tools). Messages follow JSON-RPC 2.0, a small standard for requests and responses. The 2026-07-28 specification, current as of October 24, 2026, carries protocol version and capabilities in per-request _meta rather than a connection-start negotiation handshake. A client can optionally call server/discover to learn what the server supports. Legacy versions, 2025-11-25 and earlier, instead establish a session with an initialize handshake.

Two ways to connect

A server can run on the same machine as the host and talk over standard input and output, which the guide notes typically serves a single client. Or it can run as a remote service over Streamable HTTP, which typically serves many clients. The same JSON-RPC messages travel over both.

SwirlAI’s Aurimas Griciūnas thinks MCP brings the most value with remote servers, and warns that it is sometimes overused: for a tool that lives inside your own code, calling it directly can be simpler. The trade-off is in MCP vs. a custom integration.

Follow one request

Illustrative example: a developer asks an IDE assistant to summarize the open bugs assigned to her.

1. The IDE creates a client for the issue-tracker server. It may first call server/discover to learn the server’s supported versions and capabilities, but this is optional. Each request carries its version and capabilities in _meta, and the server accepts or rejects that request independently.
2. The client asks for the server’s tool list and gets back names, descriptions and input schemas, including search_issues.
3. The host passes those tool descriptions to the model along with the request. The model replies that it wants to call search_issues with her username and an open status.
4. The host checks its approval rules, then sends tools/call through the client. The server queries the tracker with the developer’s own credentials and returns the results.
5. The host adds the results to the model’s context, and the model writes the summary.

The model chooses the tool; the host makes the call. How the model makes that choice is covered in how AI agents use tools.

Where the safety decisions live

The protocol leaves the important controls to the host. The specification’s tool schema lets a server mark a tool with hints such as destructiveHint, which signals that a call may delete or overwrite something. The schema also warns that these annotations are hints and that clients should not trust them from servers they do not trust. The tools section says there should always be a human in the loop who can deny a tool call.

Block uses the same pattern. Jones says her team marks destructive tools, and Goose lets an agent run any non-destructive tool on its own but asks the user before a destructive one. Block also connects its own MCP servers to its identity provider through OAuth, so signing in works like any other work app. The rest of Block’s rollout controls are in 4 guardrails for letting your whole company use AI.

Scoping access is where things go wrong. CrewAI’s João Moura cites an incident in which GitHub’s new MCP server gave access to private repositories it should not have. In his account, the hard part is not only authentication but the scope of access, which may need to change during a run depending on who is running it. The specification’s security best practices forbid one common shortcut, token passthrough, where a server forwards a client’s token to a downstream API without checking that the token was issued for that server.

Where it falls short

MCP standardizes the connection, not the quality of what sits behind it. Airbyte’s Michel Tricot puts it this way: MCP is just an interconnect, a way of connecting a model to an external system, and a thin wrapper over an API will still give the model poor results. Every tool description a host loads also takes up room in the model’s context, so connecting many servers has a cost even before a single call. For how MCP relates to agent-to-agent protocols, see MCP vs. A2A.

Disclosure: Episodes 48 and 52 are sponsored by Galileo, the Season 3 presenting sponsor; the reads are at 49:33 in episode 48 and at 1:30 in episode 52. Episodes 29 and 38 were sponsored by Galileo, where Conor then worked; episode 29 was co-hosted by Galileo CEO Vikram Chatterji, introduced at 0:29.