Merge remote-tracking branch 'origin/main' into feature/gauthamprabhu/correlate-invalid-envelope-request-id

# Conflicts:
#	docs/migration.md
#	tests/interaction/transports/test_hosting_http.py
#	tests/shared/test_streamable_http.py

Author: Gautham Prabhu

.github/actions/conformance/client.py

@@ -6,6 +6,10 @@
 Contract:
     - MCP_CONFORMANCE_SCENARIO env var -> scenario name
     - MCP_CONFORMANCE_CONTEXT env var -> optional JSON (for client-credentials scenarios)
+    - MCP_CONFORMANCE_PROTOCOL_VERSION env var -> spec version the harness mock
+      server is speaking (e.g. "2025-11-25", "2026-07-28"). Always set; when
+      --spec-version is omitted the harness picks per-scenario (LATEST_SPEC_VERSION
+      for active scenarios, DRAFT_PROTOCOL_VERSION for draft-only ones).
     - Server URL as last CLI argument (sys.argv[1])
     - Must exit 0 within 30 seconds
 
@@ -40,7 +44,7 @@
 )
 from mcp.client.context import ClientRequestContext
 from mcp.client.streamable_http import streamable_http_client
-from mcp.shared.auth import OAuthClientInformationFull, OAuthClientMetadata, OAuthToken
+from mcp.shared.auth import AuthorizationCodeResult, OAuthClientInformationFull, OAuthClientMetadata, OAuthToken
 
 # Set up logging to stderr (stdout is for conformance test output)
 logging.basicConfig(
@@ -50,6 +54,14 @@
 )
 logger = logging.getLogger(__name__)
 
+#: Spec version the harness is running this scenario at (e.g. "2025-11-25",
+#: "2026-07-28"). The harness always sets this (when --spec-version is omitted
+#: it picks per-scenario: LATEST_SPEC_VERSION for active scenarios,
+#: DRAFT_PROTOCOL_VERSION for draft-only ones), so None means we were invoked
+#: outside the harness. Handlers that need to take the stateless 2026 path will
+#: branch on this once the SDK has one; today it is logged only.
+PROTOCOL_VERSION: str | None = os.environ.get("MCP_CONFORMANCE_PROTOCOL_VERSION")
+
 # Type for async scenario handler functions
 ScenarioHandler = Callable[[str], Coroutine[Any, None, None]]
 
@@ -109,6 +121,7 @@ class ConformanceOAuthCallbackHandler:
     def __init__(self) -> None:
         self._auth_code: str | None = None
         self._state: str | None = None
+        self._iss: str | None = None
 
     async def handle_redirect(self, authorization_url: str) -> None:
         """Fetch the authorization URL and extract the auth code from the redirect."""
@@ -130,6 +143,8 @@ async def handle_redirect(self, authorization_url: str) -> None:
                         self._auth_code = query_params["code"][0]
                         state_values = query_params.get("state")
                         self._state = state_values[0] if state_values else None
+                        iss_values = query_params.get("iss")
+                        self._iss = iss_values[0] if iss_values else None
                         logger.debug(f"Got auth code from redirect: {self._auth_code[:10]}...")
                         return
                     else:
@@ -139,15 +154,15 @@ async def handle_redirect(self, authorization_url: str) -> None:
             else:
                 raise RuntimeError(f"Expected redirect response, got {response.status_code} from {authorization_url}")
 
-    async def handle_callback(self) -> tuple[str, str | None]:
-        """Return the captured auth code and state."""
+    async def handle_callback(self) -> AuthorizationCodeResult:
+        """Return the captured auth code, state, and iss."""
         if self._auth_code is None:
             raise RuntimeError("No authorization code available - was handle_redirect called?")
-        auth_code = self._auth_code
-        state = self._state
+        result = AuthorizationCodeResult(code=self._auth_code, state=self._state, iss=self._iss)
         self._auth_code = None
         self._state = None
-        return auth_code, state
+        self._iss = None
+        return result
 
 
 # --- Scenario Handlers ---
@@ -164,6 +179,18 @@ async def run_initialize(server_url: str) -> None:
             logger.debug("Listed tools successfully")
 
 
