MCP version status: an ongoing tracker

The Model Context Protocol (MCP) has evolved at breakneck speed from an experimental Anthropic initiative into the de facto standard for communication between AI models, orchestration engines and external data sources. Where developers previously had to write a custom wrapper for every API, database or local CLI tool, MCP offers a uniform JSON-RPC 2.0 protocol across a range of transport layers. This document serves as an ongoing tracker in which we carefully follow the evolution of the specification, the maturity of official and community SDKs, and the emerging security and architecture patterns.

1. The specification landscape: from 2024-11-05 to the current state

The core MCP specification defines the interaction between a client (such as an AI desktop application, IDE or agentic runtime) and a server (which provides tools, files or contextual data). Since the initial release, the protocol has been structured around three main categories of capability: prompts (predefined templates), resources (passive data such as file contents or database records) and tools (active functions the model can call).

In the current evolution of the specification, the emphasis lies on robust capability negotiation during the handshake phase. At startup, client and server exchange an initialize request and response that explicitly record which protocol features are supported. For a historical overview of the initial adoption and the first wave of community servers, see the extensive analysis of MCP and agent tooling from July 2026 which explains the fundamental shift toward standardized interfaces in detail.

The table below sets out the core capabilities and their current support status in the specification:

2. Transport layers: STDIO versus Streamable HTTP

The Model Context Protocol was deliberately designed as a transport-agnostic protocol. The message structure leans on JSON-RPC 2.0, but the way those messages are physically transmitted varies with the deployment scenario. Two current transport mechanisms are defined (STDIO and Streamable HTTP), each with its own characteristics, advantages and operational trade-offs.

Standard Input/Output (STDIO)

The STDIO transport is the most direct and safest method for local agent setups. The client launches the MCP server process as a child process and communicates over the standard input and output streams. Messages are separated by line breaks (newline-delimited JSON-RPC).

• Advantages: No network ports required, extremely low latency, process isolation through standard OS permissions.
• Drawbacks: Not directly suited to distributed or remote architectures; one process per client session.

Streamable HTTP

For remote scenarios and microservices, MCP uses Streamable HTTP over a single endpoint, which replaces the older HTTP+SSE transport. The client sends JSON-RPC messages using HTTP POST requests, to which the server either responds directly with a JSON body or, for long-running calls, upgrades to an SSE stream. The old two-endpoint model with separate GET connections and session IDs is now deprecated.

The interplay between protocol-based tools and closed plugin systems calls for a clear understanding; read more about Claude skills and plugins in the July overview in which we compare how proprietary extensions relate to open standards.

// Voorbeeld: JSON-RPC 2.0 tool-call request via HTTP POST /message?sessionId=a1b2c3d4
{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "execute_sql_query",
    "arguments": {
      "query": "SELECT id, status FROM deployments WHERE status = 'failed' LIMIT 5;"
    }
  }
}

3. The SDK ecosystem and language support

MCP adoption is driven largely by the availability of official and community-maintained SDKs. Where TypeScript and Python were the only fully-fledged options in the early days, languages such as Go, Rust, Kotlin and C# have now caught up.

Because MCP servers are usually driven by larger orchestration layers, it is worth reading the assessment of agent orchestration frameworks from July 2026 to understand how planning modules call external tools. If you are unsure which overarching framework offers the best support for handling these protocol streams, consult the comparison of agent and LLM frameworks in which MCP support per library is benchmarked clearly.

The status of the various SDK implementations breaks down as follows:

• TypeScript SDK (official): The most mature implementation. Supports browser, Node.js and Bun runtimes alike. Full support for STDIO, SSE and custom transports. Includes strict Zod schema validation.
• Python SDK (official): Built on asyncio and Pydantic v2. Offers both a high-level decorator API for rapid server development and low-level protocol handling. Excellent integration with FastMCP.
• Kotlin / Java SDK (official): Aimed at enterprise integrations and Spring Boot applications. Supports asynchronous reactive streams (Project Reactor / coroutines).
• Rust SDK (community-driven / becoming official): Offers maximum performance and a minimal memory footprint, ideal for running MCP servers on edge hardware or in WASM containers.

4. The security model and capability negotiation

Access to external tools and file resources carries considerable security risk. A malicious or misconfigured MCP server may try to compromise the host environment, while a compromised client can perform unauthorized actions through the server's tools.

The MCP security model rests on four pillars:

