47  Bringing MCP 2026-07-28 to Claude

47.1 Overview

On July 28, 2026, Anthropic announced the release of MCP 2026-07-28 — the fifth major specification release of the Model Context Protocol. The update was the most significant evolution of MCP since its introduction, introducing three major changes that reshaped how agents connected to external tools, data, and services.

By the time of this release, MCP had become one of the most widely adopted open standards in the AI ecosystem. The numbers were staggering: over 400 million monthly SDK downloads (a 4x increase year-over-year), and 950+ MCP servers catalogued in Claude’s connectors directory. MCP had evolved from a promising specification into the de facto standard for agent-to-tool communication.

The 2026-07-28 release addressed three areas that the community and Anthropic had identified as critical for the next phase of MCP’s growth:

  1. Stateless core — simplifying the protocol for serverless and edge deployment.
  2. Standardized extensions — bringing MCP Apps and Tasks under a versioned framework.
  3. Auth hardening — aligning with OAuth 2.0 and OIDC standards.

This chapter covers each of these changes in detail, along with the new capabilities they unlocked.

47.2 The Scale of MCP Adoption

Before diving into the specification changes, the adoption metrics provided important context for why this release mattered:

Metric Value Growth
Monthly SDK downloads 400M+ 4x year-over-year
MCP servers in Claude directory 950+ Rapidly growing
Spec releases to date 5 This is the fifth
Languages with official SDKs 10+ Python, TypeScript, Go, Rust, etc.
Note

The 4x growth in SDK downloads indicated that MCP was not just an Anthropic standard — it was being adopted across the AI industry. Multiple model providers, agent frameworks, and tool builders were building MCP-compatible servers and clients, making it a genuine ecosystem standard rather than a single-vendor protocol.

47.3 Change 1: Stateless Core

47.3.1 The Problem

The original MCP specification assumed a stateful connection between client and server. The client connected to the server, maintained a session, and exchanged messages over that persistent connection. This worked well for traditional server deployments but created challenges for modern infrastructure:

  • Serverless platforms (AWS Lambda, Cloudflare Workers, Google Cloud Functions) are inherently stateless — each invocation is independent, with no persistent connection.
  • Edge deployments benefit from stateless request/response patterns that can be cached and routed efficiently.
  • Load balancing is simpler with stateless protocols — any server instance can handle any request.

The stateful assumption limited where MCP servers could be deployed and how they could scale.

47.3.2 The Solution: Request/Response Model

The 2026-07-28 release introduced a stateless core for MCP — a request/response model that didn’t require a persistent connection:

Stateful (original MCP):
  Client ──── connect ────► Server
     │                        │
     │◄─── session ──────────►│
     │                        │
     │    (persistent         │
     │     connection)        │
     │                        │
  Requires: persistent server process

Stateless (MCP 2026-07-28):
  Client ──── request ──────► Server
     │                        │
     │◄─── response ──────────│
     │                        │
  Connection closed.          │
  Next request is independent.│

  Requires: nothing persistent
  Works with: serverless, edge, CDN
# Stateless MCP server (Python SDK)
from mcp import StatelessMCPServer

server = StatelessMCPServer(name="my-tools")

@server.tool("search")
def search(query: str) -> dict:
    """Each request is independent — no session needed."""
    results = perform_search(query)
    return {"results": results}

@server.resource("data/{id}")
def get_data(id: str) -> dict:
    """Stateless resource access."""
    return load_data(id)

# Deploy as a serverless function
# Each HTTP request is handled independently

47.3.3 Benefits of the Stateless Core

Benefit Explanation
Serverless deployment MCP servers can run on Lambda, Workers, Cloud Functions
Edge deployment MCP servers can run at CDN edge locations for low latency
Horizontal scaling Any server instance can handle any request — no session affinity needed
Simpler load balancing Standard HTTP load balancers work without sticky sessions
Better caching Request/response patterns can be cached at CDN/API gateway level
Tip

The stateless core didn’t eliminate stateful connections — they remained supported for use cases that needed them (streaming, long-running operations, subscriptions). The change made stateless an option, not a requirement. Server authors could choose the model that fit their deployment target.

47.4 Change 2: Standardized Extensions

47.4.1 The Problem

As MCP adoption grew, the community began building extensions to the core protocol — capabilities that went beyond the original tools/resources/prompts model. Two particularly important extensions emerged:

  • MCP Apps: Interactive UI components embedded in conversations.
  • MCP Tasks: Long-running, asynchronous operations.

Initially, these extensions were implemented as ad-hoc, vendor-specific additions. Different implementations had different APIs, different behavior, and different levels of compatibility. This fragmentation threatened the interoperability that made MCP valuable.

47.4.2 The Solution: Versioned Extension Framework

The 2026-07-28 release brought MCP Apps and Tasks under a standardized, versioned extension framework. This meant:

  • A common specification for each extension type.
  • Versioned APIs that could evolve independently of the core protocol.
  • Compatibility guarantees — extensions that declared compliance with a specific version would work with any compliant client.
