MCP Upgrade Checklist for Production Chatbot Integrations

The Model Context Protocol's next specification becomes final on July 28, 2026. Its release candidate removes the protocol-level session and initialize handshake, adds a stateless core, strengthens authorization, and moves optional capabilities into extensions. The four Tier 1 SDKs already have betas for testing.

That date is a publication milestone, not a shutdown switch. Existing clients and servers keep working. The urgent job is to find the assumptions in your chatbot integration that the new protocol no longer makes for you.

Run this seven-gate checklist before changing production traffic:

1. Inventory every use of session IDs, sticky routing, and in-memory state.
2. Separate the SDK major-version upgrade from the protocol revision.
3. Replace hidden session state with explicit, authorized handles.
4. Prove old and new clients can negotiate through your gateway.
5. Retest OAuth discovery, token audiences, scopes, and redirects.
6. Plan replacements for deprecated Roots, Sampling, and Logging.
7. Re-run tool schemas, error handling, retries, and audit evidence.

Gate 1: Find State the Protocol Used to Hide

Start at the transport boundary, not in the tool code. Search your server, gateway, and observability stack for Mcp-Session-Id, session-keyed maps, sticky-cookie rules, connection affinity, and caches partitioned by session. Then classify each occurrence.

Transport-only state can usually disappear. A session ID used only because an SDK example generated one is not application data.

Application state needs an explicit replacement. A shopping basket, draft refund, selected account, pagination cursor, or partially completed support workflow must have its own identifier and authorization rules.

Routing state needs an infrastructure decision. If a gateway sends every session to the same process, test whether any server instance can now handle the next request. Stateless transport is useful only when state is no longer stranded inside one worker.

Security state must never be migrated mechanically. If a session ID currently keys a PKCE verifier, tenant, permission set, or user identity, bind that information to an authenticated principal or server-generated nonce instead.

The protocol's sessionless design makes the boundary explicit: protocol state disappears, while application state travels through ordinary tool inputs and outputs. That is a better fit for chatbots because a conversation can resume on another process without inheriting an invisible authorization decision.

Gate 2: Split the SDK Upgrade From the Wire Upgrade

Do not put "upgrade MCP" into one ticket. There are two changes with different blast radiuses:

• The SDK may introduce new packages, names, types, or defaults.
• The server may begin speaking the 2026-07-28 protocol revision.

The official beta SDK guidance says these steps are independently controllable in TypeScript and Go. Python v2 can answer both protocol revisions from one endpoint, while the C# preview defaults its HTTP transport to the new stateless mode. Exact behavior belongs in the release notes for the SDK version you pin.

Keep stable SDKs on critical production paths until your compatibility suite passes. Pin an exact beta in a branch or disposable deployment because public APIs can still change before stable releases. If you publish a wrapper library, add dependency bounds so a new major SDK cannot surprise downstream users.

Gate 3: Make Chatbot Workflow State Explicit

Consider a support chatbot that opens a return case. The old server stores the draft against the protocol session:

Mcp-Session-Id: s_91d

create_return_draft(order_id: "48192")
-> { "status": "draft_created" }

add_return_reason(reason: "arrived damaged")
-> { "status": "reason_added" }

The second call works only when it reaches the process holding s_91d. The payload does not say which draft should change, and a log reviewer cannot see the dependency.

With explicit state, the first tool returns a narrow handle and every later call carries it:

{
  "tool": "create_return_draft",
  "arguments": { "order_id": "48192" },
  "result": {
    "return_draft_id": "rd_7f23",
    "expires_at": "2026-07-17T15:30:00Z"
  }
}

{
  "tool": "add_return_reason",
  "arguments": {
    "return_draft_id": "rd_7f23",
    "reason": "arrived damaged"
  }
}

The server still owns the state behind rd_7f23. It must verify that the authenticated caller may access the order, reject expired handles, and prevent one customer from guessing another customer's ID. Explicit does not mean client-trusted.

