MCP Client Changelog July 2026: Host Updates & What to Test

Seven MCP clients and host platforms published July updates that may affect how servers connect, authenticate, route tools, return results, or recover from interrupted work. In this Changelog update, we’ll walk you through what changed, who is affected, and what MCP server developers should test. Let’s dive in.

July 2026 MCP Changes at a Glance

What Changed in the MCP 2026-07-28 Revision

The MCP 2026-07-28 specification landed near the end of the month, and it is the largest revision since MCP launched. Two parts of it matter for the client changes below.

MCP is now stateless. The old protocol held a session open between client and server. The new one treats each request as self-contained, which retires the initialize handshake. A client still built around initialize, like Cline, is running the legacy lifecycle.

Sampling is deprecated, along with roots and protocol logging. Sampling lets your server ask the client's model to generate text on your behalf. The deprecation policy keeps all three specified for at least twelve months before removal becomes possible. Goose removed sampling anyway.

The revision also reworks request headers, caching, authorization, and extensions. For more details, see MCP 2026-07-28 Goes Stateless: What Breaks and How to Migrate to V2.

Which MCP Clients Adopted the 2026-07-28 Specification in July?

Protocol Mechanics Changes

Amazon Bedrock AgentCore: Tool-Result Metadata Reaches the Client

An MCP tool result can carry structured metadata in _meta alongside the content the model reads. The harness is the AgentCore layer that runs the agent and passes tool results onward. It used to drop that metadata before the client ever saw it.

AWS changed the harness to stream the metadata instead. It now arrives on its own channel in the InvokeHarness response stream, named toolResultMetadata.

AgentCore splits large metadata into ordered fragments. Join them in the order they arrive, then parse the combined value as JSON to recover the original object. A response can be valid on the wire while a host truncates its metadata, reorders it, or attaches it to the wrong result.

AgentCore also changed authentication and web search:

• AgentCore Identity added Private Key JWT client authentication. The agent signs a short token with a private key instead of sending a shared client secret. The private key never leaves AWS KMS, and CloudTrail records every signing operation. It works for machine-to-machine, on-behalf-of, and user-delegated OAuth flows, and supports RS256, PS256, and ES256.
• Gateway Web Search connector 1.2.0 added a target-level domain include list and raised the existing exclude list from 20 to 100 domains. Each request can also send domainFilter.include, domainFilter.exclude, and publishedDateFilter bounds. Request filters compose with the target-level lists, which stay enforced every time, so a request can only narrow the configured policy.

Both can affect authentication and tools/call behavior for servers behind AgentCore.

Cline: Restart-Safe Routing and Per-Server Timeouts

Cline 4.1.1 replaced the random in-memory identifier used to route native MCP tool calls. Routing now uses the server name from Cline's configuration. The old identifier changed on every process restart, so routing could break after a restart or a server-list edit.

Cline CLI 3.0.48 shipped alongside it and began honoring each server's timeout value from cline_mcp_settings.json. The timeout now applies to initialize, tools/list, and tools/call. A hard-coded five-second limit used to terminate valid slow operations, which most often hit tools that use the network, drive a browser, or run code. The fix ships in Cline SDK 0.0.67, so other Cline surfaces inherit it.

Codex CLI: Refresh MCP Connections Without Restarting Healthy Servers

Codex CLI 0.146.0 keeps MCP connections and Apps tools current when authentication or configuration changes. It can replace a closed connection without restarting healthy ones, so their in-flight calls and cached tool catalogs survive.

The same release included several smaller changes visible to an MCP server:

