Todd Schiller

Human ✘ Artificial Intelligence

Note This Week in Extensibility: MCP ships its stateless spec with sandboxed app UIs, WebMCP starts tracking cross-engine support, WebExtensions weighs OAuth for MCP servers

Week of July 24–31, 2026: MCP ships its 2026-07-28 specification with a stateless core and first-class extensions for sandboxed app UIs and async tasks, WebMCP stands up a cross-engine implementation tracker, and the WebExtensions group weighs letting extensions authenticate to MCP servers.

The agentic-web plumbing consolidated around MCP this week. MCP shipped its biggest revision as a final spec, reworking the protocol to be stateless and formalizing extensions for server-rendered app UIs and long-running tasks. The standards work around it oriented the same way: WebMCP began tracking cross-engine support, and the WebExtensions group started weighing how an extension would authenticate to an MCP server.

Infrastructure: MCP ships its 2026-07-28 specification

MCP shipped the 2026-07-28 specification, its largest revision since launch. The release, out July 28, makes the protocol stateless, dropping the initialize handshake and session-ID pinning so requests self-describe through HTTP headers that gateways can route on, and formalizes an extensions framework. Two extensions lead it: MCP Apps, where a server ships an interactive HTML UI that the host renders in a sandboxed iframe, with UI-initiated actions flowing through the same consent and audit path as tool calls; and a stateless Tasks extension for long-running work an agent can start and resume from a handle. Authorization moves from Dynamic Client Registration toward client metadata documents, and the release sets a formal twelve-month minimum deprecation window for the features it retires (Roots, Sampling, Logging, and the HTTP+SSE transport). The TypeScript, Python, Go, and C# SDKs are updated; the Rust SDK supports the new spec in beta.

Why it matters: end users of an MCP host can now be shown interactive, server-supplied interfaces inside the same consent boundary as tool calls, rather than plain text, and the Tasks extension lets an agent hand off long-running work and return to it later. Making the core stateless also lets MCP run behind ordinary load balancers, which lowers what it takes to operate.

Standards: WebMCP starts tracking cross-engine support

WebMCP opened an implementation-status document tracking Brave, Chrome, Firefox, and Safari. WebMCP lets a website expose in-page tools for a user's own agent to call. It specified the getTools() discovery API the prior week; this week a July 28 commit normalized how a tool accesses this and the abort signal, and a July 31 pull request added a central file to record where each engine stands. The status document is still an open pull request, and WebMCP remains a Web Machine Learning Community Group draft shipping only as a Chrome origin trial, so the tracker records intent and progress, not shipped cross-vendor support.

Why it matters: a standards effort standing up a cross-engine status tracker is a signal it is being managed as a multi-vendor track rather than a single-vendor experiment. It does not change that the only running implementation is one browser's origin trial.

Governance: WebExtensions weighs how extensions authenticate to MCP servers

The WebExtensions group triaged a proposal to let extensions authenticate to MCP servers without per-developer OAuth setup. At its July 30 call the Community Group discussed an issue, opened July 4 by @MiguelsPizza, to have browsers or extension stores host an OAuth Client ID Metadata Document for each extension, so an authorization server can validate the extension's identity and redirect URIs without the developer pre-registering a client or implementing Dynamic Client Registration. The stated motivation is connecting extensions to MCP servers and other OAuth sign-in flows. The discussion, recorded in the still-open minutes, drew caution from Mozilla and others about the trust model and about further centering extension identity on app-store distribution.

Why it matters: it connects the browser-extension platform to the same authentication problem MCP is working through in its own spec, where the July 28 release also moves away from Dynamic Client Registration toward client metadata documents. This is an early triage, not an agreed work item.

Applications: n8n opens verified community nodes as agent tools

n8n 2.33.0 let verified community nodes act as agent tools and added admin-managed instance credentials. The July 28 release lets a workflow builder wire a vetted third-party community node into an agent as a callable tool, widening the set of extensions an automation can use beyond the built-in nodes, and adds centrally provisioned instance credentials that an admin manages so end-user builders do not each configure their own. The same release handles MCP OAuth2 token expiry and PKCE negotiation and makes MCP connection failures non-blocking for agents.

Why it matters: it expands what an n8n builder can assemble, both the vetted extensions available as agent tools and the connections an admin can standardize, in a widely self-hosted automation platform. The community-node-as-tool path runs through n8n's node-verification program, which ties the new capability to a governance gate.

Also worth knowing

Merge.dev added per-integration control over its embedded connect flow. A July 24 changelog lets a company embedding Merge's Link connector tailor what its end users see per integration, hiding specific authentication or configuration steps and disabling the Selective Sync screen while it keeps running in the background.

Microsoft 365 Copilot Agent Builder added SharePoint lists as knowledge sources. A July 29 release note lets makers building Copilot agents ground them on SharePoint list data and enables adaptive-card refresh for custom-engine agents, incremental additions to the agent-authoring surface.

Svix said the MCP working group is developing webhook support for a future MCP version. A July 30 post frames the stateless 2026-07-28 change as the groundwork and describes webhook delivery, where a client makes a request and receives the response later, as the next step for long-latency MCP operations. This is stated direction, not a dated spec item.

Four provisional URI schemes surfaced for expert review. Requests to register pay:, gcx:, aet:, and glue: reached the IETF uri-review list in late July, ahead of any IANA registration; pay: is aimed at payment deep links.

On the radar

  • July 28 onward: MCP's twelve-month minimum deprecation window began for Roots, Sampling, Logging, and the HTTP+SSE transport.
  • August 1: Chrome Web Store policy enforcement begins; the bans on prediction-market and AI-guardrail-circumvention extensions and the narrowed data-collection rules take effect.
  • August 4–5: W3C WebAssembly Community Group in-person meeting, with phase votes queued for several core proposals, followed by a Research Day on August 6.

This Week in Extensibility is curated by Todd Schiller. Research, drafting, and fact checking are AI-assisted.