MCP's 2026 spec changes what your tools can do

The MCP Release Candidate is out, and the final spec drops July 28, 2026. If you're building CX agents on any platform that uses the Model Context Protocol, four changes in this update will affect how you design tools, handle long operations, render results, and secure your token flow.

This article walks through each one: what it is, why it exists, and what you need to do before the final lands.

Why the spec needed an update

MCP 1.x solved the fragmentation problem. Before it existed, every AI provider had its own function-calling format, and building an agent that worked with more than one model meant writing adapter code for each pairing. We covered exactly this in Why MCP Exists: Tool Calling Shouldn't Need Adapter Code. With 97 million monthly SDK downloads and more than 10,000 servers indexed, the protocol worked. But adoption at that scale exposed gaps.

Three of those gaps were structural. First, there was no sanctioned way to add new capabilities without breaking clients that hadn't updated. Teams worked around this by stuffing features into an experimental field, which created undocumented coupling between specific server and client versions. Second, tool calls are synchronous. Call a tool, wait for the result, continue. Fine for a CRM lookup that takes 200ms. Broken for a test simulation that takes 45 seconds. Third, OAuth was advisory: the spec said you should protect your server, but didn't specify how, and the gap produced a class of token forwarding vulnerabilities in multi-server deployments.

The 2026 RC addresses all three, plus adds one new capability that changes what kind of UIs an MCP server can ship.

How Extensions replace the experimental field

Every MCP server and client that upgrades to the 2026 SDK gains a formal capability declaration exchange. During the handshake, a server lists the extensions it supports. The client responds with which ones it accepts. Both sides then know exactly what the session can do.

This matters because it replaces an informal convention that was causing real problems in production. When a server uses the experimental field to signal a non-standard behavior, it has no way to know whether the connected client understands that field or ignores it. Failures were silent. A client might receive extension-gated data and silently drop it, or worse, try to interpret it and produce unexpected behavior.

With Extensions, the negotiation is explicit. If a client doesn't declare support for an extension, the server simply doesn't use it for that session. No silent failure. No version-sniffing in server code.

For teams building custom MCP servers, the upgrade path is adding a capability block to your server initialization:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 
const server = new McpServer({
  name: "cx-tools",
  version: "2.0.0",
  capabilities: {
    extensions: {
      // Declare which extensions this server supports
      "cx-tools/streaming-results": { version: "1.0" },
      "cx-tools/structured-cards": { version: "1.0" },
    },
  },
});

If the connected client doesn't support cx-tools/streaming-results, the session proceeds without it. Your server needs to handle both paths, but at least now you know which path you're on.

Tasks: what long-running tools actually needed

The synchronous request-response model works for most tool calls, but CX agents increasingly need to trigger operations that take real time. Running a test simulation against 500 scenarios. Processing and indexing an uploaded document. Coordinating a multi-step refund across three systems. Making an agent block and wait for any of these returns a timeout error or leaves a customer staring at silence.

Tasks are the formal solution. A tool that returns a task responds immediately with a task ID, then streams progress events as the work proceeds. The agent can tell the customer "I've started processing your refund, I'll update you in a moment" instead of silently waiting or timing out.

The structure looks like this:

import { McpServer, TaskManager } from "@modelcontextprotocol/sdk/server/mcp.js";
 
server.tool("run_refund_workflow", {
  order_id: z.string(),
  reason: z.string(),
}, async (params, { taskManager }) => {
  // Return a task instead of blocking
  const task = await taskManager.create({
    title: `Refund workflow: ${params.order_id}`,
  });
 
  // Run the work in the background
  task.run(async (emit) => {
    await emit.progress({ step: "Verifying order", percent: 20 });
    const order = await fetchOrder(params.order_id);
 
    await emit.progress({ step: "Checking eligibility", percent: 40 });
    const eligible = await checkRefundEligibility(order);
 
    if (!eligible) {
      return emit.complete({ status: "ineligible", reason: "Past return window" });
    }
 
    await emit.progress({ step: "Processing refund", percent: 70 });
    const refund = await processRefund(order);
 
    await emit.progress({ step: "Sending confirmation", percent: 90 });
    await sendConfirmation(order.customer_email, refund);
 
    return emit.complete({ status: "success", refund_id: refund.id });
  });
 
  return task.id;
});

