MCP OAuth: org connector does not try path-based well-known discovery for path-prefixed servers

Description

Claude's org connector (claude.ai → Organization Settings → Connectors) does not work with MCP servers hosted at a path prefix on a shared nginx host (e.g. \https://api-internal.company.com/my-service/mcp\).

Steps to reproduce

1. Deploy a FastMCP server at a path-prefixed URL: \https://host/my-service/mcp\
2. Implement all required OAuth endpoints correctly:

• \https://host/my-service/.well-known/oauth-protected-resource\ ✅
• \https://host/my-service/.well-known/oauth-authorization-server\ ✅
• \POST /my-service/oauth/register\ ✅
• \GET /my-service/authorize\ ✅
• \POST /my-service/token\ ✅
• \WWW-Authenticate: Bearer resource_metadata=...\ on 401 ✅

1. Add the connector URL in claude.ai → Organization Settings → Connectors
2. Claude constructs discovery URL at the host root: \https://host/.well-known/oauth-authorization-server\ → 404
3. Falls back to guessing \https://host/authorize\ → 404
4. OAuth fails — connector never connects

Expected behavior

When host-root discovery fails (404), Claude should fall back to trying the path-based well-known URL:

• \https://host/my-service/.well-known/oauth-protected-resource\
• \https://host/my-service/.well-known/oauth-authorization-server\

These are valid per RFC 9728 and RFC 8414. Our server serves them correctly — Claude just never tries them.

The \WWW-Authenticate: Bearer resource_metadata=...\ 401 challenge (RFC 9728 §5.1) should also be honoured, but Claude's connector appears to do proactive discovery before connecting, so it never sees the 401.

Environment

• Claude.ai org connector (Organization Settings → Connectors)
• FastMCP server on EKS behind shared nginx
• MCP protocol version: 2025-03-26

Why this matters

Path-prefixed MCP servers on shared reverse proxies are extremely common in enterprise environments. This blocks native OAuth for any such deployment without requiring dedicated hostnames or infrastructure changes.