Concept card

Model Context Protocol (MCP) — Specification Deep Dive

As of 2026-10-05

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Model Context Protocol (MCP)?

MCP's capability negotiation handshake means a client must never assume an undeclared capability — a server that omits "resources" makes any resources/list call by the client a protocol violation, not a graceful no-op.

The Model Context Protocol is a precise, versioned contract that governs how an AI agent talks to the outside world — the databases, business applications, and tools it needs to actually get work done rather than just talk about it. For an SAP analytics practitioner, understanding the protocol machinery itself, not just the fact that Joule or another assistant "supports MCP," is what separates someone who can evaluate a vendor's integration claims from someone who has to take them on faith.

What the protocol actually is

MCP is built on JSON-RPC 2.0, the same lightweight remote-procedure-call format that already powers the Language Server Protocol behind modern code editors. Every message is a plain JSON object carrying a method name, optional parameters, and, for requests that expect an answer, an identifier used to match the response back to the call. The choice is deliberate rather than incidental: JSON-RPC is widely implemented, has predictable and structured error handling, and does not care what pipe it travels over — the identical message format works across a local process pipe, a web-based streaming connection, or a persistent socket. That transport independence is what lets the same protocol serve a developer's laptop and a production multi-tenant deployment without redesigning the message layer.

Why it matters

Built on JSON-RPC 2.0 (the same format as the Language Server Protocol), MCP inherits predictable structured error semantics and transport-agnosticism across stdio, SSE, or WebSocket.
The initialize handshake forces both client and server to declare capabilities explicitly, making the protocol forward-compatible — new capability types degrade gracefully on older clients.
Tools are the highest-risk primitive because a tools/call can write data or trigger irreversible workflows — schema quality on this primitive matters more than on resources or prompts.

Key points

JSON-RPC 2.0 wire format — requests, responses, notifications; current spec revision is 2026-07-28, which moved the base protocol to stateless, self-contained requests with per-request capability negotiation, superseding the earlier 2025-06-18 session-based model.
Two transports remain — stdio for local clients (Claude Desktop, Cursor, a SAP Build local server) and Streamable HTTP for remote; the 2026-07-28 revision drops the Mcp-Session-Id session-continuity mechanism as a base-protocol requirement.
Three-phase session — initialize (protocol version + capabilities) → notifications/initialized → feature calls until close — unchanged in spirit, though capability negotiation is now evaluated per request rather than pinned for the life of a stateful session.
Capability negotiation — tools, resources, prompts, sampling, roots, plus the new elicitation client capability (server-initiated requests for more information from the user) added in the 2026-07-28 revision.
The 2026-07-28 revision adds a formal, opt-in extensions framework: Tasks (async execution of long-running operations with polling and durable handles), Skills over MCP (structured agent-workflow instructions), and MCP Apps (interactive inline UI elements) — none mandatory, all negotiated at initialize like core capabilities.
Adopted by SAP, OpenAI, Google, Microsoft — the single cross-vendor surface; Analytics Legends MCP server is the internal reference implementation.
SAP implements MCP as a server, not yet as a confirmed 2026-07-28 spec adopter: the BTP administration MCP server and the Integration Suite MCP Gateway both predate this revision and should be re-checked for elicitation and extension support before being cited as fully current.

Terms used on this page

JSON-RPC 2.0: Lightweight remote-procedure-call protocol over a bidirectional byte stream; defines request, response and notification message shapes that MCP layers its semantics on top of.
Streamable HTTP transport: MCP's remote transport, introduced in the 2025-06-18 revision with session continuity via an Mcp-Session-Id header; the 2026-07-28 revision moved the base protocol to stateless, self-contained requests with per-request capability negotiation, removing that session-ID mechanism as a base requirement. A single HTTP endpoint still accepts JSON-RPC POSTs and may upgrade to a server-sent-event stream for progressive responses.
Capability negotiation: The initialize-time exchange in which client and server declare which optional features (tools, resources, prompts, sampling, roots, elicitation) they support; calls outside the negotiated set must be refused. As of the 2026-07-28 revision, negotiation is evaluated per request rather than fixed for a stateful session's lifetime.
Initialize handshake: The mandatory first exchange of an MCP session: client sends initialize with protocolVersion and capabilities, server responds, client sends the notifications/initialized notification, then normal calls may begin.
Elicitation: A client-side capability added in the MCP 2026-07-28 revision letting a server send a server-initiated request back to the client for additional information from the user mid-interaction — the first MCP primitive that flows from server to client rather than the reverse.
Extensions framework: A formal, opt-in mechanism added in the 2026-07-28 revision for modular, specialized or experimental MCP functionality beyond the core protocol — negotiated at initialize like any capability; Tasks, Skills over MCP and MCP Apps are the notable extensions at launch.
Tasks (MCP extension): An MCP extension introduced 2026-07-28 for asynchronous execution of long-running operations, with polling, mid-flight input and durable handles — addresses cases where a tool call previously had to complete synchronously within a single request-response cycle.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →