[BUG] Custom remote MCP connectors intermittently lose all tools / aggregate tool list capped at exactly 256 across connectors — regression since ~mid-July 2026 (web + desktop, org + personal accounts)

Summary

Since roughly mid-July 2026 (last few days to a week), custom remote MCP connectors intermittently lose all of their tools. The failure has two observable shapes that alternate:

1. The connector collapses to a hard total of exactly 256 tools across all connected MCP servers (256 = 2^8), or
2. The connector fully drops — its tools disappear entirely and it shows as effectively disconnected.

Hitting "Refresh Tools" brings the full tool set back briefly, after which it re-collapses (to 256, or to zero for that server) within minutes to a couple of hours. This is a regression — the same connectors, same accounts, same servers worked reliably before mid-July.

Critically, this reproduces on both claude.ai (web) and the Claude desktop app, and on both an organization/admin account and a personal (non-org) account. Because it is not confined to a single client surface, this looks like an account-/server-side change, not a purely local client bug.

Affected surfaces

• claude.ai (web) — Connectors UI
• Claude desktop app (macOS) — Connectors UI, "Refresh Tools" control
• Both a Team/organization admin account and a personal account (personal account is not a member of the organization, yet is affected the same way)

Environment

• Platforms: claude.ai web and Claude desktop (macOS 26.x, arm64)
• Connector type: custom remote MCP servers (self-hosted aggregators, SSE transport, OAuth 2.1 + PKCE)
• Connector A advertises well over 1,000 tools (a large aggregator bundling many upstream tool servers)
• Connector B advertises ~425 tools
• Reference CLI build seen alongside: Claude Code 2.1.196
• Onset: approximately 2026-07-08 … 2026-07-14 (a few days to a week before this report)

Detailed symptoms

• Aggregate cap, not per-server. With a large connector active, the visible tool list settles at exactly 256 total. The number is suspicious: 256 = 2^8, i.e. it looks like a newly introduced hard limit on the number of tool definitions loaded, applied to the union of tools across all connected MCP servers rather than per server.
• Connectors evict each other. With two custom connectors configured, connecting or refreshing the second one causes the first one's tools to disappear, and vice versa. They effectively compete for a shared budget: whenever the combined advertised tool count exceeds the ceiling, one connector's tools are dropped so the surviving total lands at/under 256.
• Refresh is only a temporary fix. "Refresh Tools" repopulates the list (sometimes the full set, sometimes only a partial set and in a scrambled order), then it collapses again after some minutes/hours.
• Two failure modes alternate: capped-at-256 vs. fully-disconnected (all tools gone for that server).
• Ordering/categorization also disturbed. After a refresh the tools sometimes come back in a different order and/or all bucketed under "Other" (tool typing/categorization appears reset), separate from the count problem but observed in the same window.

Likely cause / hypothesis

1. A hard aggregate limit of 256 tool definitions appears to have been introduced client-/service-side, applied across all connected MCP servers combined. 256 = 2^8 is a strong tell for an intentional cap rather than a coincidental data value.
2. Onset coincides with a newly appeared organization-wide MCP permission/governance setting ("administrators can now define org-wide how permissions are granted on an MCP" — this control did not exist before). The timing suggests the same rollout that introduced org-level MCP governance also introduced (or newly enforced) the aggregate tool cap and/or a connector re-initialization path that drops tools.
3. Because a personal, non-org account is equally affected, the cap is not purely an org-policy artifact — it behaves like a global change to how connector tools are enumerated/loaded.

Steps to reproduce

1. Configure two custom remote MCP connectors whose combined advertised tool count clearly exceeds 256 (e.g. one large aggregator with 1,000+ tools plus a second with a few hundred).
2. Connect both and observe the total available tool count.
3. Note the total settles at exactly 256, and/or one connector's tools vanish.
4. Click "Refresh Tools" on the connector whose tools are missing → full set returns briefly.
5. Wait (minutes to a couple of hours) or refresh the other connector → the first connector's tools drop again / total returns to 256.
6. Repeat: the two connectors keep evicting each other; the state never stabilizes with the full tool set from both.

Expected behavior

All tools from all connected, healthy MCP connectors remain available and stable. If a deliberate tool-count ceiling exists, it should be documented, surfaced clearly to the user (a visible "X of Y tools loaded, limit reached" indicator rather than silent dropping), and ideally configurable / per-server prioritizable — not silently applied to the union of connectors so that they knock each other offline.

Actual behavior

Tools silently disappear or are capped at 256 across all connectors combined; connectors evict one another; "Refresh Tools" only restores the set temporarily; the state is unstable.

Impact

• Breaks automations/routines mid-run. A session or scheduled routine that depends on a specific tool intermittently finds that tool missing, so the work fails non-deterministically.
• Large connectors are effectively unusable, because their tools are the ones dropped once the combined ceiling is exceeded.
• No user-visible signal explains why the tools vanished, making it look like a connection failure rather than an intentional limit.

Notes / what we've observed

• Reproduces across web and desktop, org and personal accounts → points to a server-/account-side change rather than a single client build.
• Only started in the last few days to ~1 week (mid-July 2026); the same setup was stable before.
• Correlates with the appearance of a new org-wide MCP permission setting.

Ask

1. Is there a newly introduced aggregate cap of 256 tool definitions across all connected MCP connectors? If so, please document it and make it visible when reached.
2. If this is a regression, please treat the silent tool-dropping / connector mutual-eviction as a bug: connectors should not knock each other's tools offline, and "Refresh Tools" should not be required repeatedly.
3. Guidance for users running large remote MCP aggregators: recommended way to stay under any limit (per-server prioritization, tool filtering, etc.) would help until this is resolved.