Bump conformance referee to da56f663 and reconcile baselines

The last published referee (0.2.0-alpha.9) still enforces the pre-#3002
shape, so implementing the reshape at the old pin fails three checks.
Conformance main@da56f663 includes #403 (checks flipped to the final
revision) and #406 (per-check expected-failures granularity); the sha256-
verified tarball pin mechanism is unchanged.

All server scenarios pass with zero baseline entries. The bump window adds
client auth scenarios for features the OAuth client does not implement
(DPoP per SEP-1932, and the jwt-bearer grant); those are baselined
per-check so their passing checks stay live.

Riding the same window: requiredCapabilities error data moves from the old
array shape to the schema's object shape (referee #376), and the
everything-server capability gate reads client_capabilities so it works
for clients that omit the now-optional clientInfo.

Author: maxisbey

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

@@ -10,7 +10,24 @@
 # scenarios start passing and MUST be removed from this list (the runner fails
 # on stale entries), so the baseline burns down per milestone.
 
-client: []
+client:
+  # SEP-1932 (DPoP): the SDK's OAuth client does not implement DPoP proofs.
+  # These scenarios are new in the da56f663 referee pin. The entries are
+  # per-check (conformance #406) because both scenarios pass their
+  # non-DPoP checks (discovery, token acquisition, request flow) live.
+  - auth/dpop:sep-1932-client-token-request-proof
+  - auth/dpop:sep-1932-client-dpop-auth-scheme
+  - auth/dpop:sep-1932-client-fresh-proof
+  - auth/dpop-nonce:sep-1932-client-token-request-proof
+  - auth/dpop-nonce:sep-1932-client-dpop-auth-scheme
+  - auth/dpop-nonce:sep-1932-client-fresh-proof
+  - auth/dpop-nonce:sep-1932-client-as-nonce
+  - auth/dpop-nonce:sep-1932-client-rs-nonce
+  # Workload identity federation: the OAuth client does not implement the
+  # urn:ietf:params:oauth:grant-type:jwt-bearer grant (it answers with
+  # authorization_code). Also new in the da56f663 referee pin; per-check for
+  # the same reason.
+  - auth/wif-jwt-bearer:wif-grant-type
 
 server:
   # SEP-2663 (io.modelcontextprotocol/tasks): the SDK does not implement the

.github/workflows/conformance.yml

@@ -19,17 +19,19 @@ env:
   # Bump deliberately and reconcile both
   # .github/actions/conformance/expected-failures*.yml files in the same change.
   #
-  # Temporarily pinned to the pkg.pr.new build of conformance main@4944b268
-  # (0.2.0-alpha.8, which includes #372: fail checks whose prerequisite is
-  # missing instead of skipping them) — alpha.8 is not published to npm yet.
-  # Pinned by commit SHA so the tarball cannot move under us;
+  # Temporarily pinned to the pkg.pr.new build of conformance main@da56f663,
+  # which includes #403 (sep-2575 checks flipped to the post-spec-#3002 shape:
+  # clientInfo optional on requests, serverInfo in result _meta instead of the
+  # discover body) and #406 (per-check expected-failures granularity) — the
+  # last published npm release (0.2.0-alpha.9) still enforces the pre-#3002
+  # shape. Pinned by commit SHA so the tarball cannot move under us;
   # CONFORMANCE_PKG_SHA256 pins the bytes and the fetch-and-verify step below
   # downloads, checks the digest, and repoints CONFORMANCE_PKG at the
   # verified local copy. Repin to the next published @modelcontextprotocol/
-  # conformance release (>=0.2.0-alpha.8) once it ships, then drop
+  # conformance release (>=0.2.0-alpha.10) once it ships, then drop
   # CONFORMANCE_PKG_SHA256 and the fetch-and-verify steps.
-  CONFORMANCE_PKG: "https://pkg.pr.new/@modelcontextprotocol/conformance@4944b268"
-  CONFORMANCE_PKG_SHA256: "0f70c035782d319d72ab427653c5275db5c50429d59fae0241a645b33aeda1a7"
+  CONFORMANCE_PKG: "https://pkg.pr.new/@modelcontextprotocol/conformance@da56f663"
+  CONFORMANCE_PKG_SHA256: "bbc94678033071df4bc9851ce2054f9dff918f4501661d1d60e2d09d8c515e6d"
 
 jobs:
   server-conformance:

examples/servers/everything-server/mcp_everything_server/server.py

@@ -357,13 +357,13 @@ async def test_missing_capability(ctx: Context) -> str:
     ``CallToolResult.isError``) so the conformance harness observes a protocol-level
     error response with ``data.requiredCapabilities``.
     """
-    client_params = ctx.session.client_params
-    sampling_declared = client_params is not None and client_params.capabilities.sampling is not None
+    capabilities = ctx.session.client_capabilities
+    sampling_declared = capabilities is not None and capabilities.sampling is not None
     if not sampling_declared:
         raise MCPError(
             code=MISSING_REQUIRED_CLIENT_CAPABILITY,
             message="This tool requires the client 'sampling' capability",
-            data={"requiredCapabilities": ["sampling"]},
+            data={"requiredCapabilities": {"sampling": {}}},
         )
     return "Client declared sampling capability; proceeding."