The agent receives the task ID, can report intermediate progress to the customer, and picks up the final result when the task completes. The connection doesn't need to stay open for the entire duration. On the monitoring side, tasks give you a clean unit for tracking: duration from creation to completion, which step failed if something went wrong, and which agent triggered the task and with what parameters.

For CX agents specifically, Tasks unlock a class of workflows that were previously too risky to automate because the synchronous model couldn't tolerate the latency. Complex order modifications, multi-system data aggregations, document-driven workflows: all of these fit the Tasks model.

MCP Apps: server-driven UI inside agent hosts

MCP Apps are the most forward-looking change in the 2026 RC, and the one with the longest runway before it's widely supported. The idea is simple: an MCP server can bundle web components that host applications render alongside or instead of plain text tool results.

Today, when your agent calls a tool to look up a customer's order history, the result comes back as JSON. Your agent formats it into text. The customer reads a paragraph describing their orders. With MCP Apps, the server can ship a structured order card component that the host application renders as an interactive UI: collapsible order lines, a reorder button, a status badge.

The agent host controls the rendering surface. The MCP server provides the component and its data. Neither side needs to know the other's full implementation.

This is early. Most orchestration platforms don't render MCP App components yet, and the component model is still stabilizing in the RC. But if you're building a CX agent for a platform that does support it, or if you're building the host platform yourself, the 2026 spec gives you a defined protocol for this rather than a proprietary extension.

For now, the practical move is to follow the RC component spec and design your tool outputs with structured data rather than pre-formatted strings. That way, when your target host ships MCP App support, your server is ready without a schema migration.

OAuth hardening: closing the token forwarding gap

This is the change with the most immediate security implications, and it's worth understanding before the July 28 final.

The 2026 spec classifies MCP servers as OAuth Resource Servers and requires them to use resource indicators, as defined in RFC 8707. Resource indicators bind a token to a specific server URL at the point of issuance. A token issued for https://tools.yourcompany.com/cx cannot be used at https://other-server.example.com/api, because the token's intended audience is encoded into the token itself and validated by every resource server.

Why this matters: before this change, an MCP server that received a token could forward it to other protected services and make calls as if it were the legitimate client. This was a real attack surface in multi-server deployments, where agents talk to several MCP servers in a single session. A compromised or malicious server in that chain could escalate its access by forwarding tokens to other servers.

With resource indicators, that attack fails. Each token is scoped to one resource server, and the math doesn't work across server boundaries.

The registration change is straightforward if you're using a standard OAuth provider:

// Register your MCP server as an OAuth Resource Server
// This config goes in your authorization server, not your MCP server
const resourceServer = {
  resource_identifier: "https://cx-tools.yourcompany.com",
  scopes_supported: [
    "tools:read",
    "tools:execute",
    "tasks:create",
    "tasks:read",
  ],
  // Clients must include resource parameter when requesting tokens
  require_resource_indicator: true,
};
 
// Token request from client now includes resource parameter
const tokenRequest = {
  grant_type: "client_credentials",
  client_id: "agent-runtime-prod",
  scope: "tools:execute tasks:create",
  resource: "https://cx-tools.yourcompany.com", // RFC 8707 resource indicator
};

If your MCP server currently relies on bearer tokens without resource indicators, you need to add this before the July 28 final and update your authorization server configuration to enforce it. Teams that use MCP servers from third parties should verify that those servers have completed this migration, since the protection only holds if all servers in the chain enforce resource scoping.

Stateless core: serverless and edge deployments

The cleanest architectural change in the 2026 RC is also the least visible in day-to-day development. The spec now formally separates the stateless protocol core from the stateful session layer.

The core handles message framing, tool discovery, and request-response schemas. None of that requires a persistent connection. The session layer handles multi-turn context, subscriptions, and long-running task streams. That does require statefulness, but only for sessions that need those features.

The practical result: you can deploy an MCP server as a serverless function. A request comes in, the function handles it, the connection closes. If the request starts a Task, the task state lives in a data store, not in the server process. The next event in the task lifecycle can be handled by a different function invocation.

For teams running on AWS Lambda, Cloudflare Workers, or Vercel Edge Functions, this is the change that makes production MCP deployment tractable without running persistent compute for each connected client.

