MCP Protocol Evolution: Stateless Sessions, MRTR & Tasks Explained

Overview

The Model Context Protocol (MCP) has released a new specification addressing earlier criticism that "MCP is dead" after some companies abandoned it for API or CLI integrations. The article argues MCP remains the most important and universal way for agents to connect to external systems. The new spec drops obscure features and incorporates community feedback, especially from enterprise scenarios, with three key changes.

1. Sessions: Protocol-Level Statelessness

Old Version: Stateful Interaction via Session ID

Previously, Streamable HTTP required a stateful handshake: client sends initialize, server responds with Mcp-Session-Id, client confirms initialized. Subsequent requests carried this session ID to correlate context across multiple HTTP connections.

New Version: Fully Stateless Requests

The new protocol makes client-server interaction completely stateless. Mcp-Session-Id is removed, and the initialize handshake is eliminated. Instead, each request carries protocol version and capabilities in a _meta field. The author notes: "Now calling an MCP tool is as simple as calling a RESTful API." However, protocol-level statelessness does not prevent server-side shared state.

Benefits and Costs

Benefits: Simplifies session management. Scaling, load balancing, and instance switching no longer require session synchronization or sticky routing.

Costs: Repeated metadata (version, capabilities) on every request. Stateful concerns (cross-request context, access control, idempotency) must be implemented manually.

Implementing State Manually

The server stores necessary business context (e.g., business data, rules) in a database or cache, returns a business handle (ID). The client includes this handle in subsequent tool parameters. This handle correlates a specific business work item, not the entire client-server session. Example: CRM assistant calls create_review → instance A saves data, returns reviewId → later update_review with same reviewId hits instance B, which retrieves prior state via the ID.

2. MRTR: Multi-Round-Trip Requests

Problem

When an MCP tool execution needs additional information mid-way (e.g., user choice, security approval), how to supplement and continue?

Old Version: Server-Initiated Elicitation

Server sent elicitation/create request; client displayed form, returned user response. Both client and server had to maintain the original tool execution context while waiting, effectively blocking the response stream.

New Version: MRTR (Multi Round-Trip Requests)

MRTR turns "need more input" into a formal intermediate result, ending the current tool request. The client's reply becomes a new request.

First request: Server returns resultType: input_required with inputRequests listing needed info.

Client assembles inputResponses matching original keys; if server provided requestState (intermediate state), client echoes it back.

Second request: Client sends original parameters + inputResponses + requestState. Server resumes, returns complete or another input_required for further rounds.

Analogy: Counter clerk gives you a supplement slip and a receipt; you return later with receipt and documents, clerk resumes from receipt.

Benefits and Costs

Benefits: Each round is an independent request. Client can finish the round, wait for user input, then continue. Server need not hold the response stream.

Costs: Both sides must implement resumption logic. Client must understand input_required; server must restore request context, validate requestState integrity/expiry, and handle duplicate submissions.

Intermediate State: requestState

Server returns requestState (the "receipt") to client; client returns it unchanged next round. Server validates completeness, expiry, then restores context.

3. Tasks: Long-Running Backend Work

Tasks is an official extension for server-side long-running tasks (e.g., 10-minute data analysis). Typical challenges: async execution (no client blocking), result retrieval, status monitoring, cancellation.

Execution Flow

Client calls MCP tool; server decides to handle as Task.

Server returns resultType: task with taskId, status, timestamp — task accepted.

Client saves taskId, polls via tasks/get for status; on completed, retrieves final result from query response.

Task Features

Supplemental input: Via tasks/update if input_required signaled.

Cancellation: tasks/cancel for cooperative cancellation — not guaranteed immediate stop, no auto-rollback of written data.

Completion vs. success: completed means task finished; isError flag indicates business failure; failed means system-level error (task didn't complete).

Subscription for Real-Time Status

Instead of polling tasks/get, client subscribes to task notifications. Server pushes full task snapshots (same as tasks/get response) on state changes. On completed, notification includes final result; on input_required, client can immediately tasks/update.

Trade-offs

Client avoids blocking; server handles queueing, persistence, fault recovery, idempotency (often via SDK). Tasks embody "protocol stateless, but task can have state" — simplifying protocol while retaining special capabilities via extension.

MCP Tasks vs. A2A: Both Have Tasks, What's the Difference?

MCP Tasks: Extend a Single Tool Call

MCP Tools revolve around name/description, input parameters, return result. Tasks add task ID, status query, cancellation. Entire interaction still centers on one tool call; final result maps to original tool invocation. Behind the tool can be a fully autonomous agent (multiple models, workflows, self-check), but caller only sees the tool's interface. Example: "Order Analysis Agent" wrapped as MCP Tool — Tasks let it run longer, but no cross-task context or artifact linking conventions.

A2A: Tasks Within Continuous Agent Dialogue

A2A targets agent-to-agent interoperability. Caller reads Agent Card (capabilities/access), sends message expressing need; receiver may reply directly or create a persistent Task. Core objects: Message (express task, add conditions, reply), Task (track specific work), contextId (link related messages and multiple tasks), Artifact (deliverables: reports, files).

Example: Sales Assistant Agent → Order Analysis Agent: "Analyze last month's order anomalies, give handling suggestions." Agent delivers report. User follows up: "For East China issues, add customer follow-up list." A2A links this follow-up under same contextId, references prior task, creates new task.

Comparison Table

Work entry: MCP = call tool; A2A = send message to agent.

Task role: MCP = continuous execution within tool call; A2A = work created after receiving message.

Supplemental input: MCP = tasks/update per task requirements; A2A = continue dialogue via messages linked to task/context.

Final output: MCP = tool call result; A2A = Artifact objects.

Multi-task linking: MCP = tool stateless, self-design linking; A2A = contextId links multiple tasks.

Status observation: MCP = tasks/get polling or subscription; A2A = streaming events for task/artifact updates, webhook push.

Summary Comparison

MCP Tasks: simpler protocol and usage, but complex collaboration must be self-implemented.

A2A: designed for agent interoperability, supports richer multi-turn interaction and collaboration mechanisms.

MCP integrates more easily; nearly all agents support MCP today.

Recommendations

Prefer MCP + Tasks when MCP already integrated and needs map to clear tools (capability/input/output boundaries). Examples: report generation, data validation, long statistical analysis. Responsibility, input, output boundaries clear; no complex back-and-forth needed (even if backend runs complex agent).

Consider A2A when exposing independent agents to external systems for continuous collaboration with complex deliverables. Example: Procurement Agent ↔ Supplier Agent multi-round negotiation on delivery, alternatives, pricing, linked to multiple tasks and artifacts. A2A reduces interface negotiation overhead (messages, context, artifacts).

MCP Tasks and A2A Can Cooperate

Same system can use both: external A2A for receiving goals, negotiating conditions, delivering results; internal MCP for calling CRM, inventory, document capabilities, with long-running tools using Tasks. Example: Sales Assistant ↔ Order Analysis Agent collaboration via A2A; Order Analysis Agent uses MCP+Tasks to call CRM services — no conflict.

Conclusion

The three changes — stateless requests simplifying deployment, MRTR enabling multi-turn input, Tasks extending long-running backend work — align closely with enterprise agent system needs: connecting disparate systems, reusing business capabilities, reducing duplicate integration, executing long complex tasks. Official roadmap plans further task interaction improvements and progressive tool discovery. MCP continues absorbing community feedback and evolving around real application demands; as enterprise agent systems accelerate, MCP will remain an indispensable connection layer.