Support MCP specification version 2026-07-28 (stateless core)

Start with api/core/mcp/types.py and review PRs #25766 and #37892 to compare existing protocol-version negotiation and ServerCapabilities work. Then trace the /mcp/server/<server_code>/mcp endpoint and client path; the requested stateless core, authorization changes, and Extensions support are broad enough to require decomposition before implementation.

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

The Model Context Protocol released its 2026-07-28 specification (the biggest revision since launch), which moves the protocol core to a stateless model. Key changes include:

• Removal of the initialize/initialized handshake and the Mcp-Session-Id header (per-request _meta now carries protocol version/client identity/capabilities instead)
• A new server/discover RPC for capability discovery
• Multi Round-Trip Requests (MRTR) replacing server-initiated requests (roots/sampling/elicitation)
• Roots, Sampling, Logging, and the legacy HTTP+SSE transport are now deprecated (12-month grace period)
• Mandatory Mcp-Method/Mcp-Name headers for routing, cacheable list results, and hardened OAuth/OIDC-based authorization
• A formal Extensions framework (reverse-DNS identifiers, independent versioning, advertised via ServerCapabilities.extensions), which officially folds in two extensions that matter for Dify's use cases:
  • MCP Apps: lets a server ship server-rendered, interactive UI (sandboxed iframe) alongside a tool call, so a connected client can render rich UI instead of plain text/structured content
  • MCP Tasks: moved out of the core protocol into an official extension for durable, long-running work — clients poll tasks/get for results instead of relying on tasks/result push, which better matches Dify's workflow-as-MCP-server use case for long-running app/workflow executions

Currently Dify's MCP client/server implementation only negotiates up to 2025-06-18
(see api/core/mcp/types.py:
LATEST_PROTOCOL_VERSION = "2025-06-18",
SERVER_SUPPORTED_PROTOCOL_VERSIONS = {"2024-11-05", "2025-03-26", "2025-06-18"}),
and there is no extensions field on ServerCapabilities, so neither MCP Apps nor MCP Tasks can currently be advertised or negotiated.

As more MCP servers/clients (e.g. official Tier-1 SDKs: TypeScript, Python, Go, C#) migrate to the stateless 2026-07-28 spec, I expect Dify will start hitting the same "Unsupported protocol version" error that occurred previously with 2025-06-18 (see #25767, #27677), both when:

1. Dify acts as an MCP client connecting to upstream servers that only speak 2026-07-28 (potentially including servers that expose MCP Apps UI or MCP Tasks), and
2. Dify's published-workflow MCP server endpoint (/mcp/server/<server_code>/mcp) needs to serve 2026-07-28-only clients, and would benefit from exposing long-running workflow executions via the MCP Tasks extension instead of blocking on a single synchronous tools/call.

Could the team share a timeline for supporting the 2026-07-28 specification — particularly (a) the stateless core (dropping session-based initialize handshake), (b) the new authorization requirements, and (c) the Extensions framework with MCP Apps and MCP Tasks support?

2. Additional context or comments

References:

• Official spec announcement: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Changelog vs 2025-11-25: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• MCP Apps extension (live since 2026-01-26): https://modelcontextprotocol.io/specification/2026-07-28 (Extensions section)
• MCP Tasks extension: same spec, Extensions section
• Prior related work in Dify for 2025-06-18 support: PR #25766, #37892
• Relevant file: api/core/mcp/types.py (LATEST_PROTOCOL_VERSION / SERVER_SUPPORTED_PROTOCOL_VERSIONS / ServerCapabilities)

Given the stateless core removes session semantics entirely, and MCP Apps/Tasks are net-new capabilities requiring new UI rendering (Apps) and async job/polling infrastructure (Tasks), this is likely a multi-phase migration (broader in scope than PR #25766/#37892) rather than a simple version-string bump:

1. Protocol negotiation: stateless core, _meta-based versioning, server/discover
2. Authorization hardening (OAuth/OIDC alignment, CIMD over DCR)
3. Extensions framework support in ServerCapabilities
4. MCP Apps: sandboxed iframe UI rendering on the client side (if Dify is to act as a full MCP client), and/or exposing Dify's own rich UI via Apps when Dify acts as an MCP server
5. MCP Tasks: tasks/get polling support for long-running Dify workflow/app executions exposed via the workflow-as-MCP-server feature

Happy to help test against a 2026-07-28-compliant server/client if useful.

3. Can you help us with this feature?

• I am interested in contributing to this feature.