MCP server implementation sits at the boundary between AI clients, external systems, and user trust controls, making it as much protocol engineering as application development. The 2025-11-25 specification is the current stable standard, with a 2026-07-28 release candidate (locked May 21, 2026) that replaces stateful sessions with a stateless protocol core, enabling horizontal scaling without sticky routing or shared session stores. Whether targeting the stable spec or the upcoming RC, the key mental model remains treating tools, resources, prompts, elicitation, and the extensions framework as distinct surfaces with different control planes, risk profiles, and approval expectations. A production-quality server also requires precise command of JSON-RPC request semantics, transport choices, OAuth-aligned authorization, and the new Tasks and MCP Apps extensions, because most real failures come from mismatched assumptions rather than broken business logic.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 185 indexed concepts, 125 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Architecture and Lifecycle
MCP defines a three-participant architecture and a strict session lifecycle where capability negotiation precedes all operational work. The 2025-11-25 stable spec uses a stateful initialize handshake; the 2026-07-28 RC removes it in favor of per-request _meta metadata so any server instance can handle any request.
| Role | Example | Description | |
|---|---|---|---|
Claude DesktopVS CodeChatGPT | Runs the AI application, owns the user experience, and typically embeds one or more MCP clients. | ||
host-integrated connector | Speaks MCP on the host's behalf, manages connections, and mediates server access. | ||
stdio child processhttps://example.com/mcp | Exposes context and capabilities such as tools, resources, and prompts. | ||
{"method":"initialize"} | • First required request in 2025-11-25 • negotiates protocol version, capabilities, and implementation info. | ||
{"method":"notifications/initialized"} | Client-side readiness signal that starts normal operation after initialization. | ||
"protocolVersion":"2025-11-25" | Lets both sides settle on a shared spec revision before using optional features. | ||
{"tools":{"listChanged":true},"tasks":{}} | • Declares which optional surfaces are actually available • tasks is a new bilateral capability | ||
"instructions":"Use read-only tools first" | Optional server guidance that helps the client or model interpret server behavior. | ||
{"jsonrpc":"2.0","id":1,"method":"ping"} | • Either side may send a ping • receiver MUST respond promptly with an empty result or the sender may treat the connection as stale | ||
{"method":"server/discover"} | • (2026-07-28 RC) Stateless replacement for initialize • returns capabilities on demand without a persistent session | ||
stdin closeHTTP disconnect | Uses the underlying transport rather than a special MCP shutdown method. | ||
cancel after 30s | • Prevents hung requests and should be paired with cancellation support • reset clock on progress notifications is permitted |