Xiaobai

Xiaobai

Developer · Builder

Building AI engineering systems, developer tools and long-term digital assets at XBSTACK.

About Xiaobai & XBSTACK →
MCP Protocol Boundaries: How to Layer Client, Server, Tools, and Resources: MODEL CONTEXT PROTOCOL article cover

MCP 2026-07-28 Protocol Boundaries: Stateless Core, Streamable HTTP, MRTR

MCP 2026-07-28 protocol boundaries: stateless requests, server/discover, Streamable HTTP, MRTR, Tasks, and migration from protocol sessions and legacy HTTP+SSE.

Published · 2026-04-246 min readXBSTACK
#MCP#JSON-RPC#AI Agent#Developer Tools#Architecture Design

Article Positioning: MCP 2026-07-28 Protocol Layers and Boundaries

This article focuses on the protocol boundaries of MCP: what Client, Server, Tools, Resources, Prompts, stdio, Streamable HTTP, MRTR, and Tasks are responsible for, and why the 2026-07-28 core no longer depends on protocol sessions. For a concrete server walkthrough, see MCP Server SQLite Private Data Mounting; for deployment, see MCP Streamable HTTP in Practice; for authorization, see MCP OAuth Authentication.

Direct answer: the defining change in MCP 2026-07-28 is a stateless request/response core. The initialize / notifications/initialized handshake and protocol-level Mcp-Session-Id are gone from the current core. Every request identifies its protocol version and client capabilities; servers implement server/discover for optional up-front discovery. Streamable HTTP is the modern remote transport, while legacy HTTP+SSE, Roots, Sampling, and Logging are on a formal deprecation path.

Protocol Boundary Review Checklist

After reading this article, you should at least be able to distinguish:

  • The Client initiates self-describing protocol requests, advertises capabilities, and handles MRTR input without replacing server-side business authorization.
  • The Server is responsible for exposing resource and tool manifests, and must enforce permission controls, timeouts, and logging governance.
  • Resources lean toward read-only context, while Tools may produce side effects, meaning they carry different security levels.
  • stdio suits local process boundaries; remote deployments should use Streamable HTTP plus an explicit authentication and authorization layer.
  • Protocol statelessness does not make your application stateless; approvals, long jobs, carts, uploads, and cursors need explicit business IDs or handles.
  • MCP is not a universal plugin marketplace; its true value lies in standardization, auditability, and governability.

The Key Point: MCP Defines the Protocol Boundary for AI Calling Local Tools

The value of MCP is not “allowing models to arbitrarily operate on the local machine,” but rather encapsulating local tools, files, databases, and remote services into a discoverable, permission-scoped, and auditable capability manifest. It is well-suited for private database mounting, internal enterprise toolchain integration, and automated code refactoring, but requires pre-designed permissions, logging, timeouts, and isolation boundaries.

  • Suitable Scenarios: Local private database mounting, enterprise-grade internal toolchain integration, automated code refactoring workflows.

What This Guide Covers in the 2026-07-28 Protocol

  • Why did MCP move to a stateless core?
  • What do server/discover, Mcp-Method, and Mcp-Name do?
  • How should you choose between stdio, Streamable HTTP, and legacy HTTP+SSE?
  • How does MRTR replace long-lived server-initiated request flows?
  • When should a workflow use the Tasks extension instead of a synchronous Tool Call?
  • What should replace deprecated Roots, Sampling, and Logging in new implementations?

Who This Guide Is For

  • AI Application Developers: Looking to add powerful local extension capabilities to their applications.
  • Full-Stack Engineers: Want to master the most mainstream AI plugin development standards of 2026.
  • System Architects: Designing the underlying connection protocols for enterprise-grade AI agent platforms.

1. Xiaobai’s Note

There is always a thin layer of mist over Guiyang in the early mornings. Sitting in my “Local Development Environment” studio, I watched Cursor on my screen frantically conversing with my local database via the MCP (Model Context Protocol). I couldn’t help but sigh: In 2026, if you still don’t understand MCP, your collaboration efficiency with AI might still be stuck in the Stone Age. If Agents are the “command center” I build, then MCP is the “USB-C port” of this system. It not only unifies the communication protocol between AI and the external world but also thoroughly breaks down “local data silos.” Today, I will take a practical perspective to deconstruct this underlying protocol that is reshaping the AI ecosystem.

1. MCP: The Underlying Physical Standard for Breaking Data Silos in the AI Era

In the past, AI was like a genius locked in a glass room. If you wanted it to glance at your local financial spreadsheets, you had to manually copy and paste or write an extremely fragile, specific plugin. Now, with MCP, you simply install a standardized “drawer” on the glass room. When AI needs something, it directly requests it through the drawer (protocol request), and you place the data inside (protocol response).

MCP provides a JSON-RPC protocol between hosts/clients and capability servers. In 2026-07-28, capability discovery and routing no longer depend on a persistent protocol session: each request carries the protocol version and client metadata, and server/discover is available when a client wants capabilities up front.

2. MCP Client, Server, Tools

  1. MCP Client (Brain Container): The protocol initiator, such as Cursor or Claude Desktop. It is responsible for maintaining context and deciding when to trigger calls.
  2. MCP Server (Protocol Relay): A lightweight process written by developers that encapsulates the actual logic and exposes a capability manifest.
  3. Tools & Resources (Underlying Limbs): Concrete code logic, including executable Tools (e.g., querying a database) and readable Resources (e.g., reading file streams).

3. Comparing stdio, Streamable HTTP, and Legacy HTTP+SSE