MCP Specification (2026-07-28)
│
├── Core Protocol (stateless or stateful)
│   ├── Tools
│   ├── Resources
│   ├── Prompts
│   └── Discovery
│
├── Extension: Apps (v1)
│   ├── UI component definitions
│   ├── Interaction model
│   └── Rendering contract
│
├── Extension: Tasks (v1)
│   ├── Long-running operations
│   ├── Status and progress
│   └── Result delivery
│
└── Extension: Auth (v2)
    ├── OAuth 2.0 integration
    └── OIDC alignment

47.4.3 MCP Apps

MCP Apps allowed MCP servers to provide interactive UI components that could be rendered within a conversation. Instead of returning plain text, an MCP server could return a rich, interactive component:

// MCP App: Interactive dashboard component
const dashboardApp = {
  type: "mcp-app",
  version: "1.0",
  component: {
    type: "dashboard",
    widgets: [
      {
        type: "chart",
        data_source: "metrics/cpu_usage",
        chart_type: "line",
        time_range: "1h"
      },
      {
        type: "metric",
        label: "Active Users",
        data_source: "metrics/active_users",
        format: "number"
      },
      {
        type: "alert_list",
        data_source: "alerts/active",
        severity_filter: ["critical", "warning"]
      }
    ]
  },
  interactions: {
    "widget:click": "tool:drill_down",
    "time_range:change": "resource:refresh"
  }
};

When an agent invoked a tool that returned an MCP App, the conversation interface rendered the interactive component rather than plain text. Users could interact with the component (clicking charts, changing time ranges) and those interactions triggered further tool calls — creating a rich, bidirectional experience within the conversation.

Note

MCP Apps were particularly powerful for dashboarding and monitoring use cases. Instead of describing metrics in text (“CPU usage is at 78%”), an MCP server could render an actual chart that the user could interact with — changing time ranges, drilling down into specific metrics, and setting thresholds, all within the conversation.

47.4.4 MCP Tasks

MCP Tasks provided a standardized way for MCP servers to handle long-running, asynchronous operations. Instead of blocking on a request that might take minutes or hours (e.g., processing a large dataset, running a complex analysis), the server could initiate a task and provide status updates:

# MCP Task: Long-running data processing
@mcp.task("process_dataset")
async def process_dataset(dataset_id: str, operations: list):
    # Initiate the task
    task = mcp.tasks.create(
        name=f"Processing dataset {dataset_id}",
        estimated_duration="5-10 minutes",
    )

    # Yield progress updates
    for i, op in enumerate(operations):
        task.update(
            progress=(i / len(operations)),
            message=f"Running {op.name}..."
        )
        await run_operation(dataset_id, op)

    # Complete the task
    task.complete(
        result={"processed_records": 1000000, "duration": "7m32s"}
    )

The task model included:

Concept Description
Task creation Server initiates a task and returns a task ID
Progress updates Server pushes progress notifications
Cancellation Client can cancel an in-progress task
Result delivery Final results delivered when task completes
Webhook callback Optional webhook for completion notification

47.5 Change 3: Auth Hardening

47.5.1 The Problem

Authentication in the original MCP specification was deliberately flexible — it supported multiple auth models but didn’t mandate specific standards. This flexibility led to inconsistency: different MCP servers implemented auth differently, creating integration challenges and security gaps.

Common issues included:

  • Custom auth schemes that didn’t follow industry standards.
  • Inconsistent token handling between servers.
  • Missing security features like token rotation and revocation.
  • Difficult enterprise integration with existing identity providers.

47.5.2 The Solution: OAuth 2.0 and OIDC Alignment

The 2026-07-28 release hardened MCP authentication by aligning with two industry standards:

  1. OAuth 2.0: The standard authorization framework for HTTP APIs.
  2. OpenID Connect (OIDC): The identity layer on top of OAuth 2.0.
# MCP server auth configuration (2026-07-28)
auth:
  version: "2"
  oauth2:
    issuer: "https://login.contoso.com"
    authorization_endpoint: "https://login.contoso.com/oauth2/authorize"
    token_endpoint: "https://login.contoso.com/oauth2/token"
    scopes:
      - "mcp:tools:read"
      - "mcp:tools:execute"
      - "mcp:resources:read"
  oidc:
    enabled: true
    userinfo_endpoint: "https://login.contoso.com/oauth2/userinfo"
    claims:
      user_id: "sub"
      groups: "groups"
      email: "email"

47.5.3 Benefits of Auth Hardening

Benefit Explanation
Standard compliance Follows OAuth 2.0 and OIDC — no custom protocols
Enterprise IdP integration Works with Entra ID, Okta, Auth0, Google, etc.
Consistent security All MCP servers follow the same auth model
Token lifecycle Standard refresh/revocation mechanisms
Scoped access OAuth scopes for fine-grained permissions
Audit trail OIDC claims provide user identity for audit logs
Tip

