adobe-for-creativity MCP connector returns bare HTTP 403 (incl. on /.well-known/oauth-*) to Claude Code CLI — OAuth discovery can't start

[CoronovirusG10]

Summary

The adobe-for-creativity plugin (this repo, plugins/creative-cloud/adobe-for-creativity) ships a remote HTTP MCP connector:

{ "mcpServers": { "Adobe for creativity": { "type": "http", "url": "https://adobe-creativity.adobe.io/mcp" } } }

When loaded by the Claude Code CLI (not claude.ai web), the connector can never authenticate. Claude Code shows it as ! Needs authentication, and the OAuth flow fails at the very first step — protected-resource / authorization-server discovery — because the Adobe endpoint returns a bare HTTP 403 (no body, no WWW-Authenticate header) to every request from this client, including the public .well-known OAuth discovery documents. No consent screen or authorize URL is ever reached.

Per RFC 9728 / RFC 8414, those .well-known metadata documents must be publicly retrievable so a client can discover the authorization server and begin OAuth. A 403 on them stops discovery dead.

Environment

• Client: Claude Code CLI v2.1.177 (Node/undici HTTP stack)
• Plugin: adobe-for-creativity@claude-plugins-official v1.0.2
• Connector URL: https://adobe-creativity.adobe.io/mcp → AWS us-east-1 ELB (Adobe Ethos): 100.24.166.36, 3.81.197.218, 34.193.74.192
• Source network: a single UK residential IP (AS5089), no proxy/VPN. (Exact source IP redacted here for privacy — happy to provide it privately so you can check edge/WAF logs.)
• OS: Ubuntu 24.04

What happens (Claude Code's own MCP client logs)

No access token in storage
HTTP Connection failed after 344ms: Streamable HTTP error:
  Error POSTing to endpoint: (code: 403, errno: none)

And the discovery-stage failure from an earlier attempt:

Saving discovery state (authServer: https://adobe-creativity.adobe.io/)
No client info found
SDK auth error: HTTP 403: Invalid OAuth error response:
  SyntaxError: JSON Parse error: Unexpected EOF. Raw body:

The client receives 403, never 401, and sends no token — so this is not a token rejection; the request is blocked before the OAuth / application layer.

Reproduction (independent of Claude Code)

From the same machine/IP, with both curl's default UA and a real Chrome UA + Origin: https://claude.ai, with and without MCP headers (MCP-Protocol-Version: 2025-06-18, Accept: application/json, text/event-stream), and with and without a dummy Authorization: Bearer header:

GET  https://adobe-creativity.adobe.io/mcp                                      -> HTTP/2 403  (server: adobe, empty body, no WWW-Authenticate)
POST https://adobe-creativity.adobe.io/mcp  {jsonrpc initialize}                -> HTTP/2 403  (same)
GET  https://adobe-creativity.adobe.io/.well-known/oauth-protected-resource     -> HTTP/2 403  (same)
GET  https://adobe-creativity.adobe.io/.well-known/oauth-protected-resource/mcp -> HTTP/2 403
GET  https://adobe-creativity.adobe.io/.well-known/oauth-authorization-server   -> HTTP/2 403

Identical result across all three ELB nodes.

Why this looks like an edge/WAF block rather than a client/setup problem

From the same IP, in the same session:

• https://ims-na1.adobelogin.com/.well-known/openid-configuration → 200 (Adobe IMS is reachable)
• Another vendor's remote MCP OAuth server (Vercel) → 200 on its .well-known/oauth-protected-resource, and Claude Code successfully completes discovery for it (dynamic client registration + redirect URI) on this exact host — so the client's OAuth stack works.
• learn.microsoft.com/api/mcp and other remote MCP servers respond normally.

So the OAuth client works, the network works, and Adobe broadly works from this IP — but adobe-creativity.adobe.io specifically returns a contentless 403 to this client/egress, including on documents that are supposed to be public.

Expected behavior

Per the MCP authorization spec (RFC 9728 / 8414 / 6750): an unauthenticated request to the resource should return 401 with a WWW-Authenticate header pointing to the protected-resource metadata, and the .well-known/oauth-* documents should return 200 publicly, so an MCP client can discover the authorization server and start the OAuth code + PKCE flow.

Questions / ask

1. Is the Claude Code CLI a supported client for this connector, or is it intended only for claude.ai web / Claude Desktop / Cowork / mobile? The developer docs list those surfaces but not the CLI.
2. If direct (non-claude.ai-managed) clients are meant to work, the edge appears to apply a rule that 403s them — including on the public OAuth discovery docs. Could you serve the .well-known metadata publicly and return 401 + WWW-Authenticate on the resource so discovery can proceed?
3. If the connector is intentionally restricted to Anthropic-managed egress, please document that the bundled .mcp.json does not work in the Claude Code CLI, so users don't hit a silent "Needs authentication" dead-end.

Already ruled out

• Entitlement / paid plan — the 403 fires before any account/identity is presented; a free Adobe ID is documented to grant 50+ tools.
• Region / preview gating — the connector is global GA; Adobe IMS is reachable from this IP.
• Local OAuth/callback misconfig — another vendor's MCP OAuth clears discovery on this same host; the loopback-callback step is never even reached for Adobe.

[solimant]

@CoronovirusG10 - this plugin is intended for Claude Desktop/Claude Cowork. Are you seeing the issue there as well?