Model Context Protocol — How It Works Locally and in the Cloud

1 · The wire model

MCP is an open, JSON-RPC 2.0–based protocol with a client–host–server architecture. A host (typically an LLM application or agent runtime) creates and manages one MCP client per server, and each client communicates with exactly one MCP server (a process that exposes tools, resources, and prompts). The protocol is transport-agnostic; the current revision (2026-07-28) standardises two transports: stdio and Streamable HTTP.

2 · The stdio transport

Under the stdio transport, the client launches the server as a child process and exchanges newline-delimited JSON-RPC messages over the server's standard input and standard output. The server may write UTF-8 strings to standard error for logging. This is the default transport for local, single-user tools (filesystem access, local databases, local scripts).

Source: modelcontextprotocol.io · Specification 2026-07-28 · stdio

3 · The Streamable HTTP transport

Streamable HTTP is the standardised transport for remote MCP servers. The server exposes one POST-only endpoint. Every JSON-RPC request is a separate HTTP POST, and the response is either a single JSON object or a Server-Sent Events (SSE) stream scoped to that request. The protocol has no HTTP-level session and no standalone GET stream.

Source: modelcontextprotocol.io · Specification 2026-07-28 · Streamable HTTP · Multi Round-Trip Requests · Subscriptions

4 · Stateless request flow

MCP no longer has a protocol-level connection lifecycle. Each request is self-describing and independent: the client may first call server/discover, list the server's tools, and invoke one of them. Every request repeats the protocol version and client capabilities in _meta; no handshake or hidden session state is created.

Wire example — discovery, listing, and invocation

These representative exchanges show the required per-request metadata and the new result fields.

1 · Client → Server: optional server/discover

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      }
    }
  }
}

Source: modelcontextprotocol.io · Specification 2026-07-28 · Discovery

2 · Server → Client: server/discover response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "resources": {},
      "tools": { "listChanged": true }
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "ExampleServer",
        "version": "1.0.0"
      }
    },
    "instructions": "Weather and resource utilities",
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

Source: modelcontextprotocol.io · Specification 2026-07-28 · Discovery

3 · Client ↔ Server: tools/list

// Request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      }
    }
  }
}

// Response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "get_weather",
        "title": "Weather Information Provider",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

Source: modelcontextprotocol.io · Specification 2026-07-28 · Server / Tools

4 · Client → Server: tools/call + response

// Request
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      }
    }
  }
}

// Response
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"
      }
    ],
    "isError": false
  }
}

Source: modelcontextprotocol.io · Specification 2026-07-28 · Server / Tools

5 · Pattern A — Local AI clients

A local AI application (Claude Code, VS Code, Cursor, and others) acts as the MCP host. It reads a configuration file that lists MCP servers, creates one MCP client per entry, spawns stdio servers as child processes, and sends HTTP requests to remote servers. It combines their tools into one logical catalog, but may load tools on demand or expose a search step instead of placing every definition in every model turn.

Configuration — Claude Code

Claude Code reads .mcp.json at the project root (or ~/.claude.json for user-wide servers). For the two transports this paper covers, the type field accepts stdio and http — with streamable-http as an alias for http. Claude Code also accepts sse — the legacy HTTP+SSE transport, which remains in the specification in the Deprecated state — and an app-specific ws (WebSocket) transport that sits outside the specification altogether.

{
  "mcpServers": {
    "github": {
      "type": "streamable-http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    },
    "my-db": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@bytebase/dbhub", "--dsn", "${DB_DSN}"],
      "env": { "DB_TIMEOUT": "30000" }
    }
  }
}

Source: code.claude.com/docs/en/mcp · Connect Claude Code to tools via MCP

Configuration — VS Code (Copilot Chat)

VS Code reads .vscode/mcp.json for workspace-scoped servers (or a user-profile mcp.json for user-wide). The root key is servers (not mcpServers); the type field accepts stdio, http, and sse — the last being the legacy HTTP+SSE transport, which the specification now marks Deprecated. VS Code tries the HTTP Stream transport first and falls back to SSE only for a server that does not support it.

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

Source: code.visualstudio.com · Add and manage MCP servers · MCP configuration reference

Configuration — Cursor

Cursor reads ~/.cursor/mcp.json (global) or .cursor/mcp.json (project). The root key is mcpServers. Remote entries declare only a url; Cursor infers the HTTP transport when url is present.

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "mcp-server-filesystem", "/path/to/project"],
      "env": { "LOG_LEVEL": "info" }
    }
  }
}

Source: cursor.com/docs/mcp · Model Context Protocol

6 · Pattern B — Server-hosted AI agents

