@@ -49,4 +49,7 @@ monitor both and confirm their published outputs:
   published release tags and deploys it to
   [csharp.sdk.modelcontextprotocol.io](https://csharp.sdk.modelcontextprotocol.io). Verify the new
   version appears in the version picker and that its major-version path serves the updated content.
-  A content-only docs refresh can be run later via manual dispatch with the `docs_ref` input.
+  A content-only docs refresh can be run later via manual dispatch. Its `docs_source` input defaults
+  to `release-tags` to mirror a release deployment; select `latest-branches` to refresh every
+  published major from its current `release/{MAJOR}.x` branch, using `main` for its
+  matching major.
@@ -103,11 +103,14 @@ Report the run's conclusion, accounting for these docs-specific behaviors:
 - **Version discovery reads published releases.** For each major version >= 1, the workflow takes
   the most recently published non-draft release tagged `v{MAJOR}.*`. A draft release contributes
   nothing.
-- **Every major is rebuilt.** Each major's docs are built from that major's latest release tag into
-  its own path (`/v1/`, `/v2/`). A new MAJOR adds a new path; the site root redirects to the newest
-  release, prereleases included.
+- **Every major is rebuilt.** A release-triggered run builds each major from its latest release tag
+  into its own path (`/v1/`, `/v2/`). A manual dispatch defaults to the same release-tag content,
+  or can build every major from `release/{MAJOR}.x`, using `main` for its matching major,
+  by selecting `docs_source=latest-branches`. A new MAJOR adds a new path; the site root redirects
+  to the newest release, prereleases included.
 - **Orchestration comes from `main`.** The scripts and picker assets are always checked out from
-  `main`, while each version's content comes from its release tag. A docs fix that lives only in a
+  `main`. Release-triggered and default manual runs use release-tag content; a manual
+  `docs_source=latest-branches` run uses source-branch content. A docs fix that lives only in a
   release branch will not affect orchestration.
 
 If it failed, summarize the failing step. Common causes are a docs build failure in one version's
@@ -164,17 +167,21 @@ Both remediations require explicit user confirmation.
 gh run rerun {run-id} --failed
 ```
 
-**Refresh the docs without a new release** — when documentation content needs correcting after the
-release, the docs workflow accepts a manual dispatch that rebuilds one major version's content from
-an arbitrary ref, without minting a product release:
+**Rebuild the released docs** — use the default `release-tags` source to retry a failed Pages
+deployment after a release, without minting a product release:
 
 ```
-gh workflow run docs.yml --field docs_ref={branch-tag-or-commit}
+gh workflow run docs.yml --field docs_source=release-tags
 ```
 
-The ref's major version, read from `src/Directory.Build.props`, must have a published release; the
-workflow fails fast if it does not. This replaces only the matching major's HTML — orchestration
-and all other versions are unaffected.
+**Refresh docs without a new release** — select `latest-branches` to rebuild every published major
+from its current source branch (`release/{MAJOR}.x`, using `main` for its matching major):
+
+```
+gh workflow run docs.yml --field docs_source=latest-branches
+```
+
+The workflow fails instead of silently using a release tag when any major has no matching branch.
 
 ## Edge Cases
 
 
@@ -6,19 +6,23 @@ name: Publish Docs
 # latest release, by date, for each major >= 1), builds each release tag into
 # its own sub-path (e.g. /v1/ and /v2/) with make generate-docs, injects a
 # version-picker widget into each page, adds a root redirect to the default
-# version, and deploys the combined site. A manual dispatch can also rebuild
-# the matching major-version path from a specified branch, tag, or commit.
+# version, and deploys the combined site. A manual dispatch can build every
+# major-version path from release tags or current source branches.
 # Triggers on release publish and manual dispatch.
 
 on:
   release:
     types: [published]
   workflow_dispatch:
     inputs:
-      docs_ref:
-        description: Branch, tag, or commit whose docs should refresh its matching major version
-        required: false
-        type: string
+      docs_source:
+        description: Source for every published major-version path
+        required: true
+        default: release-tags
+        type: choice
+        options:
+        - release-tags
+        - latest-branches
 
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
@@ -86,7 +90,7 @@ jobs:
     - name: Build all versions
       shell: bash
       env:
-        CONTENT_REF: ${{ inputs.docs_ref }}
+        USE_SOURCE_BRANCHES: ${{ inputs.docs_source == 'latest-branches' }}
       run: |
         set -euo pipefail
         ROOT="$PWD"
@@ -96,28 +100,43 @@ jobs:
 
         # Orchestration (discovered docs-versions.json, scripts, picker assets)
         # always comes from THIS branch. Normally each version's HTML is produced
-        # by its release tag. A manual docs_ref replaces the matching major's
-        # HTML with content built from that ref, allowing content-only refreshes
-        # without minting a product release.
-        git fetch --tags --force origin
-        CONTENT_REF="${CONTENT_REF:-}"
-        CONTENT_WORKTREE=""
-        CONTENT_SLUG=""
-        if [[ -n "$CONTENT_REF" ]]; then
-          CONTENT_WORKTREE="$ROOT/../work-content"
-          git worktree add --force --detach "$CONTENT_WORKTREE" "$CONTENT_REF"
-          CONTENT_SLUG="$(node "$ROOT/scripts/get-docs-version-slug.mjs" "$CONTENT_WORKTREE/src/Directory.Build.props")"
-          if ! node "$ROOT/scripts/list-versions.mjs" | cut -f1 | grep -Fxq "$CONTENT_SLUG"; then
-            echo "::error::The docs ref '$CONTENT_REF' has major '$CONTENT_SLUG', which has no published release."
-            exit 1
-          fi
-          echo "Refreshing $CONTENT_SLUG docs from $CONTENT_REF"
+        # by its release tag. A manual dispatch can instead build every major from
+        # its current source branch.
+        git fetch --tags --force --prune origin "+refs/heads/*:refs/remotes/origin/*"
+        USE_SOURCE_BRANCHES="${USE_SOURCE_BRANCHES:-false}"
+
+        MAIN_SLUG=""
+        if [[ "$USE_SOURCE_BRANCHES" == "true" ]]; then
+          MAIN_PROPS="$(mktemp)"
+          git show refs/remotes/origin/main:src/Directory.Build.props > "$MAIN_PROPS"
+          MAIN_SLUG="$(node "$ROOT/scripts/get-docs-version-slug.mjs" "$MAIN_PROPS")"
+          rm -f "$MAIN_PROPS"
+          echo "Refreshing all published docs from source branches (main serves $MAIN_SLUG)"
+        else
+          echo "Refreshing all published docs from release tags"
         fi
 
         while IFS=$'\t' read -r slug ref; do
-          if [[ "$slug" == "$CONTENT_SLUG" ]]; then
-            echo "::group::Build $slug (from ref $CONTENT_REF)"
-            wt="$CONTENT_WORKTREE"
+          if [[ "$USE_SOURCE_BRANCHES" == "true" ]]; then
+            source_branch="release/${slug#v}.x"
+            if ! git show-ref --verify --quiet "refs/remotes/origin/$source_branch"; then
+              if [[ "$slug" == "$MAIN_SLUG" ]]; then
+                source_branch="main"
+              else
+                echo "::error::No source branch found for $slug. Expected release/${slug#v}.x, or main with VersionPrefix for $slug."
+                exit 1
+              fi
+            fi
+
+            echo "::group::Build $slug (from branch $source_branch)"
+            wt="$ROOT/../work-$slug"
+            git worktree add --force --detach "$wt" "refs/remotes/origin/$source_branch"
+            source_slug="$(node "$ROOT/scripts/get-docs-version-slug.mjs" "$wt/src/Directory.Build.props")"
+            if [[ "$source_slug" != "$slug" ]]; then
+              git worktree remove --force "$wt"
+              echo "::error::Source branch '$source_branch' has major '$source_slug', not '$slug'."
+              exit 1
+            fi
           else
             echo "::group::Build $slug (from tag $ref)"
             wt="$ROOT/../work-$slug"
@@ -130,16 +149,10 @@ jobs:
           cp -a "$wt/artifacts/_site/." "$COMBINED/$slug/"
           node "$ROOT/scripts/inject-version-picker.mjs" "$COMBINED/$slug" "$slug" --base /
 
-          if [[ "$wt" != "$CONTENT_WORKTREE" ]]; then
-            git worktree remove --force "$wt"
-          fi
+          git worktree remove --force "$wt"
           echo "::endgroup::"
         done < <(node "$ROOT/scripts/list-versions.mjs")
 
-        if [[ -n "$CONTENT_WORKTREE" ]]; then
-          git worktree remove --force "$CONTENT_WORKTREE"
-        fi
-
         node "$ROOT/scripts/finalize-docs-site.mjs" "$COMBINED"
 
         echo "Combined site contents:"
 
@@ -58,7 +58,7 @@
 
   <!-- Build Infra & Packaging dependencies-->
   <ItemGroup>
-    <PackageVersion Include="Microsoft.SourceLink.GitHub" Version="8.0.0" />
+    <PackageVersion Include="Microsoft.SourceLink.GitHub" Version="10.0.401" />
   </ItemGroup>
 
   <!-- Testing dependencies -->
 
@@ -12,7 +12,7 @@ The C# SDK tracks implementation of MCP spec components using the [modelcontextp
 
 ### Next spec revision
 
-The next MCP specification revision is being developed in the [protocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol).
+The C# SDK's standing plan is to release support for each new MCP specification revision alongside the specification, as it did for the 2026-07-28 revision. Accepted SEPs are tracked on the revision's project board throughout development so implementation is ready when the revision is published. The next revision is being developed in the [protocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol).
 
 ### Feedback and end-to-end scenarios
 
 
@@ -846,23 +846,17 @@ private static bool ValidateProtocolVersionEnvelope(
             return false;
         }
 
-        bool hasProtocolVersionMeta = TryGetProtocolVersionMeta(message, out var protocolVersionMeta);
-
-        if (!McpProtocolVersions.RequiresPerRequestMetadata(protocolVersionHeader) &&
-            !McpProtocolVersions.RequiresPerRequestMetadata(protocolVersionMeta))
+        // Legacy headers leave reserved metadata opaque. Without a header, let the core server resolve
+        // the version from the session or metadata, falling back to legacy handling when neither selects one.
+        if (string.IsNullOrEmpty(protocolVersionHeader) ||
+            McpProtocolVersions.SupportsInitializeHandshake(protocolVersionHeader))
         {
             errorDetail = null;
             return true;
         }
 
-        if (string.IsNullOrEmpty(protocolVersionHeader))
-        {
-            errorDetail = CreateHeaderMismatchError(
-                $"Bad Request: The {McpProtocolVersionHeaderName} header is required when the request body declares a per-request metadata protocol version.");
-            return false;
-        }
-
-        if (!hasProtocolVersionMeta)
+        // Header validity was checked first, so only supported modern headers reach this point.
+        if (!TryGetProtocolVersionMeta(message, out var protocolVersionMeta))
         {
             // Notifications are exempt from the required-_meta rejection: they are fire-and-forget
             // (a JSON-RPC error response has no recipient), and rejecting them silently drops
 
@@ -77,16 +77,19 @@ private async Task InitializeAsync(JsonRpcMessage message, CancellationToken can
             else if (await StreamableHttpClientSessionTransport.TryReadJsonRpcErrorAsync(response, cancellationToken).ConfigureAwait(false) is { } parsedError)
             {
                 // A JSON-RPC error envelope in the body means the peer IS a Streamable HTTP server.
-                // It just rejected our specific request (e.g., -32022 UnsupportedProtocolVersion,
-                // -32021 MissingRequiredClientCapability, -32020 HeaderMismatch, or any other
-                // application-level error). Don't fall back to SSE — that would mask the real signal
-                // and surface a misleading "session id required" error from the SSE GET path.
-                // Adopt the Streamable HTTP transport and throw the structured exception so the
-                // connect-time fallback logic can react per spec PR #2844. Setting ActiveTransport
-                // first makes the catch filter below leave the now-owned transport alone.
+                // Adopt it before surfacing the failure so the catch filter leaves the now-owned
+                // transport alone, and never mask the response by attempting deprecated SSE.
                 LogUsingStreamableHttp(_name);
                 ActiveTransport = streamableHttpTransport;
-                throw McpSessionHandler.CreateRemoteProtocolExceptionFromError(parsedError);
+
+                if (StreamableHttpClientSessionTransport.ShouldSurfaceJsonRpcErrorAsProtocolException(response.StatusCode, parsedError))
+                {
+                    throw McpSessionHandler.CreateRemoteProtocolExceptionFromError(parsedError);
+                }
+
+                // TryReadJsonRpcErrorAsync buffered the content, so this preserves the same response
+                // body and status without consuming the network stream a second time.
+                throw await HttpResponseMessageExtensions.CreateHttpRequestExceptionWithBodyAsync(response, cancellationToken).ConfigureAwait(false);
             }
             else
             {
 
@@ -367,14 +367,6 @@ public async Task ConnectAsync(CancellationToken cancellationToken = default)
                         // fallback): falling back to initialize wouldn't fix a malformed envelope.
                         throw;
                     }
-                    catch (McpProtocolException ex) when (
-                        ex.ErrorCode == McpErrorCode.InvalidRequest &&
-                        ex.Message.Contains(McpHttpHeaders.SessionId, StringComparison.Ordinal))
-                    {
-                        // Local transport validation: a 2026-07-28+ response must not carry HTTP session state.
-                        // This is not evidence of an initialize-handshake server, so do not fall back.
-                        throw;
-                    }
                     catch (McpProtocolException)
                     {
                         // Per spec PR #2844, the fallback MUST NOT be keyed to a single error code.
 
@@ -80,19 +80,19 @@ public override async Task SendMessageAsync(JsonRpcMessage message, Cancellation
         // for robustness. Servers occasionally emit them with 4xx codes other than 400.
         if (!response.IsSuccessStatusCode &&
             await TryReadJsonRpcErrorAsync(response, cancellationToken).ConfigureAwait(false) is { } parsedError &&
-            (response.StatusCode == HttpStatusCode.BadRequest ||
-             IsPerRequestMetadataProtocolErrorCode((McpErrorCode)parsedError.Error.Code)))
+            ShouldSurfaceJsonRpcErrorAsProtocolException(response.StatusCode, parsedError))
         {
             throw McpSessionHandler.CreateRemoteProtocolExceptionFromError(parsedError);
         }
 
         await response.EnsureSuccessStatusCodeWithResponseBodyAsync(cancellationToken).ConfigureAwait(false);
     }
 
-    private static bool IsPerRequestMetadataProtocolErrorCode(McpErrorCode code) =>
-        code is McpErrorCode.UnsupportedProtocolVersion
-             or McpErrorCode.MissingRequiredClientCapability
-             or McpErrorCode.HeaderMismatch;
+    internal static bool ShouldSurfaceJsonRpcErrorAsProtocolException(HttpStatusCode statusCode, JsonRpcError error) =>
+        statusCode == HttpStatusCode.BadRequest ||
+        (McpErrorCode)error.Error.Code is McpErrorCode.UnsupportedProtocolVersion
+                                          or McpErrorCode.MissingRequiredClientCapability
+                                          or McpErrorCode.HeaderMismatch;
 
     /// <summary>
     /// Reads a JSON-RPC error envelope from an <c>application/json</c> response body, returning
 
@@ -401,14 +401,6 @@ private static async Task<ClientCompletionDetails> GetCompletionDetailsAsync(Tas
 
     private async Task HandleMessageAsync(JsonRpcMessage message, CancellationToken cancellationToken)
     {
-        // Project the 2026-07-28 protocol's per-request _meta fields onto the message context before any
-        // filters run so they (and downstream handlers) can read client info / capabilities /
-        // protocol version / log level without re-parsing.
-        if (_isServer && message is JsonRpcRequest incomingRequest)
-        {
-            PopulateContextFromMeta(incomingRequest);
-        }
-
         Histogram<double> durationMetric = _isServer ? s_serverOperationDuration : s_clientOperationDuration;
         string method = GetMethodName(message);
 
@@ -544,65 +536,6 @@ await SendMessageAsync(new JsonRpcResponse
         return result;
     }
 
-    /// <summary>
-    /// Reads the 2026-07-28 protocol's per-request <c>_meta</c> fields off the request and projects them onto
-    /// <see cref="JsonRpcMessage.Context"/> so they're available without re-parsing throughout the pipeline.
-    /// </summary>
-    /// <remarks>
-    /// Per SEP-2575 the keys are <c>io.modelcontextprotocol/protocolVersion</c>,
-    /// <c>/clientInfo</c>, <c>/clientCapabilities</c>, and (optional) <c>/logLevel</c>. Any field
-    /// that's already set on the context (e.g., <see cref="JsonRpcMessageContext.ProtocolVersion"/>
-    /// populated by the HTTP transport from the <c>MCP-Protocol-Version</c> header) is left alone
-    /// unless explicitly overwritten by a non-null value parsed here.
-    /// </remarks>
-    internal static void PopulateContextFromMeta(JsonRpcRequest request)
-    {
-        if (request.Params is not JsonObject paramsObj)
-        {
-            return;
-        }
-
-        if (paramsObj["_meta"] is not JsonObject metaObj)
-        {
-            return;
-        }
-
-        var context = request.Context ??= new JsonRpcMessageContext();
-
-        if (metaObj[MetaKeys.ProtocolVersion] is JsonValue protocolVersion &&
-            protocolVersion.TryGetValue(out string? protocolVersionValue))
-        {
-            // If a transport-level header (e.g., the Streamable HTTP MCP-Protocol-Version header) already
-            // populated this, validate the body _meta matches per SEP-2575. A disagreement is reported with
-            // -32020 HeaderMismatch (the same code used for the Mcp-Method/Mcp-Name header-vs-body checks),
-            // which conformant 2026-07-28 clients recognize as a SEP-2575 signal and surface as-is rather
-            // than mistaking it for an initialize-handshake server and falling back to initialize.
-            if (context.ProtocolVersion is { } existing && !string.Equals(existing, protocolVersionValue, StringComparison.Ordinal))
-            {
-                throw new McpProtocolException(
-                    $"Header mismatch: the per-request _meta protocol version '{protocolVersionValue}' does not match the MCP-Protocol-Version header value '{existing}'.",
-                    McpErrorCode.HeaderMismatch);
-            }
-
-            context.ProtocolVersion = protocolVersionValue;
-        }
-
-        if (metaObj[MetaKeys.ClientInfo] is JsonNode clientInfoNode)
-        {
-            context.ClientInfo = JsonSerializer.Deserialize(clientInfoNode, McpJsonUtilities.JsonContext.Default.Implementation);
-        }
-
-        if (metaObj[MetaKeys.ClientCapabilities] is JsonNode clientCapabilitiesNode)
-        {
-            context.ClientCapabilities = JsonSerializer.Deserialize(clientCapabilitiesNode, McpJsonUtilities.JsonContext.Default.ClientCapabilities);
-        }
-
-        if (metaObj[MetaKeys.LogLevel] is JsonNode logLevelNode)
-        {
-            context.LogLevel = JsonSerializer.Deserialize(logLevelNode, McpJsonUtilities.JsonContext.Default.LoggingLevel);
-        }
-    }
-
     /// <summary>
     /// Injects the 2026-07-28 protocol's per-request <c>_meta</c> fields into an outgoing request.
     /// Protocol version and client info overwrite any existing values; client capabilities are merged