When adding a new MCP server in Workspace Settings → MCP Tools, if the target server supports both a static Bearer-token header AND OAuth 2.1 discovery (per the MCP Authorization spec — i.e. it returns 401 + a WWW-Authenticate: Bearer resource_metadata="..." header when called with no credentials), the "Add New MCP Server" flow fails with "OAuth re-authorization required" — even when a valid Authorization: Bearer <token> header has been explicitly configured in the form's "Headers" section.
It looks like the discovery/connection-test step probes the target server without attaching the configured headers, sees the server's OAuth-discovery response, and immediately concludes OAuth is mandatory — without ever retrying with the header the user configured.
To Reproduce
- Go to Workspace Settings → MCP Tools → Add server.
- Enter a Server Name and Server URL for an MCP server that requires auth on every request and also supports OAuth 2.1 discovery (RFC 9728 protected resource metadata).
- In "Headers", add
Authorization = Bearer <a token confirmed working directly against that server via curl/Postman>.
- Submit.
- The modal sticks on "Adding…" then fails; the MCP Tools page shows a red "OAuth re-authorization required" banner.
- In DevTools → Network, the request to
.../discover?workspaceId=... returns 401 with body {"success":false,"error":"OAuth re-authorization required"}.
Expected behavior
If a valid static Authorization header is explicitly configured for a connection, the discovery step should use it (or at least retry with it) instead of unconditionally requiring an interactive OAuth flow just because the target server also happens to support OAuth for clients that prefer it.
Additional context
Confirmed via direct testing (curl/Postman) that the exact same Authorization: Bearer <token> used in the Headers field authenticates successfully and returns valid tool results directly against the server — ruling out an invalid/expired token as the cause. The server tested against was https://valta.co/api/mcp, which supports both a static API-key Bearer token and full OAuth 2.1 (for clients like Claude.ai's connector) on the same endpoint. Happy to provide more detail or a test credential if useful for reproducing.
When adding a new MCP server in Workspace Settings → MCP Tools, if the target server supports both a static Bearer-token header AND OAuth 2.1 discovery (per the MCP Authorization spec — i.e. it returns 401 + a
WWW-Authenticate: Bearer resource_metadata="..."header when called with no credentials), the "Add New MCP Server" flow fails with "OAuth re-authorization required" — even when a validAuthorization: Bearer <token>header has been explicitly configured in the form's "Headers" section.It looks like the discovery/connection-test step probes the target server without attaching the configured headers, sees the server's OAuth-discovery response, and immediately concludes OAuth is mandatory — without ever retrying with the header the user configured.
To Reproduce
Authorization=Bearer <a token confirmed working directly against that server via curl/Postman>..../discover?workspaceId=...returns401with body{"success":false,"error":"OAuth re-authorization required"}.Expected behavior
If a valid static Authorization header is explicitly configured for a connection, the discovery step should use it (or at least retry with it) instead of unconditionally requiring an interactive OAuth flow just because the target server also happens to support OAuth for clients that prefer it.
Additional context
Confirmed via direct testing (curl/Postman) that the exact same
Authorization: Bearer <token>used in the Headers field authenticates successfully and returns valid tool results directly against the server — ruling out an invalid/expired token as the cause. The server tested against washttps://valta.co/api/mcp, which supports both a static API-key Bearer token and full OAuth 2.1 (for clients like Claude.ai's connector) on the same endpoint. Happy to provide more detail or a test credential if useful for reproducing.