DimensionstdioStreamable HTTPlegacy HTTP+SSE
Primary useLocal child-process toolsCurrent remote MCP pathCompatibility with older clients
Protocol stateProcess stays connected, but 2026 request semantics are self-describingStateless request/response; requests can land on different instancesOlder long-lived/dual-endpoint design
ScalingHost manages local processesWorks with ordinary load balancing and replicasMore coupled to long-lived connection behavior
Security focusOS user, filesystem, stderr disciplineHTTPS, OAuth, Origin/Host, Tool authorizationMaintain only for compatibility
2026-07-28 statusSupportedRecommendedDeprecated

Streamable HTTP is not merely “SSE on a different URL.” The 2026-07-28 protocol also removes the core handshake, protocol sessions, and SSE resumability/message redelivery. If a response stream breaks, the client reissues the unfinished operation as a new request with a new request ID; business idempotency remains an application responsibility.

4. MRTR and Tasks: Stateless Does Not Mean Single-Step

Multi Round-Trip Requests (MRTR) replace the old assumption that a server must open a reverse request toward the client for sampling, elicitation, or other input. A server can return resultType: "input_required" with inputRequests; the client gathers input and retries the original request with inputResponses.

Long-running work lives in the io.modelcontextprotocol/tasks extension. Task handles, tasks/get, and tasks/update provide protocol-level lifecycle mechanics, while external side effects such as payments, deployment, or email still need application-level idempotency and reconciliation.

5. Roots, Sampling, and Logging Are Deprecated for New Implementations

MCP 2026-07-28 marks Roots, Sampling, and Logging as deprecated with a migration window of at least twelve months. The official direction is to pass directories/files through tool arguments, resource URIs, or server configuration; integrate directly with model providers instead of Sampling; and use stderr for stdio or OpenTelemetry for logging.

Do not confuse deprecated MCP Roots with a server-enforced allowedRoots filesystem policy. Roots are informational and never guaranteed access control. A server-side realpath-aware allowlist plus identity and operation checks remains a valid application security boundary.

Practical Pitfalls and Error Logs Guide

  1. Error: Stdio Stream Pollution
    • Cause: Your code contains print() or console.log(). These impurities disrupt JSON-RPC communication over Stdio.
    • Solution: All debug logs must be output via stderr (Python’s sys.stderr or TypeScript’s console.error).
  2. Error: Zombie Process Detected
    • Cause: After the client exits abnormally, the MCP Server process is not properly terminated.
    • Solution: Listen for the SIGTERM signal and implement “watchdog” logic. If there is no heartbeat for 5 minutes, execute process.exit(0).
  3. Error: JSON-RPC Buffer Overflow
    • Cause: Attempting to return multi-megabyte files via Resources, which overwhelms the Stdio buffer.
    • Solution: Never return large files through MCP. Instead, extract summaries or use chunked retrieval (RAG).

7. Frequently Asked Questions

Q: Why can’t my Cursor recognize the newly added Tool?

A: Click the Refresh button in the Cursor MCP configuration interface. If it still fails, check whether your function has proper Docstrings. AI models rely heavily on comments to understand tool intent.

Q: How do I secure MCP connections to remote servers?

A: A tunnel only creates a network path; it does not provide complete authorization. Use Streamable HTTP over HTTPS and implement the current MCP authorization model, including Protected Resource Metadata, Resource Indicators, issuer validation, and Tool-level authorization. See MCP OAuth Authentication.

I’ve been diving deep into:

  • The performance of the MCP protocol within large-scale distributed Agent clusters
  • A unified workflow standard for cross-IDE environments (Cursor, Zed, VSCode) based on MCP
  • Streamable HTTP gateways that authorize and route with Mcp-Method / Mcp-Name headers

If you encounter bizarre protocol errors while building an MCP Server, feel free to leave a comment so we can discuss.

Topic path / MCP

Continue from protocol details to production MCP governance

The MCP hub connects protocol fundamentals, transports, authentication, security, JSON-RPC debugging and production deployment without splitting the search intent across isolated guides.

More to Explore

Topic hub →
How to Configure MCP, Function Calling, and API Gateway: A Three-Layer Architecture for AI Agent Tool IntegrationMCP, Function Calling, and API Gateway solve different layers of AI tool integration: model tool selection, reusable tool/context protocol, and production access control.MCP vs. Semantic Kernel: Protocol, Agent Orchestration, and Enterprise Project SelectionMCP vs Semantic Kernel: compare protocol interoperability for tools/resources/prompts with an SDK for plugins, function calling, agents, and orchestration.MCP -32700 Parse Error: stdout Pollution, Tool List Failed, and Version ChecksFix MCP -32700 Parse Error by separating stdout/stderr, malformed JSON, startup failures, SDK v2 migration, and legacy 2025 versus stateless 2026-07-28 lifecycle issues.MCP StreamableHTTPClientTransport POST Stays Pending After SSE Disconnect: Issue #2739 ReproducedA v1 MCP StreamableHTTPClientTransport POST can remain pending until request timeout after request-scoped SSE error/EOF. XBSTACK reproduced Issue #2739 on SDK 1.29.0 and 1.30.0.

AI Engineering Weekly

Production changes, real failures, experiments and new XBSTACK assets.

Comments & evidence

DISCUSSION

Questions, verification and corrections

Sign in to comment. Every new comment is reviewed before publication; while pending, it is visible only to you and the administrator.

Sign-in required Reviewed before public
Loading the discussion…