Learn MCP - Modern Features & Roadmap

#Introduction

In episode 20 you saw MCP working in the real ecosystem. Now it's time to see one spec version in its entirety. Episode 21 is a comprehensive tour of the 2026-07-28 spec — the major release that defines the modern era — from the headline stateless core, server/discover, MRTR, and routable headers, to formal deprecations, structured output, MCP Apps and MCP Tasks as official extensions, plus the roadmap and the SDK map across all languages.

#Stateless Protocol Core

The biggest headline of the 2026-07-28 spec is the stateless protocol core — as you learned in episode 3. The initialize handshake and Mcp-Session-Id were removed. Protocol version, identity, and capabilities are sent per request, not stored in a session. The architectural consequences: requests can be routed to any server, load balancers run round-robin without sticky sessions, and horizontal scaling becomes trivial.

#server/discover and Routable Headers

The handshake replacement is the server/discover method — a single call to learn a server's version, identity, and capabilities, without storing any session.

{
  "jsonrpc": "2.0",
  "id": "d-1",
  "method": "server/discover"
}

{
  "jsonrpc": "2.0",
  "id": "d-1",
  "result": {
    "protocolVersion": "2026-07-28",
    "serverInfo": { "name": "billing", "version": "2.4.0" },
    "capabilities": { "tools": {}, "resources": {} }
  }
}

For routing between servers, the spec provides the routable Mcp-Routing-Id header. This header carries the request's destination, so a gateway can direct requests without storing sessions — exactly what's needed for many servers behind one gateway, as covered in episode 16.

#MRTR: Mid-Call Interaction

The Multi-Round-Trip Request you know from episode 8 is now a mature part of the core spec. Requests use messageId and routingId; the server can request confirmation or authorization step-up mid-execution, the client replies, then the server continues. This replaces the reliance on long SSE streams and becomes the foundation of safe interactive patterns.

#Authorization Hardening

Authorization in the modern era is tightened. Combining the lessons from episode 10: the Mcp-Authorization header, tokens bound to the authorization server, and scope accumulation for step-up auth. An often-missed advantage: because identity is carried per request, tokens can be revoked without closing the connection — control that was impossible in the long-session era.

#Formal Deprecation and Removal Clock

Roots, Sampling, and Logging are officially listed as deprecated features with a removal clock of about one year. They still work in the dual era (episode 17), but without a future guarantee. The errors marking them are now standardized via ISO-JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": "d-1",
  "error": {
    "code": -32601,
    "message": "Method not found",
    "data": {
      "type": "protocol_error",
      "hint": "logging dihapus di era modern"
    }
  }
}

For those of you building servers: plan the migration now, not when the removal clock runs out.

#Tool Schemas and Structured Output

The new spec strengthens the contract between model and tool. tools/list can now carry an outputSchema, so the model knows the output shape before calling — the result is fewer retries and fewer tokens wasted on trial and error.

{
  "name": "send_payment",
  "description": "Mengirim pembayaran mikro",
  "outputSchema": {
    "type": "object",
    "properties": {
      "status": { "type": "string" },
      "transactionId": { "type": "string" }
    },
    "required": ["status", "transactionId"]
  }
}

This completes the existing inputSchema: input and output are both structured, and the model doesn't have to guess the shape of the answer.

#MCP Apps and MCP Tasks: Official Extensions

MCP Apps (episode 11) and MCP Tasks (episode 12) officially moved from the core spec to official extensions. Apps lets tools return interactive UIs rendered by the host in a sandboxed iframe; Tasks handles long-running work with tasks/get, tasks/update, and tasks/cancel. This move isn't a downgrade — it's a healthy policy: the core spec stays stable and lean, while new features grow quickly outside the core.

#Roadmap: After Stateless

Where does MCP go after stateless? Several themes visible on the roadmap:

• Extensibility — formalizing an extension framework so third parties can add capabilities without changing the core.
• Multi-hop routing — requests passing through several servers and gateways with Mcp-Routing-Id, not just a single hop.
• Further extension formalization — Apps and Tasks maturing, with new extensions likely to follow.
• Error standardization — ISO-JSON-RPC spreading consistently across all SDKs.

The direction is consistent with the philosophy you've seen since episode 1: a protocol that stays lean, but is open to extension.

#SDKs in Various Languages

Official SDKs are now available in six languages: TypeScript, Python, C#, Kotlin, Java, and Go. Each adopts the spec according to its era, with the same transport, client, and server principles. Installation is simple — bun add @modelcontextprotocol/sdk for TypeScript and pip install mcp for Python.

bun add @modelcontextprotocol/sdk

pip install mcp

When choosing an SDK, check which spec version it supports — the dual-era compatibility from episode 17 is still relevant for interoperability.

#Conclusion

Episode 21 summarized the 2026-07-28 spec in full: the stateless core that changed the architecture, server/discover and the Mcp-Routing-Id header for routing, MRTR for mid-call interaction, authorization hardening, formal deprecation with removal clocks, structured output, MCP Apps and MCP Tasks as official extensions, the extensibility roadmap, and the six-language SDKs.

Key takeaways:

• The stateless core means identity and capabilities are sent per request — scaling without sticky sessions.
• server/discover replaces the handshake, and Mcp-Routing-Id enables multi-server routing.
• MRTR and authorization hardening create safe, bounded interactive flows.
• Roots, Sampling, and Logging have a removal clock — migration must be planned from now.
• MCP Apps and Tasks are officially extensions; the core spec stays lean.

Episode 22 is the final episode of this series. There we compare MCP with A2A and AG-UI/AGNTCY, discuss when to choose MCP, and close with a complete production checklist and reflections on the whole journey. See you there!