Cowork silently caps a connector's tools at exactly 256 — tools past the cap are dropped with no warning (same endpoint loads all ~630 tools in Claude Code)

### What happened?

Cowork (Claude Desktop) silently truncates a remote MCP connector's tool list to **exactly 256 tools**. Tools past the 256th are never registered, never shown in the connector's tool settings, and cannot be invoked. No warning is surfaced anywhere that tools were dropped.

Our setup: a custom connector (Streamable HTTP, OAuth via an authorization-code flow brokered to our IdP) pointing at an internal LiteLLM MCP gateway that aggregates ~22 upstream MCP servers into a single endpoint, ~630 tools total. The gateway returns the full tool list in a single unpaginated `tools/list` response (no `nextCursor`), with tools grouped by upstream server, alphabetically by server prefix.

What Cowork shows for this connector: **exactly 256 tools** (the settings UI groups them as 145 read-only + 77 write/delete + 34 other). The composition matches "first 256 in response order" precisely:

- Servers early in the alphabet are fully present — cumulative 194 tools.
- The next server is **cut mid-server**: only ~62 of its tools appear.
- Every server alphabetically after it is entirely absent.

The truncation is deterministic: disconnecting and reconnecting the connector several times yields exactly 256 tools every time, same composition.

The same endpoint, same OAuth identity, connected from **Claude Code (CLI)** registers all ~630 tools (as deferred tools, loadable via tool search) and they invoke successfully. So the server side is healthy; the cap is in the claude.ai/Cowork connector layer.

This looks related in spirit to the `tools/list` pagination bugs previously fixed in Claude Code (#59538 in anthropics/claude-code) and reported for Desktop (anthropics/claude-code#66537), but it is a distinct defect: our server does **not** paginate — this is a hard cap applied to a single-page response.

### What did you expect to happen?

Either:
1. All tools exposed by the server are registered (Claude Code demonstrates this works fine at ~630 tools with deferred loading), or
2. If a platform limit exists, it is documented, and the UI clearly warns "N of M tools loaded — M−N dropped" instead of silently discarding them.

Silent truncation is the worst of both: the connector reports healthy, tool calls against the missing tools are simply impossible, and users burn hours debugging their gateway/server (we did).

### Steps to reproduce

1. Stand up a remote MCP server (Streamable HTTP) exposing more than 256 tools, returning them in one `tools/list` page (no `nextCursor`). An aggregating gateway (e.g. LiteLLM MCP gateway) in front of several large servers is an easy way to get there.
2. Add it to claude.ai as a custom connector and open a Cowork session.
3. Inspect the connector's tool list in settings, or ask the agent to use a tool that sorts late in the response order.
4. Observe exactly 256 tools registered; everything after position 256 is missing with no warning.
5. Disconnect/reconnect: same 256 every time.
6. Connect the same endpoint from Claude Code CLI: all tools register and invoke fine.

### Additional context

- Client: Claude Desktop / Cowork, macOS (current as of 2026-07-09)
- Transport: Streamable HTTP; OAuth (authorization code + PKCE, dynamic client registration against our broker)
- Server: LiteLLM-based MCP gateway, single-page `tools/list`, ~630 tools
- The number 256 (2^8) and its stability across reconnects strongly suggest an intentional or incidental hard cap rather than a timeout/race.