MCP OAuth DCR fails for Calendly: client_name "Claude Code (<server>)" rejected as invalid_client_metadata (recurrence of #59445)

Summary

Same failure as #59445, which was auto-closed by the inactivity bot without a fix. Still reproduces on Claude Code 2.1.198.

Environment

• Claude Code version: 2.1.198
• OS: macOS (Darwin 25.5.0), arm64
• Server: Calendly MCP — https://mcp.calendly.com, registered as a user-scoped HTTP MCP server

Symptom

/mcp → calendly → Authenticate, and claude mcp login calendly, both fail instantly with:

Couldn't complete authentication for "calendly": SDK auth failed:

No browser window opens. The message is empty after the colon.

Root cause (independently reproduced)

Claude Code's DCR request hardcodes client_name: "Claude Code (${serverName})". For a server named calendly, this becomes "Claude Code (calendly)". Calendly's /oauth/register endpoint rejects client names containing parentheses:

$ curl -s -X POST https://calendly.com/oauth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"Claude Code (calendly)","redirect_uris":["http://localhost:51543/callback"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"],"token_endpoint_auth_method":"none"}'

{"error":"invalid_client_metadata","errors":{"name":["may only contain alphanumeric characters, hyphens, and spaces."]}}

Identical payload with the parentheses stripped succeeds:

$ curl -s -X POST https://calendly.com/oauth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"Claude Code calendly","redirect_uris":["http://localhost:51543/callback"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"],"token_endpoint_auth_method":"none"}'

{"client_id":"...","client_name":"Claude Code calendly", ...}

The underlying invalid_client_metadata error/description from the server is not surfaced anywhere in the UI or CLI output — only the generic SDK auth failed: message is shown, which made this very hard to diagnose without probing the DCR endpoint directly.

Workaround

Manually pre-register a client with a paren-free name against Calendly's /oauth/register, pin the callback port, and reconfigure with --client-id so Claude Code skips its own (broken) DCR call:

claude mcp remove calendly -s user
claude mcp add --transport http calendly https://mcp.calendly.com -s user \
  --callback-port <fixed-port> --client-id <manually-registered-client-id>

This moves status from ✘ Failed to connect to ! Needs authentication and lets the browser OAuth flow proceed normally.

Proposed fix

1. Strip/replace parentheses in the hardcoded client_name template (e.g. Claude Code - ${serverName} or Claude Code ${serverName} — both accepted by Calendly).
2. Surface the server's error_description/errors object from invalid_client_metadata responses instead of a bare SDK auth failed: — this is what actually blocked diagnosis.

Additional observation (possibly a separate bug)

After completing OAuth via the workaround above, the connector authenticated successfully and tools loaded, but shortly after in the same session, claude mcp get calendly reverted to ! Needs authentication and a tool call returned "requires re-authorization (token expired)". This looks like it may be the same class of issue as #52565 (custom/non-managed MCP connector OAuth tokens not persisting/refreshing correctly), rather than the DCR bug this issue is about — flagging for triage, not asserting it's the same root cause.

Related

• #59445 — this exact bug, auto-closed by inactivity bot, not fixed
• #52565 — possibly related to the token-persistence observation above