+@register("json-schema-ref-no-deref")
+async def run_json_schema_ref_no_deref(server_url: str) -> None:
+    """Initialize and list tools; the scenario fails only if the client fetches a network $ref.
+
+    ClientSession never walks inputSchema or resolves $refs, so listing is enough (SEP-2106).
+    """
+    async with streamable_http_client(url=server_url) as (read_stream, write_stream):
+        async with ClientSession(read_stream, write_stream) as session:
+            await session.initialize()
+            await session.list_tools()
+
+
 @register("tools_call")
 async def run_tools_call(server_url: str) -> None:
     """Connect, initialize, list tools, call add_numbers(a=5, b=3), close."""
@@ -347,6 +374,7 @@ def main() -> None:
 
     server_url = sys.argv[1]
     scenario = os.environ.get("MCP_CONFORMANCE_SCENARIO")
+    logger.debug(f"Conformance protocol version: {PROTOCOL_VERSION!r}")
 
     if scenario:
         logger.debug(f"Running explicit scenario '{scenario}' against {server_url}")

.github/actions/conformance/expected-failures.2026-07-28.yml

@@ -0,0 +1,91 @@
+# Expected failures for the carried-forward 2026-07-28 legs
+# (`--suite all --spec-version 2026-07-28` for both server and client).
+#
+# This baseline is separate from expected-failures.yml because entries are
+# keyed by scenario name only: a scenario that passes at its default version
+# in the 2025 legs but fails when forced to 2026-07-28 (or vice versa) cannot
+# be expressed in a shared file (the passing leg would flag the entry as
+# stale). Like expected-failures.yml, this single file covers both
+# directions: the client 2026 leg reads the `client:` section and the server
+# 2026 leg reads the `server:` section. Both burn down independently of the
+# 2025 legs.
+#
+# Baseline established against the harness pinned via CONFORMANCE_PKG in
+# .github/workflows/conformance.yml. New conformance releases are adopted by
+# deliberately bumping that pin and reconciling both this file and
+# expected-failures.yml in the same change.
+#
+# Entries are grouped by what unblocks them. As each gap closes the
+# corresponding scenarios start passing and MUST be removed from this list
+# (the runner fails on stale entries), so the baseline burns down per
+# milestone.
+
+client:
+  # --- No stateless client path on main yet ---
+  # client.py drives the 2025 stateful lifecycle (initialize handshake +
+  # session). The 2026-mode mock server is stateless, so the call sequence
+  # never reaches the assertion. Unblocks when client.py's is_modern_protocol()
+  # branch takes the per-request _meta path.
+  - tools_call
+
+  # --- Auth scenarios cut short by the 2026 connection lifecycle ---
+  # The auth fixture flow drives the 2025 stateful lifecycle; the 2026-mode
+  # mock rejects the MCP POST before the scope-escalation behaviour these
+  # scenarios measure, so no authorization requests are observed. Unblocks
+  # when client.py's auth flow speaks the 2026 per-request lifecycle.
+  - auth/scope-step-up
+  - auth/scope-retry-limit
+
+  # --- Same gaps as the 2025 baseline (fail identically when forced to 2026-07-28) ---
+  # SEP-2575 (request metadata / _meta envelope): client does not populate the
+  # _meta envelope or the MCP-Protocol-Version header semantics yet.
+  - request-metadata
+  # SEP-2322 (multi-round-trip requests): client does not echo requestState /
+  # handle IncompleteResult yet.
+  - sep-2322-client-request-state
+  # SEP-2243 (HTTP standardization): no fixture handler / client header support yet.
+  - http-custom-headers
+  - http-invalid-tool-headers
+  # SEP-2352 (authorization server migration): the client re-registers and does not reuse the old
+  # AS credentials, but the 2026-mode mock rejects the MCP POST before the migration 401 fires
+  # (client.py drives the 2025 stateful lifecycle), so the re-register check is never reached.
+  # Unblocks with the 2026 stateless client lifecycle.
+  - auth/authorization-server-migration
+  # auth/enterprise-managed-authorization (SEP-990) is in the 2025 baseline but
+  # NOT here: the harness skips it as inapplicable at --spec-version 2026-07-28
+  # (it is an extension scenario not carried into the 2026 wire), so it is
+  # neither run nor evaluated on this leg.
+
+server:
+  # --- Carried-forward 2025-era scenarios still failing on the 2026 wire ---
+  # The stateless 2026 path now reaches handlers for plain request/response
+  # scenarios; tools-call-with-progress still fails because the stateless
+  # server has no channel for server→client progress notifications.
+  - tools-call-with-progress
+  # SEP-2106 (JSON Schema 2020-12 in tool inputSchema): the fixture tool's
+  # schema has none of the 2020-12 keywords the scenario checks. The scenario
+  # is in `--suite all` but not `--suite active`, so this is the only leg that
+  # runs it; it fails identically at 2025-11-25 (not a 2026-path regression).
+  - json-schema-2020-12
+
+  # --- Draft scenarios (same failures and reasons as the `--suite draft` leg) ---
+  # SEP-2322 (multi-round-trip requests / IncompleteResult): not implemented.
+  - input-required-result-basic-elicitation
+  - input-required-result-basic-sampling
+  - input-required-result-basic-list-roots
+  - input-required-result-request-state
+  - input-required-result-multiple-input-requests
+  - input-required-result-multi-round
+  - input-required-result-non-tool-request
+  - input-required-result-result-type
+  - input-required-result-tampered-state
+  - input-required-result-capability-check
+  # SEP-2243 (HTTP header standardization): Mcp-Method / Mcp-Name cross-check
+  # against the request body is not implemented.
+  - http-header-validation
+  # WARNING-only entries: these scenarios emit no FAILURE checks but the
+  # expected-failures evaluator counts WARNINGs as failures (the summary line
+  # only shows passed/failed, not warnings, so a local re-probe can mis-read
+  # these as stale).
+  - input-required-result-missing-input-response
+  - input-required-result-validate-input

