Custom remote MCP connector: tools never surfaced to the model in claude.ai web, while the broker completes the full OAuth + MCP handshake server-side (same server works in ChatGPT + Claude Code)

## Summary

A Connected **custom** remote MCP connector (FastMCP, OAuth, Streamable HTTP, `stateless_http=True` + `json_response=True`) shows as Connected with all its tools listed in claude.ai **web** Settings, but its tools are **never handed to the model** in conversations — the model only sees first-party connectors (e.g. Notion, Gmail). The **same server with the same OAuth identity works in ChatGPT and in Claude Code's native MCP client.** Server-side access logs prove Anthropic's broker completes the full OAuth + MCP handshake and even issues tool calls, so the failure is host-side tool surfacing, not the server.

## Environment

- Custom remote MCP server: Python FastMCP on Starlette/uvicorn, Streamable HTTP at `/mcp`, `stateless_http=True`, `json_response=True`.
- Auth: OAuth 2.1 authorization-code + PKCE/S256, JWKS backed by AWS Cognito, refresh tokens enabled.
- Plan: Max (personal).
- Onset: ~2026-06-18 to 06-20 (the connector worked before this window).

## What I verified server-side (healthy and unchanged)

1. **Healthy:** valid TLS; unauthenticated `POST /mcp` returns `401` with a correct RFC-9728 `WWW-Authenticate` header + `resource_metadata` pointer; both `/.well-known/oauth-protected-resource` and `/.well-known/oauth-authorization-server` return `200` and are well-formed.
2. **OAuth / identity provider unchanged:** the OAuth app-client config was last modified ~1 month before onset; audit logs show no auth-relevant change in the window; recent identity-provider updates are idempotent CI re-applies (identical request parameters across deploys).
3. **The broker completes the handshake AND calls tools — the server returns success.** Load-balancer access logs for a reconnect show, from Anthropic broker egress IPs (`160.79.106.x`, User-Agent `Claude-User`):

```
POST /oauth/token 200 <- fresh token minted
POST /mcp 200 <- initialize
POST /mcp 202 <- notifications/initialized (handshake completed)
POST /mcp 200 xmany <- tool list/calls, all succeed
```

So `/oauth/token`, `initialize`, `notifications/initialized`, and the subsequent `/mcp` calls all succeed at the server — yet the tools never appear to the model in chat.
4. **Works in other clients:** the identical server + OAuth works in ChatGPT (`openai-mcp/1.0.0`, 200s in the same logs) and in Claude Code's native MCP client (tools load and execute).

## Expected vs actual

- **Expected:** a Connected custom connector's tools are loaded into the conversation's tool set, the way first-party connectors are.
- **Actual:** the tools are never surfaced to the model in claude.ai web; only first-party connectors (Notion, Gmail) appear.

## Likely area

This matches the recent web-only connector cluster (#470, #471, #472, #473, #474) and the tool-discovery issue `anthropics/claude-code#69686`. The distinguishing factor appears to be **custom vs published/directory** connectors: the tool-*calling* runtime is documented as identical between the two, but the tool *surfacing/discovery* layer — exactly where published and custom connectors differ — is where this fails.

## Repro

1. Add a custom remote MCP connector (FastMCP, `stateless_http=True` + `json_response=True`, OAuth) in claude.ai web on a Max plan.
2. Complete the OAuth flow; the connector shows Connected with its tools listed in Settings.
3. Start a new chat: the model does not have the connector's tools (only first-party connectors surface).
4. Connect the same server in ChatGPT or Claude Code: tools load and execute normally.

## Ask

Surface Connected custom-connector tools to the model in claude.ai web conversations, on par with directory connectors. Happy to provide load-balancer access logs or an `ofid` for a specific failing connect on request.