What Is MCP? Model Context Protocol, JSON-RPC, AI Agents, and LLM Tool Calling

Up front: MCP (Model Context Protocol) is not another name for Function Calling, and it is not a model. It is an open protocol between an AI app (the Host) and external tool processes (MCP Servers). The messages are JSON-RPC 2.0. The model still speaks each vendor’s Tool Calling / Function Calling. The Host translates tools/list into the model’s tools array, then translates tool_calls into tools/call. Those three layers together are how most 2026 agents invoke tools.

This article is dated 7 September 2026. The current spec is 2026-07-28: no protocol session, no initialize handshake, every request carries _meta, and capability discovery uses server/discover. Our August piece Agent JSON data flow still shows the old initialize example; treat this guide as the current reading. For “do I have to change Server code?”, see the MCP 2026 migration guide.

What MCP is

Model Context Protocol is an open standard for how AI applications discover, read, and invoke external context. Anthropic shipped it in November 2024; governance later moved to the Agentic AI Foundation. It specifies how context is exchanged. It does not specify which model you use, how you orchestrate a multi-step agent, or how you write business logic.

Think USB-C: the socket is standard; whether a disk, a display, or a power supply is plugged in is out of scope. MCP standardizes the Host ↔ Server socket. A filesystem, GitHub, an internal orders API, or a JSON validator like this site are all just Servers.

Two layers: the data layer is JSON-RPC 2.0 (methods, params, error codes, notifications); the transport layer is how those JSON frames move — stdio on the same machine, Streamable HTTP remotely. Swap the transport and the message shape stays. That is why MCP debugging starts by splitting “the envelope is JSON-RPC; the business payload is often JSON too.”

Host, Client, Server

The spec’s triangle is easy to mix up with everyday “client / server” talk:

• Host: the AI app the user opened. It creates Clients, feeds tool schemas to the model, authorizes and validates before execution, and writes results back into the thread.
• Client: one connection object inside the Host. One Server, one Client. VS Code talking to a filesystem and to Sentry is two Clients at runtime.
• Server: the program that serves context. It can share a machine with the Host (stdio) or run elsewhere (Streamable HTTP). “Server” is a role, not a requirement for a public hostname.

The model is not in that triangle. GPT-5.5, Claude 4.8, and Gemini 3.7 see the Host’s translated tools array. They do not see JSON-RPC, and they do not see Mcp-Session-Id (the session header is gone in 2026-07-28). “The model speaks MCP” is marketing. In engineering there is always a Host in the middle.

How to read JSON-RPC 2.0

JSON-RPC is a convention for remote procedure calls using JSON — closer to “call a function” than REST. MCP picked it because method names stay stable (tools/list, tools/call), the request / response / notification split is clean, and the whole envelope is model-friendly JSON.

A tools/call on spec 2026-07-28 looks like this. Note: no handshake, no session header. Version and client identity live in _meta, so any Server instance can handle the frame.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

A success response is the same envelope. The business result sits in result.content, often type: "text", and that text may itself be a JSON string — protocol outside, payload inside. When debugging, match id to the request first, then schema-check the inner object.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Failures use the JSON-RPC error object: code, message, optional data. 2026-07-28 changed “resource not found” from the MCP-specific -32002 to standard -32602 (Invalid Params). Clients that match the old literal will miss it. Notifications have no id and expect no reply — for example a tools-list change.

Tools, Resources, Prompts

A Server may expose three primitives. Agents live on Tools; the other two are easy to skip and often save a round of model guessing.

A tool is name, description, and inputSchema. inputSchema is JSON Schema (2020-12 as of 2026-07-28; the root must still be type: "object"; oneOf / $ref / $defs are allowed). Optional outputSchema constrains the return shape. Hosts almost 1:1 copy inputSchema into the model API’s parameters / input_schema.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources fit “read, then think”: loading schema://order.v1 is cheaper than making the model memorize a 200-line schema in the thread. Prompts fit a team’s canned openers. Roots, Sampling, and Logging are deprecated in 2026-07-28: pass workspace paths as tool arguments or resource URIs; Servers should not ask the Host for a completion; logs go to stderr or OpenTelemetry.

How it stacks with Tool Calling

Three names get flattened into one. They are not the same layer — the Agent JSON data-flow article traces each hop. Here, only the mapping:

Function Calling is OpenAI’s early name; Tool Calling is the later generic term (Claude tools, Gemini Function Calling, OpenAI Tools API). For developers it is one flow: Host sends a schema, the model returns a call with JSON arguments, Host runs it, then stuffs a JSON result back into the thread.

