MCP lifecycle

2 min read
On trails:AGPROTOstep 3/4

One tool callTool useFunction calling gives the model hands: it asks, and code does the work.Opens in a new tab has three beats, the same as ordering at a restaurant: the menu, the order, the delivery. In MCP terms the client asks what tools exist, asks for one to run, and gets the result back.

Discovery: the client sends tools/list and the server returns tool names, descriptions and input schemas. The model picks a tool. Order: the client sends tools/call with a name and arguments. Delivery: the server returns a result with content and isError. client server 1 DISCOVERY the menu tools/list tool names, descriptions, input schemas model picks a tool 2 ORDER the order tools/call {name, arguments} 3 DELIVERY the delivery result {content, isError}
The three beats, as messages.

The menu

The client sends tools/list and the server answers with each tool’s name, description and inputSchema, a JSON Schema for the arguments. The model reads that and decides what it can order. The menu is not a file on disk. The server answers it on request, and it can change: a server that declares listChanged can notify the client, which then asks again. The file-style version of this idea does exist in A2A, as the Agent Card (see A2A, ACP and AG-UIA2A, ACP and AG-UIThe other three protocols: agent to agent, the one that merged, and agent to user.Opens in a new tab).

The order

order.httpHTTP
POST /mcp HTTP/1.1Content-Type: application/jsonAccept: application/json, text/event-streamMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: get_weather {  "jsonrpc": "2.0",  "id": 3,  "method": "tools/call",  "params": {    "name": "get_weather",    "arguments": { "city": "Colombo" },    "_meta": {      "io.modelcontextprotocol/protocolVersion": "2026-07-28",      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },      "io.modelcontextprotocol/clientCapabilities": {}    }  }}

The order is a POST to the MCP endpoint, carrying a JSON-RPC tools/call with the tool’s name and arguments that match the menu’s schema. The Mcp-Method and Mcp-Name headers repeat what is in the body, so gateways can route without parsing it. The _meta block on every request is covered below.

The delivery

result.jsonJSON
{  "jsonrpc": "2.0",  "id": 3,  "result": {    "resultType": "complete",    "content": [{ "type": "text", "text": "Sunny in Colombo" }],    "isError": false  }}

The answer comes back in content. A tool that fails still returns a result, with isError: true, so the model can read the message and retry. A protocol problem, such as an unknown tool, is a JSON-RPC error instead. Between the menu and the order, the host is the place to ask a person to confirm (see human in the loopHuman in the loopA pause in the agent's decision, where a person approves before a high-risk action runs.Opens in a new tab).

Before the first order

Revisions up to 2025-11-25 opened with a handshake: the client sent initialize with its protocol version and capabilities, the server replied, and the client followed with notifications/initialized. Revision 2026-07-28 removed it. Every request now carries its own protocol version and client capabilities in _meta, and an optional server/discover returns the server’s versions, capabilities and identity in one call.

A client that must reach both kinds of server has to detect which one it is talking to, then fall back to initialize for the older kind.

Sources