v2.1.101 regression: MCP tools not exposed to model when server loaded via --dangerously-load-development-channels

Resolved 💬 2 comments Opened Apr 12, 2026 by ilanoh Closed Jun 25, 2026

Description

When an MCP server is loaded via --dangerously-load-development-channels server:<name>, the server's tools are no longer exposed to the model in v2.1.101. They were accessible in v2.1.100.

Reproduction

  1. Register an MCP server in .mcp.json that declares both tools: {} and experimental: { "claude/channel": {} } capabilities
  2. Launch Claude Code with --dangerously-load-development-channels server:<name> -- "<prompt asking to call a tool>"
  3. /mcp shows the server as ✔ connected with all tools listed
  4. The model reports it has no access to any tools from that MCP server — tools do not appear in the deferred tool index or in the direct tool list

Expected behavior

The MCP server's tools should be callable by the model (as they were in v2.1.100), while also receiving inbound channel notifications.

Actual behavior

  • /mcp → server connected, tools listed ✓
  • Model → "I don't have access to [server] MCP tools" ✗
  • ToolSearch with select:mcp__<name>__<tool> → no results ✗

Analysis

Binary string diffing between 2.1.100 and 2.1.101 shows:

  • New identifier regularMcpConfigs in 2.1.101 — MCP connection init was refactored from inline code to extracted helper functions (z6K/w6K). The configs are now split into regularMcpConfigs and claudeaiConfigs categories.
  • In 2.1.100, all MCP configs were passed to the same connection function. In 2.1.101, regularMcpConfigs appears to be a filtered subset that may exclude channel-loaded servers, so their tools never enter the model's tool index.
  • The channel gate function itself (qK_/z4_) is identical between versions — the regression is in the upstream config partitioning, not in the gate logic.
  • New exports: createMCPServer, applyMcpUpdate, McpConfigs, McpUpdate
  • New telemetry: tengu_mcp_directory_bff, tengu_mcp_directory_visibility, tengu_mcp_registry_fetch

Workaround

Pin the launcher to the 2.1.100 binary:

exec /path/to/versions/2.1.100 --dangerously-load-development-channels server:<name> -- "$PROMPT"

Environment

  • macOS (arm64)
  • Claude Code v2.1.101 (regression), v2.1.100 (working)
  • MCP SDK @modelcontextprotocol/sdk v1.28.0
  • Node.js v25.9.0

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