Token-in-URL custom connector: connects and lists tools, but tools are never injected into conversations (regression, ~June 2026)

## Summary
A custom **remote MCP connector** that authenticates via a **token embedded in the URL** (e.g. `?key=…`, because the connector UI provides no API-key/bearer field) shows as **Connected** and populates its tool list, but in conversations the model reports its tools are unavailable and never calls them. A connector using **OAuth** on the same account works normally. This previously worked with token-in-URL; it regressed.

## Environment
- Claude Desktop (latest) **and** claude.ai web — identical behavior on both.
- Broken connector: self-hosted remote MCP server (~32 tools), streamable-HTTP, HTTPS, auth = token in the URL query string (the "Add custom connector" dialog offers only a URL field plus optional OAuth Client ID/Secret — there is no header/API-key field).
- Working connector: a different remote MCP server on the same account that uses **OAuth**.

## Expected
A connected custom connector's tools are injected into the conversation and callable, regardless of whether auth is OAuth or a token carried in the URL.

## Actual
- Settings shows the connector **Connected**; tool list is fetched successfully.
- In a chat the model says the connector's tools "aren't showing up as directly callable" and falls back to its own memory; it **never emits a tool call**.
- Persists when it is the **only** connector enabled (not a tool-count/budget cap).
- Persists after fully **removing and re-adding** the connector.
- Only the **OAuth** connector's tools get injected; the **token-in-URL** connector's do not.

## Server-side evidence
Server request logs during a failing attempt show the Claude client issuing `tools/list` **with no preceding `initialize`** and **no `tools/call`**, ever.

A **reference MCP client** (official Python SDK, `streamablehttp_client`) pointed at the **identical URL (token in the query string) and no header** completes the full handshake every time: `initialize` → `tools/list` (32 tools) → `tools/call` (success). So the server, transport, TLS, and token-in-URL auth are all verified healthy end-to-end — only the Claude client never advances past `tools/list` for this connector.

## Ruled out
- Tool-budget cap — fails as the sole connector.
- Auth validity — the same URL+token authenticates a full session from a reference client; server returns all 32 tools and executes a tool call.
- Server/transport health — reference client succeeds through the same public URL.
- Stale connector state — remove + re-add, no change.

## Underlying gap
The connector UI has **no field for API-key / bearer auth** — only OAuth. Servers that require a static token are forced to bake it into the URL. That path used to work but now appears to be treated as display-only (lists tools, never injects them), while OAuth connectors work. Either restoring token-in-URL tool injection **or** adding a first-class custom-auth-header/API-key field would resolve it.

## Likely trigger (timing)
The regression coincides with **mid-June 2026**. On **June 18, 2026** the MCP OAuth authorization extension was declared stable and Enterprise-Managed Authorization launched, with the accompanying guidance that *"OAuth authentication is still required for connectors accessing private user data."* Direct usage of this token-in-URL connector dropped to near-zero the same week — suggesting that change also stopped **injecting tools** for non-OAuth (token-in-URL) connectors, while still showing them as Connected and listing their tools.

## Related (but distinct) issues
- **#479** — provably-healthy server, bad state not cleared by remove + re-add. Same theme, but here the client **does** reach the server (`tools/list` lands); it just never injects the tools.
- **#326** — custom connector works in Claude Code but fails on claude.ai. Same "works elsewhere, not claude.ai" pattern; but here there is **no** authorization error — the connector reports Connected and lists tools.
- **#402** — no non-OAuth / custom-auth option in the connector UI. Same underlying gap (no API-key/bearer field) that forces token-in-URL in the first place.

## Repro
1. Stand up a remote MCP server (streamable-HTTP, ~30 tools) over HTTPS that authenticates via a token in the URL query string.
2. Add it as a custom connector (URL only, no OAuth); confirm it shows **Connected** and lists tools.
3. In a new chat, ask the model to call one of its tools.
4. Observe: model says the tools aren't available; server logs show `tools/list` with no `initialize` and no `tools/call`.