How Does MCP Work Under the Hood?

How does MCP work under the hood? It is a JSON-RPC 2.0 conversation between a client, embedded in the host application, and a server that exposes tools. The two shake hands and negotiate capabilities, the client fetches the tool list, and every tool call the model makes travels as a tools/call request over stdio or Streamable HTTP.

How MCP works internally, message by message

1. Three message shapes. Every MCP message is JSON-RPC 2.0. A request carries an id, a method and params; a response carries the same id with either result or error; a notification has a method but no id and expects no reply.
2. The initialize handshake. The client opens with initialize, stating the protocol version it speaks, its own capabilities and a clientInfo name. The server answers with the version it will use, its capabilities (whether it offers tools, resources or prompts, and whether it will announce list changes) and serverInfo. The client then sends notifications/initialized.
3. Discovery. The client calls tools/list, and resources/list or prompts/list when the server advertised them. Each tool arrives with a name, a description and a JSON Schema for its arguments. The host turns those into the tool definitions it hands to the model, so the model sees ordinary function definitions and never the protocol.
4. The call. When the model emits a tool call, the host matches the name to the client that advertised it and sends tools/call with the name and arguments. The server replies with content blocks, usually text, and optionally structuredContent. A failed run comes back with isError: true as a result the model can read, not as a protocol error.
5. Transports. Over stdio the host launches the server as a subprocess and exchanges newline-delimited JSON on stdin and stdout; stderr is for logs. Over Streamable HTTP the server is one endpoint at a URL: the client POSTs each message, the server answers with plain JSON or a server-sent event stream, and an optional Mcp-Session-Id header ties requests to a session.
6. Everything else is notifications. Servers announce changed tool lists, report progress and accept cancellation, and can ask the client for a model completion (sampling) or user input (elicitation) if the client declared those capabilities.

The host, not the model, owns the connection. When Claude or Cursor produces a tool call, the host looks up which client advertised that tool name, sends the request and inserts the result into the model’s context. With several servers connected it dispatches by name, which is why two servers exposing the same tool name cause trouble.

Where JobsPipe fits

JobsPipe is a jobs data API that collects live postings from LinkedIn, Indeed, Y Combinator, Naukri, Workday, Greenhouse, Workable, SmartRecruiters, Ashby, Lever and Paylocity, returns them as one schema with closure tracking and a ghost score, and includes a free tier of 1,000 jobs a month. It runs a hosted MCP server at https://mcp.jobspipe.dev/mcp over Streamable HTTP with four tools: search_jobs, detect_company_tech_stack, list_pricing_plans and search_documentation. When an agent calls search_jobs, the server maps the arguments onto POST /v1/jobs/search and returns the postings as structured content. You can watch the handshake yourself with curl:

curl -X POST https://mcp.jobspipe.dev/mcp \
  -H "Authorization: Bearer $JOBSPIPE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": { "name": "curl", "version": "1.0" } } }'

The response lists the server’s capabilities, and a tools/list call on the same session returns the four tool schemas. Setup for each client is on the MCP server page, the concepts are in what is an MCP server, and the server side is in how to build an MCP server.