René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[BUG] MCP server \"discover\" step ignores configured static Authorization header, always requires OAuth","articleBody":"\nWhen 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 \u003ctoken\u003e` header has been explicitly configured in the form's \"Headers\" section.\n\nIt 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.\n\n**To Reproduce**\n1. Go to Workspace Settings → MCP Tools → Add server.\n2. 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).\n3. In \"Headers\", add `Authorization` = `Bearer \u003ca token confirmed working directly against that server via curl/Postman\u003e`.\n4. Submit.\n5. The modal sticks on \"Adding…\" then fails; the MCP Tools page shows a red \"OAuth re-authorization required\" banner.\n6. In DevTools → Network, the request to `.../discover?workspaceId=...` returns `401` with body `{\"success\":false,\"error\":\"OAuth re-authorization required\"}`.\n\n**Expected behavior**\nIf 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.\n\n**Additional context**\nConfirmed via direct testing (curl/Postman) that the exact same `Authorization: Bearer \u003ctoken\u003e` 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.","author":{"url":"https://github.com/Billionaire664","@type":"Person","name":"Billionaire664"},"datePublished":"2026-07-14T02:24:26.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":45},"url":"https://github.com/5665/sim/issues/5665"}