• MCP tool-name prefixes can be disabled per server (#34991). Codex normally prefixes your tool names with the server name. Without it, your tools appear under their bare names, which can expose collisions the prefix was hiding.
• MCP HTTP requests now include a default user agent (#34883). This changes your access logs and breaks anything that identified Codex by the absence of one.
• Codex binds each call to the tool-catalog revision captured when it starts, so a mid-flight catalog update cannot change an active call (#34588).
• Elicitation reviews use the server's current authority (#35205). Elicitation is the feature that lets your server pause a call to ask the user a question.
• Codex honors configured proxies during MCP authorization (#34479, #35239).
• Codex raised the MCP server recursion limit for deeply nested structures (#35414).

Goose: Sampling Removed, Elicitation and Reconnects Improved

Goose v1.41.0 removed MCP sampling and Goose's legacy proxy for embedded MCP-UI. Older protocol revisions still include sampling during the deprecation window, so a server should check the client's advertised capabilities rather than assume the feature is available.

The release also included these MCP-relevant changes:

• Goose serializes per-session agent creation, so it no longer initializes the same MCP server twice (#9357).
• MCP elicitations now travel through tool streams (#9943). A declined or cancelled question now reaches the server instead of disappearing (#9437).
• Streamable HTTP, which is MCP's current HTTP transport, now has a network-level timeout, so a stalled connection fails fast instead of hanging (#9207). The SSE reconnect loop survives longer disconnections (#8717). SSE is the older server-sent-events transport that Goose still supports.
• Goose reports MCP App host capabilities correctly (#9116), raised App request-size limits (#10180), and fixed an App sandbox-bridge lifecycle bug (#10064). MCP Apps are servers that render a UI inside the client.
• GOOSE_MAX_TOOL_RESPONSE_SIZE makes the tool-output cap configurable (#9256). Goose also dedupes repeated tool-call IDs within one turn (#9792).

ChatGPT, Claude, and Claude Code: Client Changes That Affect MCP Servers

These releases change how tools are discovered, authorized, retried, and run in the background.

ChatGPT: Plugins, Long-Running Work, and Separate Permissions

OpenAI introduced ChatGPT Work for longer tasks across connected apps and files, including scheduled and triggered work. The same release replaced the App Directory with the Plugin Directory, leaving existing app connections untouched. Plugins became the discovery and packaging layer for skills, apps, and app templates across ChatGPT Work and Codex.

A later July release began rolling out Sign in with ChatGPT across selected plugins and partner sites, starting with Airtable, GitLab, HubSpot, Notion, Supabase, and Vercel. Signing in shares name, email, and profile picture if the user has one. Users still approve each plugin's access separately.

For a server, identity and tool authorization remain two different decisions. A successful login must not be treated as permission to call every available tool.

Claude: Consequential Writes and Remote Cowork Sessions

Claude's Microsoft 365 connector gained optional write tools for email, calendars, mailbox settings, OneDrive, and SharePoint. Teams remained read-only. A Microsoft Entra administrator must consent to the updated permission set, and an admin must enable the tools for the organization.

The same release expanded Claude Cowork to web and mobile with remotely running sessions in beta. Work can continue after a laptop closes. Scheduled tasks can run with no device online. MCP servers used in these workflows should treat interruption, delayed completion, and resumption as normal operating states.

Claude Code: Background Agents Are Not Human Approval

Claude Code 2.1.198 added background agent notifications in claude agents. A session that needs input or finishes now fires the Notification hook, through the agent_needs_input and agent_completed events.

Background agents launched from claude agents also finish differently. A worktree is a separate checkout of the repository. When an agent completes code work in one, it now commits, pushes, and opens a draft pull request instead of stopping to ask.

The release also retries transient network errors such as ECONNRESET with backoff rather than aborting the turn. It fixes background tasks in the web, desktop, and VS Code task panels that stayed stuck on "Running" after finishing or after a session resumed.

The release states one security boundary explicitly. A subagent treats a message from the agent that launched it as ordinary task direction. Only a human decision counts as approval. A server performing a consequential action must be able to identify that human authorization in its own inputs.

What These Host Changes Mean for MCP Servers

Ask for the narrowest permissions each tool needs. Keep authentication separate from authorization, and re-check access after credentials or sessions change.

Protect writes with an idempotency key, which is a unique identifier attached to each write. It lets your server recognize a repeat and return the original result instead of doing the work twice. A resumed or retried task then cannot repeat a send, create, update, or delete.

Give long-running operations stable IDs and explicit states such as running, waiting, failed, cancelled, and completed.

How to Test an MCP Server Against July 2026 Client Changes

Add the following cases to your regression suite.

Use protocol traces for wire-level failures, an OAuth debugger for authorization failures, and cross-client tests for host-specific differences. MCPJam covers all three, including single-server local inspection.

What MCP Server Developers Should Do Next

Not every server needs an immediate code change, but they should nevertheless retest the clients it supports. These releases moved the exact boundaries where a server can work locally and still fail inside a production host.

MCPJam can run these cases against a controlled server with request traces, OAuth debugging, cross-client comparison, a model in the loop, and CI integration. Start with the twelve tests above and prioritize the clients your users actually run.

Test your MCP server with MCPJam

Frequently Asked Questions

Does Goose removing sampling mean MCP sampling is gone?

No. Sampling is deprecated in MCP 2026-07-28, not removed, and the protocol keeps it specified for at least twelve months before removal becomes possible. Individual clients can drop it sooner, as Goose did in v1.41.0. Servers that depend on sampling should check client capabilities and plan a migration.

How do I test an MCP server across clients such as ChatGPT, Claude, and Codex?

Run the same tool discovery and execution cases against each real client or an accurate host emulator, then compare protocol traces. Cover authentication, capability negotiation, tool catalogs, metadata, timeouts, cancellation, reconnection, elicitation, and duplicate writes. MCPJam runs these cases against multiple clients from one place and captures a trace for each, which is what exposes the behavior a single-server local inspection cannot.

How do I debug an MCP server that works locally but fails in ChatGPT, Claude, or Codex?

Capture a protocol trace at the failure boundary and classify the problem before changing the server. Check the connection lifecycle, advertised capabilities, tool catalog, result metadata, timeout, OAuth state, permission decision, and retry history. MCPJam reproduces the same call across clients and shows the exact request and response, so the trace tells you whether the failure comes from MCP mechanics or from host-level authentication, authorization, and execution behavior.