Skip to content

[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) #77704

Open

Description

@mguttmann

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.

Activity

  1. spencerburtonre commented on Jul 16, 2026

    @spencerburtonre

    Published directory connector (custom remote MCP, Streamable HTTP, OAuth 2.1 + PKCE). In claude.ai chat, shows Connected, surfaces zero tools. Our server logs show claude.ai completing the handshake and fetching tools/list (HTTP 200) plus the client receives the full tool list and discards it.

    Reproduces even with our connector as the sole connected connector (well under 256), so this is the "connector fully dropped" mode, not the count. A second custom MCP server on the same host (different tools) loads fine in the same chat. Works normally in Code, Cowork, ChatGPT, Perplexity, and Manus but fails only in claude.ai chat + desktop.

    Onset July 15th 2026, no server change on our end (A/B-removed prompts, icons, a free-form schema param and each confirmed delivered via tools/list 200, each dropped). Reproduced across org + personal accounts. Happy to share request logs / an ofid_.

  2. dawnpatrol04 commented on Jul 24, 2026

    @dawnpatrol04

    Independent corroboration from a self-hosted MCP hub — different account (personal, not org-affiliated), single custom remote server, streamable HTTP. Same hard 256 = 2^8 cap, but in a deterministic, alphabetical form that may help isolate the mechanism.

    Setup: one MCP server serving ~330 tools in a single un-paginated tools/list. Server-side DB + response verified complete.

    What the client keeps: exactly 256 tools — the alphabetically-first 256 by tool name. Every namespace sorting before the cut is byte-for-byte complete; the namespace straddling the boundary is truncated mid-way; everything after is dropped. Our management tools are served last in the response yet survive, because their names start with h — so the capping layer sorts by name, then truncates. That rules out transport truncation and server ordering. Same 256 survivors every session, across restarts and reboots.

    This looks like the non-intermittent form of the cap reported here: once a menu exceeds 256, the client silently keeps the alphabetically-first 256. Pagination is not a workaround (nextCursor ignored — #24785). Different account type, transport, and a single self-hosted server (not an aggregator) — so unlikely to be account/org-specific.

  3. JF-Lalonde commented on Jul 27, 2026

    @JF-Lalonde

    Observed this exact same issue in Claude Cowork anthropics/claude-ai-mcp#587 (comment)

  4. sjh9714 commented on Aug 24, 2026

    @sjh9714

    Maintainer disclosure: I maintain MCP Host Canary. AI assistance was used in its implementation and in preparing this comment; I reviewed the claims and links.

    A controlled no-auth Claude Web observation from 2026-08-24 adds a server-side data point to the tools/list→dispatch gap already reported above; it does not confirm the UI-visible exactly-256 cap. In a separate three-tool baseline run, one explicit canary_ping request executed its callback. In the limits run, Canary recorded two successful tools/list.response observations containing 258 definitions. Operator notes record two explicit requests for sentinel_257, but the strongest retained boundary remained tools/list.response and callback executions remained zero.

    This proves only that Canary produced 258-definition responses. It does not show how many definitions Claude retained or displayed, or why no call followed. The fixture also includes a 16,385-byte description at tool 258; the exact deployed commit and exact historical prompt text were not retained.

    In a separate same-day maintainer-run FastMCP 3.4.7 direct-client control against the current public fixture, the client listed all 258 definitions and executed sentinel_257. That is a fixture control, not a Claude compatibility result.

    Normalized evidence, caveats, and the prospective protocol. A new disposable run can be created from that page; keep its URL private while active and finalize it before sharing a receipt.

  5. iagowp-mthr commented on Oct 7, 2026

    @iagowp-mthr

    This is still happening

  6. SimonZeeck commented on Nov 3, 2026

    @SimonZeeck

    Same symptom here, but in my case the 256 cap looks per connector, not aggregate across connectors. Also reproduces on the mobile app (iOS, voice mode), observed 2026-11-03.

    Setup: one large custom remote MCP connector ("Greenroom", ~300 tools) plus ~15 other connectors (GitHub, Gmail, Vercel, Figma, Supabase, Smartsheet, HubSpot, Slack, a small custom one, etc.).

    What we see:

    • Greenroom is listed with exactly 256 tools, apparently the alphabetically-first 256. The last visible tool is rename_task_category; everything after it alphabetically (e.g. update_task, other update_* tools) is missing.
    • It's not just the listing: a tool search for the exact name mcp__Greenroom__update_task doesn't load it, even though other Greenroom tool descriptions reference update_task.
    • The tools that are visible work fine (e.g. list_todo_lists returns data).
    • Other connectors are unaffected and load completely, e.g. a small custom connector with 9 tools and Vercel with 247 tools. Around 820 tools are visible in total across all connectors, so this isn't an aggregate cap of 256.

    Ask: please document whether there's a per-connector limit of 256 tool definitions, and show it when it's hit instead of silently dropping tools. As in the original report, there's currently no visible sign that tools were dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:mcpbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions