How the Pieces Fit Together

Three roles, one connection

MCP splits responsibility across three roles, and it's worth keeping them straight before anything else, since most confusion about the protocol traces back to mixing them up.

A server that exposes, say, a project tracker's tools doesn't need to know whether it's being called from a desktop assistant or a custom internal dashboard. That separation is what makes a server reusable across completely different hosts without any changes on either side.

The wire format: JSON-RPC 2.0

Underneath the roles, MCP is built on JSON-RPC 2.0, a lightweight standard for structuring requests and responses as JSON. It gives MCP a few things for free: requests can flow in either direction (a server can ask the AI model for something mid-task, not just respond to requests), connections stay stateful across a whole session instead of resetting every call, and long-running work doesn't have to block the connection while it finishes.

Picking a transport

The same JSON-RPC messages can travel over more than one transport, and the right choice depends on where the server runs:

If you're building something only you will run on your own machine, start with STDIO; there's nothing to secure beyond your own filesystem permissions. Move to Streamable HTTP once a server needs to serve more than one person or live somewhere other than a laptop.

What a request actually looks like

Here's the shape of a tool a server might advertise:

{
  "name": "add_calendar_event",
  "description": "Create a calendar event with a title, start time, and optional attendees",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "start_time": { "type": "string" },
      "attendees": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["title", "start_time"]
  }
}

And here's the full sequence from connection to result:

1. The client connects to the server over the chosen transport.
2. The server advertises its available tools, resources, and prompts.
3. The AI model, seeing what's available, decides a tool is relevant to the current task.
4. The model constructs a call matching that tool's input schema.
5. The client sends the call to the server as a JSON-RPC request.
6. The server executes it and returns a result, or an error.
7. The client hands the result back to the model.
8. The model incorporates it and continues, or responds to the user.

Every one of the deeper topics in this guide, tool design, security, performance, is really about making one or more of those eight steps work well under real conditions rather than just in a demo.