.github/actions/conformance/expected-failures.yml

@@ -0,0 +1,56 @@
+# Conformance scenarios not yet passing against the Python SDK on main.
+# CI exits 0 if only these fail, exits 1 on unexpected failures or stale entries.
+#
+# Baseline established against the harness pinned via CONFORMANCE_PKG in
+# .github/workflows/conformance.yml. New conformance releases are adopted by
+# deliberately bumping that pin and reconciling both this file and
+# expected-failures.2026-07-28.yml in the same change.
+#
+# Entries are grouped by SEP. As each SEP lands in the SDK the corresponding
+# scenarios start passing and MUST be removed from this list (the runner fails
+# on stale entries), so the baseline burns down per milestone.
+
+client:
+  # --- Draft-spec scenarios (in `--suite draft`, also part of `--suite all`) ---
+  # SEP-2575 (request metadata / _meta envelope): client does not populate the
+  # _meta envelope or the MCP-Protocol-Version header semantics yet.
+  - request-metadata
+  # SEP-2322 (multi-round-trip requests): client does not echo requestState /
+  # handle IncompleteResult yet.
+  - sep-2322-client-request-state
+  # SEP-2243 (HTTP standardization): no fixture handler / client header support yet.
+  - http-custom-headers
+  - http-invalid-tool-headers
+  # SEP-2352 (authorization server migration): the client re-registers and does not reuse the old
+  # AS credentials, but this 2026-introduced scenario runs at 2026-07-28, where client.py's 2025
+  # stateful lifecycle is rejected (400 on initialize) before the migration 401 fires, so the
+  # re-register check is never reached. Unblocks with the 2026 stateless client lifecycle.
+  - auth/authorization-server-migration
+
+  # --- Pre-existing scenarios that fail on checks added after conformance 0.1.15 ---
+  # SEP-990 (enterprise-managed authorization extension): no fixture handler /
+  # client support for the token-exchange + JWT bearer flow.
+  - auth/enterprise-managed-authorization
+
+server:
+  # --- Draft-spec scenarios (in `--suite draft`; the `active` suite is green) ---
+  # SEP-2322 (multi-round-trip requests / IncompleteResult): not implemented.
+  - input-required-result-basic-elicitation
+  - input-required-result-basic-sampling
+  - input-required-result-basic-list-roots
+  - input-required-result-request-state
+  - input-required-result-multiple-input-requests
+  - input-required-result-multi-round
+  - input-required-result-non-tool-request
+  - input-required-result-result-type
+  - input-required-result-tampered-state
+  - input-required-result-capability-check
+  # SEP-2243 (HTTP header standardization): Mcp-Method / Mcp-Name cross-check
+  # against the request body is not implemented.
+  - http-header-validation
+  # WARNING-only entries: these scenarios emit no FAILURE checks but the
+  # expected-failures evaluator counts WARNINGs as failures (the summary line
+  # only shows passed/failed, not warnings, so a local re-probe can mis-read
+  # these as stale).
+  - input-required-result-missing-input-response
+  - input-required-result-validate-input

.github/actions/conformance/run-server.sh

