Back to blog
This site is an independent third-party technical services platform offering aggregated access to multiple model APIs. It is not affiliated with, authorized by, or partnered with Anthropic, OpenAI, Google, or any other model provider.
Key Takeaways
- The MCP 2026-07-28 specification has been released. According to the release notes, it is the largest update since the protocol was created.
- The protocol layer is now stateless. Remote MCP servers no longer need to maintain session state, significantly increasing deployment and scaling flexibility.
- Extensions are now a first-class feature. There is an official path for adding capabilities to the protocol. Initial examples include MCP Apps, Tasks, and enterprise-managed authentication.
- Authentication has been strengthened, alongside a formal deprecation policy. MCP now has clearer rules for version evolution, making long-term integrations more predictable.
- For developers, the practical impact is that MCP servers can be operated like ordinary stateless HTTP services. The tool layer is further decoupled from the model layer, making it more realistic to reuse one toolset across multiple model providers.
A Closer Look
Statelessness: The Most Practical Change
Under the previous design, running a remote MCP server meant maintaining session state for clients. This was not inherently difficult, but it constrained deployment options: requests had to return to the process holding the relevant session. That made Serverless deployments and edge infrastructure difficult, while horizontal scaling behind a load balancer required sticky sessions.
Many teams ultimately had to run a permanently available instance and operate it as a stateful service.
Once state is removed from the protocol layer, the deployment model becomes much more flexible:
- MCP servers can run on Serverless and edge infrastructure, making cold starts and pay-as-you-go scaling practical.
- They can scale horizontally behind any load balancer without requiring requests to remain attached to the same instance.
- Canary releases, rolling deployments, and multi-region active-active setups can follow the same practices already used for stateless HTTP services.
In other words, an MCP server changes from “a long-lived service that requires careful handling” back into “an ordinary API service.” The impact on operational cost may be greater than that of any individual new feature.
Extensions: Adding Capabilities Without Waiting for the Main Specification
Previously, adding a capability to MCP involved an awkward choice: wait for the main specification to adopt it, or add private fields that could undermine interoperability between implementations.
This version makes Extensions a first-class feature and provides an official path for extending the protocol. The release notes highlight three example directions:
1. MCP Apps — Server-rendered UIs running inside sandboxed iframes. Tool responses no longer have to be limited to text or JSON; they can include interactive interfaces. Forms, result confirmation, and data tables no longer need to be forced into a conversational flow. The sandbox boundary also establishes a security foundation for server-provided UI.
2. Tasks — Long-running and asynchronous operations. This is one of the most common pain points in real-world engineering: running a large batch process, waiting for external approval, or invoking a pipeline that takes several minutes to complete.
Previously, developers had to build their own workaround inside each tool—for example, returning a job ID and having the model poll for updates. With a standardized protocol-level representation, clients can handle progress, cancellation, and result collection consistently.
3. Enterprise Managed Auth — Centralized access control for MCP servers through an organization’s own identity provider. For organizations that already have an IdP, this feature may determine whether MCP can enter production: who can connect to which server, how permissions are revoked, and where audit records are stored can all be managed through the existing identity system instead of being scattered across individual client configurations.
Stronger Authentication and a Deprecation Policy
This release also strengthens authentication and introduces a formal deprecation policy.
The latter may sound less exciting, but it is highly valuable for teams building long-term integrations. Once there are written rules for retiring old fields, defining transition periods, and marking deprecated features, teams can confidently build MCP into core workflows instead of performing a compatibility audit every time the protocol changes.
What This Means for Developers
First, the deployment barrier for MCP servers is lower. Previously, launching a remote MCP server required answering the question, “Where should session state live?” In most cases, that question no longer applies. Individual developers can deploy nearly zero-cost services with Serverless infrastructure, while teams can reuse their existing Kubernetes or edge deployment processes.
Second, the tool layer and model layer are becoming more decoupled. MCP’s core value has always been that one tool can be written once and reused by multiple clients and models. Statelessness makes the server easier to scale horizontally, while extensions allow developers to expand the protocol’s capabilities independently. Together, these changes make “one toolset connected to multiple models” a more convenient engineering choice, not merely a design principle.
Third, asynchronous capabilities deserve another architectural review. If you previously broke long-running tasks into many small steps because tool calls had to return within a few dozen seconds, the arrival of the Tasks extension may justify redesigning that workflow.
Fourth, the main obstacles to enterprise adoption are gradually being removed. Centralized authentication and a clear deprecation policy are typically among the first questions raised during security and architecture reviews.
Using It with Code0
MCP addresses “how models use tools,” while Code0 addresses “how you connect to different model providers through one interface.” The two operate at complementary layers.
Once the tool layer has been abstracted through MCP, switching the model is simply a matter of changing the model field:
from openai import OpenAI
client = OpenAI(
base_url="https://hk.code0.ai/v1",
api_key="sk-your-key", # Get your key from console.code0.ai
)
resp = client.chat.completions.create(
model="claude-opus-4-8", # Switch to gpt-5.4, gemini-3-pro, deepseek-v3, etc.
messages=[
{
"role": "user",
"content": "Use the tools to check this week's build failure records.",
}
],
)
print(resp.choices[0].message.content)
For Claude-specific workflows, you can also use the Anthropic SDK style:
from anthropic import Anthropic
client = Anthropic(
base_url="https://hk.code0.ai",
api_key="sk-your-key",
)
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello"}],
)
print(resp.content[0].text)
One possible architecture is to build MCP servers as a stateless tool layer while routing all agent model calls through Code0.
This means your tools do not need separate adapters for each model provider. Models can also be routed by task type: use Claude Opus for demanding reasoning, a more cost-effective model for long-context summarization, and compare several providers during evaluation before making a final choice.
Available models and billing rules are subject to the information shown in the console.code0.ai dashboard.
Claude™ and Anthropic® are trademarks of Anthropic, PBC. Related information is based on Anthropic’s public documentation and release notes.
Conclusion
The significance of this MCP release is not a collection of flashy new features. It is that the protocol has taken a major step toward production-grade usability:
- Statelessness improves deployment flexibility.
- Extensions provide a path for capability evolution.
- Stronger authentication and a deprecation policy improve long-term predictability.
The recommended next steps are straightforward: read the release notes to confirm whether your client or SDK version supports the new specification, then assess whether your existing MCP servers can remove session dependencies and move to stateless deployment.
On the model side, maintain a unified access layer. That way, regardless of how the protocol or model landscape changes, most future modifications can remain concentrated in one place.
To get started, register through the Code0 console and obtain an API key.
