MCP 401 has no WWW-Authenticate header and no OAuth discovery metadata

An unauthenticated request to /mcp returns a bare 401 with no WWW-Authenticate header, and none of the OAuth discovery documents exist. MCP clients that attempt discovery fail with an opaque parse error instead of a usable message.

Steps to reproduce

claude mcp add --transport http trackslash https://trackslash.com/mcp
claude mcp list

Actual

trackslash: https://trackslash.com/mcp (HTTP) - ✘ Failed to connect — HTTP 404:
Invalid OAuth error response: SyntaxError: JSON Parse error: Unable to parse JSON
string. Raw body: 404 page not found

The client sees 401, looks for the protected-resource metadata, gets Go's plain-text 404 page not found, and fails trying to parse it as JSON. Nothing in the error indicates that a bearer API token is what is actually required.

Verified against production:

Expected

At minimum, the 401 advertises its scheme:

WWW-Authenticate: Bearer realm="trackslash"

That alone turns the failure into an actionable "supply a token" for every conforming client.

Scope decision

Two options, and they are not exclusive:

1. Minimal (recommended first): add the WWW-Authenticate: Bearer header to the /mcp 401. Small, no new endpoints, fixes the confusing error immediately.
2. Full: serve /.well-known/oauth-protected-resource per RFC 9728 so clients can discover the resource and its authorization servers. Only worth doing if trackslash intends to support an OAuth flow rather than the current manual API-token model documented in README.md:24-47.

If option 1 only, also make the README connection steps explicit that OAuth is not supported and a token is required, since claude mcp add --transport http attempts OAuth by default.

Tests

Assert the 401 from /mcp carries WWW-Authenticate, and that a valid bearer token still returns 200.

Related

Depends on the NotFound/MethodNotAllowed ticket — once JSON 404s are wired for API subtrees, the discovery 404 should be JSON rather than plain text.