@@ -7,15 +7,36 @@ SERVER_URL="http://localhost:${PORT}/mcp"
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 cd "$SCRIPT_DIR/../../.."
 
-# Start everything-server
+# Refuse to start if something is already listening on the port. The readiness
+# check below cannot tell our server apart from a stale one, so a leftover
+# listener would mean silently running conformance against old code.
+if (: > "/dev/tcp/localhost/${PORT}") 2>/dev/null; then
+    echo "Error: port ${PORT} is already in use." >&2
+    echo "Stop the stale process first (lsof -ti:${PORT} -sTCP:LISTEN | xargs kill) or set PORT to a free port." >&2
+    exit 1
+fi
+
+echo "Starting mcp-everything-server on port ${PORT}..."
 uv run --frozen mcp-everything-server --port "$PORT" &
 SERVER_PID=$!
-trap "kill $SERVER_PID 2>/dev/null || true; wait $SERVER_PID 2>/dev/null || true" EXIT
 
-# Wait for server to be ready
+cleanup() {
+    echo "Stopping server (PID: ${SERVER_PID})..."
+    kill $SERVER_PID 2>/dev/null || true
+    wait $SERVER_PID 2>/dev/null || true
+}
+trap cleanup EXIT
+
+# Wait for server to be ready. --max-time keeps a hung listener from wedging
+# the loop, and a dead server process fails fast instead of retrying.
+echo "Waiting for server to be ready..."
 MAX_RETRIES=30
 RETRY_COUNT=0
-while ! curl -s "$SERVER_URL" > /dev/null 2>&1; do
+while ! curl -s --max-time 2 "$SERVER_URL" > /dev/null 2>&1; do
+    if ! kill -0 $SERVER_PID 2>/dev/null; then
+        echo "Server process exited unexpectedly" >&2
+        exit 1
+    fi
     RETRY_COUNT=$((RETRY_COUNT + 1))
     if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
         echo "Server failed to start after ${MAX_RETRIES} retries" >&2
@@ -26,5 +47,5 @@ done
 
 echo "Server ready at $SERVER_URL"
 
-# Run conformance tests
-npx @modelcontextprotocol/conformance@0.1.10 server --url "$SERVER_URL" "$@"
+npx --yes "${CONFORMANCE_PKG:?set CONFORMANCE_PKG (pinned in .github/workflows/conformance.yml)}" \
+    server --url "$SERVER_URL" "$@"

.github/dependabot.yml

@@ -1,9 +1,21 @@
 version: 2
 updates:
+  - package-ecosystem: "uv"
+    directory: "/"
+    schedule:
+      interval: monthly
+    cooldown:
+      default-days: 14
+    groups:
+      python-packages:
+        patterns:
+          - "*"
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule:
       interval: monthly
+    cooldown:
+      default-days: 14
     groups:
       github-actions:
         patterns:

.github/workflows/claude.yml

@@ -27,14 +27,14 @@ jobs:
       actions: read # Required for Claude to read CI results on PRs
     steps:
       - name: Checkout repository
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
         with:
           fetch-depth: 1
           persist-credentials: false
 
       - name: Run Claude Code
         id: claude
-        uses: anthropics/claude-code-action@2f8ba26a219c06cfb0f468eef8d97055fa814f97 # v1.0.53
+        uses: anthropics/claude-code-action@d5726de019ec4498aa667642bc3a80fca83aa102 # v1.0.148
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} # zizmor: ignore[secrets-outside-env]
           use_commit_signing: true

.github/workflows/comment-on-release.yml

@@ -13,14 +13,14 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
+        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
         with:
           fetch-depth: 0
           persist-credentials: false
 
       - name: Get previous release
         id: previous_release
-        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
+        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         env:
           CURRENT_TAG: ${{ github.event.release.tag_name }}
         with:
@@ -105,7 +105,7 @@ jobs:
 
       - name: Get merged PRs between releases
         id: get_prs
-        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
+        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         env:
           CURRENT_TAG: ${{ github.event.release.tag_name }}
           PREVIOUS_TAG_JSON: ${{ steps.previous_release.outputs.result }}
@@ -171,7 +171,7 @@ jobs:
             return Array.from(prNumbers);
 
       - name: Comment on PRs
-        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
+        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         env:
           PR_NUMBERS_JSON: ${{ steps.get_prs.outputs.result }}
           RELEASE_TAG: ${{ github.event.release.tag_name }}