MCP does not replace that layer. A Host that calls in-process functions with Tool Calling only is still valid. MCP makes tools discoverable, cross-process, and reusable across Hosts. Enterprise agents almost always stack both; scripts and demos often skip MCP.

Two mapping traps: model APIs often give arguments as a string; MCP params.arguments is an object. And the name from tools/list must reach the model and tools/call unchanged — do not invent a “friendlier” alias in the middle. Validate before the real tools/call; see Tool Calling and JSON Schema validation.

One complete tool call

The user says: “Validate this order JSON with order.v1.” On 2026-07-28, the path is:

1. Host → Server: server/discover (cacheable) to confirm tools; or send the next request and retry on a version error.
2. Host → Server: tools/list returns items with inputSchema; the result may carry ttlMs / cacheScope.
3. Host → model: map the list to tools[].parameters (still JSON Schema).
4. Model → Host: tool_calls with name validate_json; arguments is often stringified JSON.
5. Host validates: JSON.parse, then check inputSchema. On failure, write the error as a tool result — do not touch the real Server.
6. Host → Server: tools/call with object arguments and protocol version in _meta.
7. Server → Host: result.content; Host may check outputSchema again.
8. Host → model: a role: tool JSON string; the model answers the user or starts another tool turn.

User natural language
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call only after validation
    │
    ▼
result JSON ──► tool message ──► model’s final answer

On remote transport, HTTP headers must include MCP-Protocol-Version, Mcp-Method, and Mcp-Name, and they must match the body or the Server should reject. Load balancers can route on headers without parsing JSON. Local stdio has no those headers; the JSON-RPC method names are the same.

What to remember from 2026-07-28

The July spec is the largest revision since launch, and 28 July 2026 is the final publication date. For “what is MCP,” keep the list below. Whether your Server needs code changes is still the migration article’s decision tree.

• No handshake, no protocol session: initialize / initialized and Mcp-Session-Id are gone. Every request is self-contained. Thread application state with an explicit basket_id (or similar) as a normal argument. Do not expect the transport to remember you.
• Discovery is server/discover: optional, but one call returns supported versions, capabilities, and serverInfo. List results carry ttlMs; a long SSE stream is no longer the only way to learn that tools changed.
• Schemas are JSON Schema 2020-12: input root stays an object; composition and refs are allowed; do not auto-dereference external $ref. Output schemas are no longer object-only.
• Roots / Sampling / Logging are deprecated: methods still work inside the one-year window. New Servers should not implement Sampling to ask the Host for a completion.
• Extensions: Tasks and MCP Apps are official extensions, not core must-haves. Long work uses a task handle + tasks/get. Do not invent your own session.

Hosts and Servers still on 2025-11-25 keep using initialize. When versions mix, use the negotiated protocolVersion. Do not send this article’s sessionless frames to an old Server. For what to install, see 2026 MCP Server rankings.

What to do now

1. Draw three layers before you write code: the model API’s Tool Calling, Host orchestration, MCP Server. Scripts can stop at the first two. Cross-IDE reuse is when you write a Server.
2. Use an official SDK; do not hand-roll JSON-RPC frames: @modelcontextprotocol/sdk and the other official language packs already handle discovery, transport, and error codes. Hand-written SSE or private fields are the usual “you must change code” case in the migration guide.
3. Write inputSchema as a contract you can validate alone: additionalProperties: false, required, enums, length caps. Models omit fields and stringify numbers. Block once with the same schema before execution.
4. stdio locally, Streamable HTTP remotely: personal debugging does not need HTTP. Shared team access, many clients, or a gateway is when you go remote — plus OAuth and least privilege.
5. Cache lists, trim results: honor ttlMs. Do not pour raw stacks back into the model. A bigger window does not make dirty JSON safe — see 1M token context windows.
6. Check fixtures in the browser before you hit a live Server: save inputSchema, good / bad arguments, and sample Server returns as JSON; validate and Diff on this site. Nothing is uploaded. Same habit as testing a REST contract.

FAQ

Takeaways

MCP is the 2026 agent tool socket: JSON-RPC 2.0 moves discovery and invocation between Host and Server; the model side is still Tool Calling; JSON Schema is the shared contract. It is not a model, not a framework, and not a replacement for OpenAPI. Spec 2026-07-28 removed sessions from the protocol, so requests must be self-contained. The three primitives — Tools, Resources, Prompts — did not change.

This guide is only the layering. Byte shapes per hop are in the data-flow article; whether an old Server must change code is in the migration article; which Servers to install is in the ranking article. Before you wire anything live, validate the schema and sample JSON locally — you can swap models; field names and required should not move.