In this pattern, the agent runtime acts as the MCP host: running in a container, a serverless function, or a long-lived service, it creates one MCP client per server. Local stdio servers are less common because the runtime may be ephemeral or may restrict child-process execution. The agent instead connects to one or more remote MCP servers over Streamable HTTP. Those servers may run in the same cluster as the agent or be operated by a third party.

7 · Authorization (Streamable HTTP)

Authorization is optional in MCP. When an HTTP server is protected, implementations SHOULD follow the MCP OAuth 2.1 profile: Protected Resource Metadata (RFC 9728) locates the authorization server, PKCE protects the authorization code, Resource Indicators (RFC 8707) bind tokens to the MCP server, and issuer validation (RFC 9207) prevents authorization-server mix-up. Client ID Metadata Documents are preferred; Dynamic Client Registration is deprecated.

Source: modelcontextprotocol.io · Specification 2026-07-28 · Authorization · Client registration

8 · Authoring an MCP server

The Tier 1 SDKs for revision 2026-07-28 are TypeScript, Python, Go, and C#; Rust supports the revision in beta. The Python and TypeScript v2 examples below use high-level APIs that hide JSON-RPC parsing and derive tool schemas from native types. The same tool definitions are served over stdio or Streamable HTTP by changing only how the server is mounted at startup.

Source: Official MCP 2026-07-28 release announcement

Python v2 — MCPServer

Install with pip install "mcp[cli]". A minimal server exposes one tool and runs over stdio:

from mcp.server import MCPServer

mcp = MCPServer("greeting-server")

@mcp.tool()
def greet(name: str) -> str:
    """Greet someone by name"""
    return f"Hello, {name}!"

if __name__ == "__main__":
    mcp.run()              # stdio is the default transport

Source: Official MCP Python SDK v2 · Running your server

To serve the same code over Streamable HTTP, change one line:

if __name__ == "__main__":
    mcp.run(transport="streamable-http", port=8000)
    # server is now reachable at http://localhost:8000/mcp

Source: Official MCP Python SDK v2 · Streamable HTTP

TypeScript v2 — McpServer

Install with npm install @modelcontextprotocol/server zod. A minimal stdio server:

import { McpServer } from "@modelcontextprotocol/server";
import { StdioServerTransport } from "@modelcontextprotocol/server/stdio";
import * as z from "zod/v4";

const server = new McpServer({ name: "greeting-server", version: "1.0.0" });

server.registerTool(
  "greet",
  {
    description: "Greet someone by name",
    inputSchema: z.object({ name: z.string() }),
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }],
  }),
);

const transport = new StdioServerTransport();
await server.connect(transport);

Source: Official MCP TypeScript SDK v2 · README quickstart

Streamable HTTP is not a different transport object in v2. createMcpHandler takes the same registrations wrapped in a factory and returns a web-standard handler. The factory runs once per HTTP request, so a fresh McpServer serves every call and the handler keeps nothing between requests — §4's stateless request model expressed directly in the API:

import { createMcpHandler, McpServer } from "@modelcontextprotocol/server";

const handler = createMcpHandler(() => {
  const server = new McpServer({ name: "greeting-server", version: "1.0.0" });
  server.registerTool(/* …the same registration as above… */);
  return server;
});

Source: Official MCP TypeScript SDK v2 · Serve over HTTP (createMcpHandler replaces v1's per-request StreamableHTTPServerTransport + connect() wiring).

handler.fetch is a standard (Request) => Promise<Response>, so on a web-standard runtime (Cloudflare Workers, Deno, Bun) export default handler is the entire mount. Node frameworks wrap it once with toNodeHandler; thin adapter packages cover Node, Express, Fastify, and Hono:

npm install @modelcontextprotocol/server @modelcontextprotocol/express @modelcontextprotocol/node express

import { createMcpExpressApp } from "@modelcontextprotocol/express";
import { toNodeHandler } from "@modelcontextprotocol/node";

const app = createMcpExpressApp();   // express() + express.json() + DNS-rebinding guards
const node = toNodeHandler(handler);

app.all("/mcp", (req, res) => void node(req, res, req.body));
app.listen(3000);

Source: Official MCP TypeScript SDK v2 · Serve with Express. createMcpExpressApp applies the Host and Origin validation §3 requires, defaulting to a 127.0.0.1 bind; pass allowedHosts when binding to 0.0.0.0.

9 · Side-by-side · stdio vs Streamable HTTP

10 · Summary observations

Six factual observations drawn from revision 2026-07-28 and the current Tier 1 SDKs.

Sources: 2026-07-28 changelog · stdio · Streamable HTTP · MRTR · Subscriptions · Authorization · SDK docs cited in §8.

11 · Mini-glossary

Terms used throughout this paper.

MCP-specific definitions above are taken from the MCP Specification 2026-07-28. RFC numbers refer to the published IETF documents.