[BUG] Claude.ai MCP servers only partially loaded in v0.87 (regression from v0.81)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using the Claude.ai MCP server sync feature (importing pre-configured MCP servers from Claude.ai into Claude Code), only a subset of servers are loaded in v0.87.

I have 13 MCP servers configured in Claude.ai. In v0.87, only 3 of them are loaded — the remaining 10 are silently dropped with no error, warning, or explanation in the UI or in --debug log output.

What Should Happen?

All 13 MCP servers configured in Claude.ai should be loaded and available in the session, as they were in v0.81.

Error Messages/Logs

[from --debug log]
... listed 13 mcp servers
... [only 3 appear in the session]

The debug log confirms Claude Code discovered 13 MCP servers from Claude.ai but only 3 were actually loaded/presented. There is no log entry explaining why the other 10 were skipped, filtered, or failed to initialize — making this very hard to diagnose from the user side.

Steps to Reproduce

1. Configure 13 (or more) MCP servers in Claude.ai
2. Launch Claude Code — it should sync and load all Claude.ai MCP servers
3. Run with --debug to observe the loaded MCP server list
4. Observe that only 3 servers are loaded despite 13 being discovered in the debug log

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

0.81

Claude Code Version

0.87 (latest at time of report; confirmed working in 0.81)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

• Severity: High — core MCP integration is broken for users with more than ~3 Claude.ai MCP servers
• Workaround: Pinning to v0.81
• The silent drop (no log entry per skipped server) makes root-cause analysis impossible from the user side. Even if some servers are intentionally skipped (e.g. due to auth, timeout, or filter logic), a debug-level log entry per skipped server explaining why would be very helpful.