Custom connector fails for unchanged, verified-healthy MCP server (started 2026-08-06); validator probes with browser Accept and never completes the MCP handshake

### What happened?

Since 2026-08-06 our custom connector fails with "Couldn't register with the connector's sign-in service" / "Connection issue — Couldn't connect to the server". Evidence the server is healthy:

- Server code byte-identical since 08-04 (84 tools; tools/list = 56,972 bytes, identical). Reverting to the known-good state did not help.
- The official MCP Inspector connects and lists all 84 tools over the same public URL (self-hosted MCP server behind Tailscale Funnel, valid HTTPS).
- Server-side request logging captured the connector's only contact at the exact time of an attempt: a single GET with `Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8` and UA `Mozilla/5.0 ... facebookexternalhit/1.1 Facebot Twitterbot/1.0`, which received HTTP 200 with a correct `text/event-stream` response (`event: endpoint` emitted immediately). The client never followed up — no POST, no initialize, no second request — and the UI declared the URL "not a valid MCP server".
- Earlier logs (08-07) show the same browser-style probe getting 406 from the MCP SDK's literal Accept-substring check on the streamable-HTTP endpoint, while the broker's POST /oauth/register did reach the box (201). The connector never sent a single POST to the MCP endpoint in any attempt.
- Tried: token-in-path (no OAuth), full OAuth shim (metadata/register/authorize/token, RFC 8414 path-aware), fresh alternate URLs to bypass caching, stateful SSE mode, and the legacy HTTP+SSE transport. The failure is identical across all — consistent with a cached negative verdict per account (#479, #704) and the 08-06/07 regression cluster (#794, #798–#806).

Failed-attempt references:
ofid_c94770796ad2aa3b · ofid_436ad1c9049a8b05 · ofid_948c5e6ac43980f7 ·
ofid_272b55d7e06b0928 · ofid_f4ea818327cfaab0 · ofid_1796e3f35e406afc ·
ofid_0bf89551be316ab7

Final test: probe GET returns 200, full OAuth (metadata/register/authorize/token) is live and verified, fresh connector record, fresh URL path — the connector still fails with "Couldn't register with the sign-in service". Server-side conditions are exhausted.

Server-side request logging confirmed the broker reported "Couldn't register with the sign-in service" without ever calling /oauth/register — zero inbound requests during the failing attempts, matching #374. Timing correlates with the Aug 5 outage that included OAuth issues on claude.ai.

Confirmed just now: claude mcp add --transport http connects immediately (✔ Connected) to the same URL the web connector rejects — the "works in Claude Code, fails in claude.ai" pattern of #326/#803.

Related (same family, distinct evidence): #704 / #479 (cached negative verdict), #374 (zero inbound), #326 / #803 (works in Claude Code, fails in claude.ai), #784 (OAuth-forcing). This report adds server-side request logging proving the broker never contacted the server, across 7 failed attempts in 4 configurations.

### What did you expect to happen?

The connector should register and connect successfully, as it did for months before 2026-08-06. At minimum, the broker should attempt to contact the server before reporting a sign-in failure — our logs show it never did.

### Steps to reproduce

1. Add a custom connector pointing to a self-hosted MCP server (streamable HTTP, valid HTTPS cert, authless with secret path).
2. Leave OAuth fields empty.
3. UI reports "Couldn't register with the sign-in service" while server logs show zero inbound OAuth/MCP requests from the broker.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell

```

### Additional context

_No response_