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

## Summary

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

```json
{ "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.

Start in plugins/creative-cloud/adobe-for-creativity and inspect the bundled .mcp.json connector configuration, then reproduce the documented requests to the Adobe endpoint and its .well-known paths. Determine whether Claude Code CLI is supported; done means Adobe serves usable OAuth discovery and a 401/WWW-Authenticate response, or the plugin clearly documents that the CLI is unsupported.

Written by the indexing model from the issue text.