How MCP works

MCP works through a client-server architecture in which an MCP client connects to one or more servers, negotiates capabilities, and then routes model tool calls and resource requests to the appropriate server — with all communication following the MCP specification's message format and transport conventions.

The connection and initialization sequence

When an MCP client connects to a server, the two parties exchange initialization messages. The client sends its protocol version and capabilities; the server responds with its protocol version, its implementation name, and the capabilities it supports. Following initialization, the client sends a request for the server's full capability catalog — requesting the list of tools, resources, and prompts the server exposes. The server returns these definitions with their schemas and descriptions. The client stores this catalog and makes it available to the model host. This handshake happens once at connection time; subsequent interactions use the established session.

Tool call flow

When the model decides to call a tool, it produces a tool call message with the tool name and arguments formatted according to the tool's schema. The model host passes this to the MCP client, which identifies which server registered that tool, formats the call as an MCP tool-call request, and sends it to the server. The server executes the tool — calling an API, querying a database, running a function — and returns a result message. The client receives the result and returns it to the model host as a tool result, which the host includes in the model's context for the next reasoning step. Resource access follows a similar flow with different message types.

Error handling and protocol robustness

The MCP specification defines standard error types for common failure conditions: tools that are not found, invalid arguments, execution failures, and transport-level errors. Servers return structured error responses that the client can interpret and surface to the model host in a consistent way. The model host decides how to handle errors — retrying the call, trying an alternative tool, or surfacing the failure to the user. This standardized error handling means that error logic written for one server's error responses transfers to any other MCP server, reducing the boilerplate that agent developers would otherwise need to write.

How MCP works — FAQ

Is MCP stateful or stateless?

MCP connections are stateful — the client and server maintain a session with negotiated capabilities for the duration of the connection. Individual tool calls within a session are stateless in the sense that each call is independent, but the connection itself carries state (negotiated capabilities, session metadata). This means that if the connection drops, the client must re-establish it and re-negotiate capabilities, which is why client implementations typically include reconnection logic.

Can MCP handle streaming responses from tools?

The MCP specification includes support for streaming in tool responses, allowing servers to return partial results progressively rather than waiting until the entire result is available. This is useful for tools that produce large outputs — log retrieval, long-running computations, or data exports — where returning the complete result before the model can begin processing it would add unnecessary latency. Not all tool implementations use streaming, but the protocol supports it for use cases where it improves performance.