Xiaobai
Developer · Builder
Building AI engineering systems, developer tools and long-term digital assets at XBSTACK.
About Xiaobai & XBSTACK →
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.
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, andMcp-Namedo? - 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
- 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.
- MCP Server (Protocol Relay): A lightweight process written by developers that encapsulates the actual logic and exposes a capability manifest.
- Tools & Resources (Underlying Limbs): Concrete code logic, including executable
Tools(e.g., querying a database) and readableResources(e.g., reading file streams).
3. Comparing stdio, Streamable HTTP, and Legacy HTTP+SSE
| Dimension | stdio | Streamable HTTP | legacy HTTP+SSE |
|---|---|---|---|
| Primary use | Local child-process tools | Current remote MCP path | Compatibility with older clients |
| Protocol state | Process stays connected, but 2026 request semantics are self-describing | Stateless request/response; requests can land on different instances | Older long-lived/dual-endpoint design |
| Scaling | Host manages local processes | Works with ordinary load balancing and replicas | More coupled to long-lived connection behavior |
| Security focus | OS user, filesystem, stderr discipline | HTTPS, OAuth, Origin/Host, Tool authorization | Maintain only for compatibility |
| 2026-07-28 status | Supported | Recommended | Deprecated |
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
- Error:
Stdio Stream Pollution- Cause: Your code contains
print()orconsole.log(). These impurities disrupt JSON-RPC communication over Stdio. - Solution: All debug logs must be output via
stderr(Python’ssys.stderror TypeScript’sconsole.error).
- Cause: Your code contains
- Error:
Zombie Process Detected- Cause: After the client exits abnormally, the MCP Server process is not properly terminated.
- Solution: Listen for the
SIGTERMsignal and implement “watchdog” logic. If there is no heartbeat for 5 minutes, executeprocess.exit(0).
- 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.
Recommended In-Depth Reading
- 👉 MCP Server in Practice: A 5-Step Guide with Pitfall Avoidance for Enabling Claude to Access Local SQLite
- 👉 AI Agent Architecture: 5 Core Modules for Building Autonomous Agent Systems
- 👉 LangGraph in Action: 3 Design Patterns for Building Robust AI Agent Workflows
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-Nameheaders
If you encounter bizarre protocol errors while building an MCP Server, feel free to leave a comment so we can discuss.
-
MCP vs Function Calling: Why It’s the USB Interface of the AI Era
-
MCP Server in Action: Enabling Claude to Access Local SQLite
-
Q: How do I handle MCP Tool timeouts? A: First separate proxy/read timeouts, Tool execution timeouts, and long-running Tasks. Increasing one timeout is not a universal fix; long work should use explicit task handles, idempotency, and recovery semantics.
-
Q: How can I ensure local database security? A: Use a read-only account and restrict physical path access via environment variables.
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 →AI Engineering Weekly
Production changes, real failures, experiments and new XBSTACK assets.
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.