MCP headersHelper 401-recovery falls back to OAuth dynamic client registration instead of re-invoking headersHelper

Version: 2.1.217

Description: For an HTTP-transport MCP server configured with headersHelper (static bearer token minted by a shell command, e.g. gcloud auth print-access-token), the helper only runs at connection setup/reconnect (per docs), not per-request. When the underlying token expires mid-session (e.g. GCP user access tokens expire ~60 min), tool calls fail with 401. The docs (changelog v2.1.193) state the client should "re-run and reconnect automatically" on 401/403 — but in practice this surfaces as:

Incompatible auth server: does not support dynamic client registration

This indicates the 401-recovery path is attempting generic OAuth discovery/dynamic client registration against the server rather than cleanly re-invoking headersHelper and reconnecting. claude mcp list/get still report the server "✔ Connected" during this failure. Running /mcp reconnect <server> manually resolves it, confirming the fix is "re-run headersHelper + reconnect," but the automatic path doesn't do this correctly for headersHelper-authenticated servers.

Repro config:

{ "google-secops": { "type": "http", "url": "https://us-chronicle.googleapis.com/mcp", "headersHelper": "echo '{\"Authorization\": \"Bearer '\"$(gcloud auth print-access-token)\"'\"}'" } }

Expected: on 401/403 from a headersHelper-configured server, silently re-run headersHelper and retry, without attempting OAuth discovery.

Actual: surfaces "Incompatible auth server: does not support dynamic client registration" and the tool call fails until a manual /mcp reconnect.