How MCP Works: The Request Lifecycle from Discovery to Tool Result

MCP works as a negotiated client-server session. Before a tool can be called, the client and server establish a protocol version, exchange capabilities, and complete initialization. The client can then discover the server's available primitives, send a request, receive a result or error, and close the connection when the session ends.

1. The host creates a client

The host application selects a server and creates an MCP client for the connection. The transport may be stdio for a local process or Streamable HTTP for a remote service. The client is responsible for speaking the protocol over that transport.

2. Initialization establishes the session

The client sends an initialize request with its supported protocol version, client capabilities, and implementation details. The server responds with the version and server capabilities it will use. The client follows with an initialized notification. Normal operations begin only after this handshake.

3. Discovery makes the catalog visible

The client can request the server's tools, resources, or prompts when the corresponding capabilities are available. The returned names, descriptions, schemas, and URIs give the host enough information to decide what to present or what an agent may call.

4. A request is validated and executed

For a tool call, the client sends a JSON-RPC request with a method and structured arguments. The server validates the method, arguments, authorization, and domain constraints before doing work. It returns a result or a protocol error. A tool result can also carry an application-level error even when the transport itself completed successfully.

5. Notifications and updates can occur

Servers can send notifications such as catalog changes or progress updates when those capabilities are negotiated. Clients and servers should still apply timeouts and bounded work so a slow or misbehaving operation does not exhaust resources.

6. Shutdown closes the connection

MCP does not require a separate shutdown message. A stdio client closes the child process input and waits for the process to exit, while HTTP sessions close their associated connections. Operational telemetry should make the end of a session distinguishable from a failed connection.

A useful debugging timeline

• Initialization failed: inspect protocol version and capability compatibility.
• Discovery failed: inspect the server catalog and the negotiated feature.
• The call was rejected: inspect authorization, method, schema, and validation.
• The call returned an error: inspect tool behavior and downstream dependencies.
• The call succeeded but the workflow stopped: inspect the host-side context and outcome signal.