For enterprises, the OAuth 2.0/OIDC alignment was arguably the most important change in the release. It meant MCP servers could integrate with existing identity infrastructure — no custom auth to build, no special integrations to maintain. The same IdP that managed human access also managed MCP server access.

47.6 Enterprise-Managed Auth: Zero-Touch

Building on the auth hardening, the release introduced enterprise-managed auth for MCP servers — a model where the enterprise’s identity provider managed all MCP server authentication, with zero-touch from end users:

Traditional MCP auth (user-managed):
  User → manually authenticate to each MCP server
  User → manage tokens for each server
  User → handle token refresh

Enterprise-managed auth (zero-touch):
  User → authenticates once (SSO to Claude)
  Claude → uses enterprise OIDC token
  Claude → automatically authenticates to all MCP servers
  User → never sees an auth prompt

This was enabled by:

  1. Enterprise MCP directory: Administrators registered approved MCP servers with their auth configurations.
  2. SSO token exchange: Claude exchanged the user’s SSO token for MCP server tokens automatically.
  3. Centralized policy: Access to MCP servers was governed by enterprise policy, not individual user choice.

47.7 MCP Tunnels: Private Network Access

The release also formalized MCP tunnels (first previewed at Code w/ Claude London, Chapter 44) as part of the standard:

  • Outbound-only connections from private networks.
  • No inbound ports opened on enterprise firewalls.
  • End-to-end encryption between agent and MCP server.
  • Enterprise-controlled: Tunnel clients are deployed and managed by the enterprise.

This brought the private network access capability from research preview into the standardized specification, ensuring interoperability across implementations.

47.8 Migration and Compatibility

Anthropic was careful to ensure backward compatibility with existing MCP servers and clients:

Aspect Compatibility
Existing MCP servers Continue to work unchanged
Stateful connections Still fully supported
Old auth methods Deprecated but functional
New features Opt-in — servers can adopt incrementally 
# Gradual migration: server supports both old and new
@mcp_server.tool("search")
def search(query, auth=None):
    # auth can be legacy API key OR OAuth 2.0 token
    if auth and auth.type == "oauth2":
        user = validate_oauth_token(auth.token)
    elif auth and auth.type == "api_key":
        user = validate_api_key(auth.key)
    else:
        raise AuthRequired()

    return perform_search(query, user=user)
Note

The backward compatibility commitment was essential given MCP’s massive installed base. With 950+ servers and 400M+ monthly downloads, breaking changes would have been catastrophic. The 2026-07-28 release added capabilities without removing existing ones — servers could adopt new features at their own pace.

47.9 The MCP Ecosystem at a Glance

By the time of the 2026-07-28 release, the MCP ecosystem had grown dramatically:

Category Examples
Databases PostgreSQL, MySQL, MongoDB, Redis, DynamoDB
Developer tools GitHub, GitLab, Jira, Linear, Slack
Cloud platforms AWS, Google Cloud, Azure
Productivity Notion, Confluence, Google Workspace, Microsoft 365
Monitoring Datadog, Grafana, PagerDuty, New Relic
Data platforms Snowflake, BigQuery, Databricks
Custom enterprise Internal APIs, legacy systems, proprietary tools

The diversity of available MCP servers meant that agents could connect to virtually any system an enterprise used — and the 2026-07-28 spec made those connections more secure, more scalable, and more capable.

47.10 Key Takeaways

  • MCP 2026-07-28 is the fifth major specification release, reflecting the protocol’s rapid evolution and massive adoption.
  • 400M+ monthly SDK downloads (4x growth) and 950+ MCP servers demonstrate that MCP has become the de facto standard for agent-to-tool communication.
  • Three major changes define this release: stateless core, standardized extensions, and auth hardening.
  • Stateless core enables serverless and edge deployment — MCP servers can now run on Lambda, Cloudflare Workers, and other serverless platforms using a simple request/response model.
  • Standardized extensions bring MCP Apps and Tasks under a versioned framework — ending fragmentation and ensuring interoperability across implementations.
  • MCP Apps provide interactive UI components in conversations — dashboards, charts, and interactive elements rendered natively, not as text.
  • MCP Tasks standardize long-running asynchronous operations — with progress updates, cancellation, and webhook callbacks.
  • Auth hardening aligns with OAuth 2.0 and OIDC — ending custom auth schemes and enabling seamless enterprise IdP integration.
  • Enterprise-managed auth provides zero-touch authentication — users never see auth prompts; the enterprise IdP handles everything transparently.
  • MCP tunnels are formalized in the spec — outbound-only private network access, bringing the London preview into the standard.
  • Full backward compatibility — existing servers and clients continue to work; new features are opt-in and incremental.
  • The MCP ecosystem spans databases, developer tools, cloud platforms, and custom enterprise systems — agents can connect to virtually any system through standardized, secure MCP servers.