This pattern also improves the AI agent audit trail: the trace can connect intent, draft creation, approval, and execution without reconstructing an opaque transport session. For broader tool boundaries, use the chatbot connector permissions checklist to keep read and write authority separate.

Gate 4: Prove Routing and Negotiation

The new protocol puts version and capability information on requests and uses server/discover instead of a long-lived initialization handshake. A compatible client can probe the new path and fall back to initialize when it reaches an older server.

Test that behavior through the infrastructure users actually reach. A local client-to-server check will not expose a gateway that strips unfamiliar headers or a cache that mixes authenticated tool catalogs.

The new Mcp-Method header lets a gateway route or rate-limit without parsing the JSON-RPC body. Requests that name a tool, resource, or prompt can also carry Mcp-Name. Decide whether those values belong in access logs, then redact arguments and credentials independently. Use the list-result ttlMs only when the result is genuinely safe to cache for that caller; a shared tool catalog must not leak tenant-specific capabilities.

Remove sticky sessions only after a round-robin test proves that ten sequential calls can land on different instances without losing workflow state. Then terminate one instance during a multi-turn chatbot task and confirm the next request completes or fails with a recoverable, specific error.

Gate 5: Rehearse Authorization as a New Client

The draft MCP authorization specification aligns HTTP deployments more closely with OAuth and OpenID Connect. Treat the migration as an authorization review, not just a new handshake.

Verify these behaviors in a clean client with no cached credentials:

• The server publishes protected-resource metadata and identifies its authorization server.
• The client handles both OAuth authorization-server metadata and OIDC discovery.
• Authorization and token requests include the MCP server as the resource audience.
• The server rejects tokens minted for another resource and never passes the client token through to an upstream API.
• Desktop and CLI clients register as native when appropriate, so localhost redirects are not mistaken for web redirects.
• PKCE uses S256, redirect URIs match exactly, and requested scopes begin at the minimum needed.
• A step-up scope challenge asks for the additional permission without silently widening every future tool call.

Use separate tokens for the MCP server and any downstream CRM, helpdesk, or commerce API. A valid user token is not permission to forward that token elsewhere. If a chatbot can access account-specific data, the identity and authorization checks from the authenticated chatbot guide still apply at every lookup and action.

Gate 6: Give Deprecated Features an Owner

Roots, Sampling, and Logging remain functional in this release, but they are now deprecated. The deprecation policy gives teams time to migrate; it does not make the work disappear.

Inventory capability negotiation as well as method calls. A codebase that never invokes logging/setLevel may still advertise Logging and assume every client understands it. Stop adding new dependencies on the deprecated surface, assign each existing use to an owner, and record the replacement date.

Gate 7: Re-run Schemas, Errors, and Human Questions

Tool input and output schemas move to full JSON Schema 2020-12. Composition, conditionals, $ref, and $defs become available, but richer schemas create more validation paths. Re-run valid, missing, extra, incorrectly typed, and mutually exclusive inputs against every high-impact chatbot tool.

Check literal error assertions too. The beta guidance notes that a missing resource now uses standard JSON-RPC -32602 rather than MCP's older custom -32002. A client that switches on one number may turn a recoverable lookup miss into a generic failure.

The Tasks extension covers long-running work, while Multi Round-Trip Requests let a tool return an input-required result and continue after the user answers. Test interruptions as first-class paths: the visitor closes the widget, denies a confirmation, answers twice, or resumes after the handle expires. No protocol revision can decide your product's retry and consent policy for you.

The Release Rehearsal

Run the final test against a production-like gateway with redacted production-shaped data.

Canary one integration and one low-risk tool before migrating write actions. Set rollback criteria in advance: authentication failure rate, tool error rate, lost-state events, duplicate actions, and p95 latency. Keep the old protocol path available until the new path has survived real multi-turn traffic and an instance-failure drill.

The useful deadline is not July 28. It is the day your compatibility evidence is strong enough that protocol state, application state, and authorization are visibly separate. That separation makes a chatbot integration easier to scale, debug, and secure long after this MCP revision is old news.

Build your chatbot for free →

No credit card required.