What Salesforce Agentforce 3 signals for enterprise adoption

The other datapoint worth noting alongside the spec update: Salesforce Agentforce 3 is anchoring its interoperability story around MCP. When a platform with Salesforce's enterprise footprint makes MCP a first-class integration point, it changes the procurement conversation for any team evaluating CX agent infrastructure.

This isn't about which CRM you use. It's about the signal that enterprise software vendors are treating MCP as the interoperability layer for agent-to-tool communication. The 97 million monthly downloads and 10,000 indexed servers were developer adoption. Agentforce 3 is enterprise adoption. The two together mean that MCP tool investments made today are more durable than they were 12 months ago.

The spec changes in the 2026 RC reflect this maturation. Extensions, Tasks, and OAuth hardening are not developer-experience improvements. They're the kind of changes you make when the protocol needs to run reliably in regulated enterprise environments with real security requirements and real latency SLAs.

Monitoring the new spec in production

Tasks introduce a new monitoring surface that didn't exist before: the gap between task creation and task completion. For CX agents, that gap is where things go wrong in ways your existing tool call logs won't capture.

You'll want to track task duration distributions by task type, the rate at which tasks fail at each progress step, and correlation between task duration and customer satisfaction scores. A task that consistently takes 45 seconds at the "Processing refund" step is a signal worth investigating before it shows up in your CSAT data.

Here's how you'd wire task monitoring in Chanl:

import Chanl from "@chanl/sdk";
 
const chanl = new Chanl({ apiKey: process.env.CHANL_API_KEY });
 
// Track task lifecycle events
chanl.monitoring.onTaskEvent((event) => {
  if (event.type === "task.created") {
    console.log(`Task started: ${event.taskId} (${event.toolName})`);
  }
 
  if (event.type === "task.completed") {
    const durationMs = event.completedAt - event.createdAt;
    if (durationMs > 30_000) {
      // Flag tasks taking more than 30 seconds
      chanl.monitoring.flag({
        taskId: event.taskId,
        reason: "slow_task",
        durationMs,
      });
    }
  }
 
  if (event.type === "task.failed") {
    // Which step failed?
    console.error(`Task ${event.taskId} failed at step: ${event.lastStep}`);
  }
});
 
// Track Extensions negotiation to know which clients support what
chanl.monitoring.onExtensionNegotiation((event) => {
  console.log(
    `Client ${event.clientId} accepted extensions: ${event.accepted.join(", ")}`
  );
  console.log(
    `Client ${event.clientId} declined extensions: ${event.declined.join(", ")}`
  );
});

Pairing this with Chanl's MCP monitoring gives you a dashboard view across every tool call, task lifecycle, and extension negotiation in your production traffic. When a new client version drops that accepts an extension yours does not yet implement, you'll see it in the negotiation logs before it affects behavior.

Getting ready before July 28

The RC is final enough to build against. The SDK maintainers are releasing 2026-compatible versions, and the protocol changes between RC and final are expected to be minimal.

Four concrete steps before the final drops:

First, read the spec RC. Not just this summary. The authorization section in particular has nuances that matter for your specific deployment topology. Second, audit your MCP servers for tools that currently block on long operations and plan the Task refactor. Third, register your production MCP servers as OAuth Resource Servers with your authorization provider and enable resource indicator enforcement. Fourth, update your test suite to cover the new negotiation handshake. If you're using simulation-based testing, add test cases for clients that don't support your extensions to verify your fallback paths work correctly.

The protocol improvements in MCP + OpenAPI guide for managing tool definitions at scale still apply. What changes is the runtime behavior once those tools are deployed: they can now run longer, stream progress, and authenticate safely in multi-server environments.

If you're starting from scratch on MCP tool design, Building MCP Tools for CX Agents covers the design patterns that hold regardless of spec version, tool descriptions being the most consequential piece of any MCP tool definition. The 2026 spec changes what tools can do at runtime. Good tool descriptions remain the difference between an agent that uses tools correctly and one that doesn't.

Learn Agentic AI

Weekly. Patterns for shipping agents that work. MCP, scorecards, regression tests, prompts, model comparisons.

Subscribe

500+ builders subscribed