1. Explicit capability negotiation: During the initialization phase, both client and server must declare which features they support. A server can, for example, require the client to support the roots capability before granting file access.
2. Human-in-the-loop approval: The specification requires the client application (the UI) to ask the user for explicit permission before sensitive tool executions, such as writing files, running code or modifying infrastructure resources.
3. Transport security and isolation: With STDIO servers, the architecture relies on the OS permission model. With SSE transports, TLS (HTTPS) is mandatory, combined with OAuth2 or API key tokens in the HTTP headers.
4. Sandboxing: Running MCP servers remotely introduces specific vulnerabilities around process isolation; see the guide on agent runtime security from July 2026 to learn how to lock down sandboxing on Linux hosts.

A security rule for developers: Never assume that the input of a tools/call argument is safe by definition, even when it has been validated against the JSON Schema. Sanitize all database queries, shell commands and file paths on the MCP server itself.

5. Schema validation and dynamic resource discovery

One of the most powerful aspects of MCP is the dynamic nature of resources and tools. Instead of statically predefined endpoints, an MCP server can notify the client at any moment that the list of available tools or resources has changed, using the notifications/tools/list_changed or notifications/resources/list_changed methods.

For resources, MCP uses a URI-based addressing model comparable to REST. A server might, for instance, expose the following resources:

• postgres://production-db/tables — Provides an overview of tables as a JSON resource.
• file:///var/log/syslog — Provides real-time log access over text/plain streams.

Tool declarations use the **JSON Schema Draft 7** format. This allows LLM orchestrators to parse parameters precisely. An example of a robust tool declaration in TypeScript looks like this:

// Server-zijde tool declaratie met behulp van de TypeScript SDK
server.tool(
  "calculate_shipping_cost",
  {
    weight_kg: z.number().positive().describe("Gewicht van het pakket in kilogram"),
    destination_country: z.string().length(2).describe("ISO 3166-1 alpha-2 landcode"),
    express: z.boolean().default(false).describe("Kies voor spoedlevering")
  },
  async ({ weight_kg, destination_country, express }) => {
    const cost = await calculateRate(weight_kg, destination_country, express);
    return {
      content: [
        {
          type: "text",
          text: `De berekende verzendkosten bedragen €${cost.toFixed(2)}.`
        }
      ]
    };
  }
);

6. Performance measurement and latency analysis in production

In large-scale agentic workflows, tool execution latency is a critical factor. Every time an agent decides to call an MCP tool, network or process boundaries are crossed. To judge the impact of MCP on total response time, three delay components need to be distinguished:

1. Serialization & deserialization latency: The time needed to encode and decode the JSON-RPC payload. With large payloads (reading big log files through resources, for example) this can run into tens of milliseconds.
2. Transport overhead: STDIO has negligible overhead (< 1 ms). SSE over HTTP/2 or HTTP/3 introduces network RTT (round trip time) and TLS handshake overhead if the connection is not kept persistent.
3. Execution latency: The actual runtime of the underlying task (a database query or API call, for instance).

To capture the error margins and latency of MCP calls in quantitative test sets, we refer you to the guide on evaluating AI agents for a concrete measurement methodology.

7. Known pitfalls and anti-patterns

Rolling out MCP servers in production environments surfaces a number of recurring pitfalls that jeopardize the stability or security of the entire agent stack:

1. Over-exposure of tools (tool bloat)

Offering dozens of small-scale tools to an LLM confuses the model (hallucinated tool calls) and drives up token consumption sharply on every prompt, because all the schemas have to be loaded into the context. Bundle related functionality or use dynamic tool filtering based on the user's current intent.

2. State management on the MCP server

MCP servers should preferably be designed to be **stateless**. When a server depends on internal memory state between successive tool calls, things break as soon as the client restarts or when several instances of the server scale behind a load balancer. Store session state in an external cache (such as Redis) and pass a session token through the tool arguments.

3. A lack of strict schema enforcement

When optional fields are not defined correctly in the JSON Schema, LLMs may pass arbitrary data types. Always use strict schema validators (such as Zod or Pydantic) that reject invalid arguments at the protocol level before the actual business logic is called.

8. Outlook and changelog policy

The Model Context Protocol will continue to evolve over the coming years into a universal connector within AI infrastructure. Key themes on the roadmap include improved support for streaming binary data (such as audio and video streams), fine-grained OAuth scoping per tool, and built-in federated discovery of remote MCP catalogs.

As part of the **radar.llmnet.nl** continuity effort, this page is updated monthly with the latest specification version status, SDK releases and industry best practices. Developers are encouraged to check the changelog regularly for breaking changes in the underlying protocol definition.