[BUG] Claude Desktop 1.1.3189: MCP tools/list response silently dropped above ~2,500 bytes (Windows)

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?

Claude Desktop 1.1.3189: MCP tools/list response silently dropped above ~2,500 bytes (Windows)

Environment

• Claude Desktop version: 1.1.3189 (auto-updated from 1.1.2998 on ~2026-02-14)
• OS: Windows 11 Pro 10.0.26200
• Node.js: v24.13.1
• MCP SDK: @modelcontextprotocol/sdk v1.26.0
• Transport: stdio

Description

After Claude Desktop auto-updated from 1.1.2998 to 1.1.3189, a custom MCP server's tools stopped appearing in the UI. The server logs confirm the tools/list JSON-RPC response is sent successfully over stdio and Desktop receives it — but the UI shows zero tools.

Through systematic binary search testing, the issue was isolated to the byte size of the tools/list response. The same server code that worked on 1.1.2998 (~6KB tools/list response) fails silently on 1.1.3189.

Reproduction Steps

1. Create an MCP server (stdio transport) with 11 tools and standard JSON Schema inputSchema definitions including property descriptions
2. Run on Claude Desktop 1.1.3189 (Windows)
3. Observe: zero tools appear in UI despite server logs showing successful tools/list response delivery

Binary Search Evidence

Used a CW_MAX_TOOLS env var to serve subsets of the tool list and measured JSON-RPC response sizes:

| Tools served | Response bytes | Result |
|---|---|---|
| 1 | ~600 | Works |
| 3 | ~1,400 | Works |
| 4 | ~2,768 | Fails (0 tools) |
| 6 | ~4,466 | Fails (0 tools) |
| 11 (all) | ~5,958 | Fails (0 tools) |

After stripping all property descriptions and minimizing tool description strings (keeping schemas valid), the full 11-tool response was reduced to 2,507 bytes:

| Tools served | Response bytes | Result |
|---|---|---|
| 11 (compact) | 2,507 | Intermittent — worked once, then failed on subsequent restarts |
| 11 (verbose) | 5,831 | Always fails |

The threshold appears to be approximately ~2,500 bytes for the complete tools/list JSON-RPC response.

Key Observations

1. Silent failure — No error shown to the user. The server appears connected (green indicator) but tools list is empty.
2. Protocol-level delivery confirmed — Server logs show Desktop sends tools/list request and the server responds with all tools. The response is sent successfully over stdio.
3. Intermittent at the boundary — At exactly 2,507 bytes, the same response works on some restarts and fails on others, suggesting a race condition or timing-dependent buffer.
4. Worked on 1.1.2998 — The identical server with ~6KB tools/list response worked perfectly on the previous Desktop version.
5. Not schema-related — Tested with and without type: "array" properties, with and without property descriptions. The determining factor is total byte size, not schema content.
6. Separate minimal server (3 tools, ~800 bytes) always works on the same Desktop instance, confirming the MCP connection itself is functional.

Compact Tool Definition Pattern (for reference)

To get under the threshold, all property descriptions had to be stripped:

const S = (props: Record<string, any>, req: string[]) => ({
  type: "object" as const, properties: props, required: req
});
const str = { type: "string" as const };
const num = { type: "number" as const };
const bool = { type: "boolean" as const };

// Example tool — no property descriptions, minimal tool description
{ name: "search", description: "Search CW entities.",
  inputSchema: S({ entity: str, query: str, limit: num }, ["entity", "query"]) }

This works but is a significant regression — property descriptions are important for model accuracy.

Expected Behavior

The tools/list response should be processed regardless of byte size (within reasonable limits). The previous version (1.1.2998) handled ~10KB+ responses without issue.

Possibly Related Issues

• #25706 — "Searched available tools" regression introduced in 1.1.3189
• #26094 — Object parameter serialization bug in 1.1.3189
• #22299 — Electron IPC EventEmitter leak dropping MCP responses (Windows)

What Should Happen?

Expected Behavior

The tools/list response should be processed regardless of byte size (within reasonable limits). The previous version (1.1.2998) handled ~10KB+ responses without issue.

Error Messages/Logs

Steps to Reproduce

Reproduction Steps

1. Create an MCP server (stdio transport) with 11 tools and standard JSON Schema inputSchema definitions including property descriptions
2. Run on Claude Desktop 1.1.3189 (Windows)
3. Observe: zero tools appear in UI despite server logs showing successful tools/list response delivery

Binary Search Evidence

Used a CW_MAX_TOOLS env var to serve subsets of the tool list and measured JSON-RPC response sizes:

| Tools served | Response bytes | Result |
|---|---|---|
| 1 | ~600 | Works |
| 3 | ~1,400 | Works |
| 4 | ~2,768 | Fails (0 tools) |
| 6 | ~4,466 | Fails (0 tools) |
| 11 (all) | ~5,958 | Fails (0 tools) |

After stripping all property descriptions and minimizing tool description strings (keeping schemas valid), the full 11-tool response was reduced to 2,507 bytes:

| Tools served | Response bytes | Result |
|---|---|---|
| 11 (compact) | 2,507 | Intermittent — worked once, then failed on subsequent restarts |
| 11 (verbose) | 5,831 | Always fails |

The threshold appears to be approximately ~2,500 bytes for the complete tools/list JSON-RPC response.

Key Observations

1. Silent failure — No error shown to the user. The server appears connected (green indicator) but tools list is empty.
2. Protocol-level delivery confirmed — Server logs show Desktop sends tools/list request and the server responds with all tools. The response is sent successfully over stdio.
3. Intermittent at the boundary — At exactly 2,507 bytes, the same response works on some restarts and fails on others, suggesting a race condition or timing-dependent buffer.
4. Worked on 1.1.2998 — The identical server with ~6KB tools/list response worked perfectly on the previous Desktop version.
5. Not schema-related — Tested with and without type: "array" properties, with and without property descriptions. The determining factor is total byte size, not schema content.
6. Separate minimal server (3 tools, ~800 bytes) always works on the same Desktop instance, confirming the MCP connection itself is functional.

Compact Tool Definition Pattern (for reference)

To get under the threshold, all property descriptions had to be stripped:

const S = (props: Record<string, any>, req: string[]) => ({
  type: "object" as const, properties: props, required: req
});
const str = { type: "string" as const };
const num = { type: "number" as const };
const bool = { type: "boolean" as const };

// Example tool — no property descriptions, minimal tool description
{ name: "search", description: "Search CW entities.",
  inputSchema: S({ entity: str, query: str, limit: num }, ["entity", "query"]) }

This works but is a significant regression — property descriptions are important for model accuracy.

Expected Behavior

The tools/list response should be processed regardless of byte size (within reasonable limits). The previous version (1.1.2998) handled ~10KB+ responses without issue.

Possibly Related Issues

• #25706 — "Searched available tools" regression introduced in 1.1.3189
• #26094 — Object parameter serialization bug in 1.1.3189
• #22299 — Electron IPC EventEmitter leak dropping MCP responses (Windows)

Reproduction Steps

1. Create an MCP server (stdio transport) with 11 tools and standard JSON Schema inputSchema definitions including property descriptions
2. Run on Claude Desktop 1.1.3189 (Windows)
3. Observe: zero tools appear in UI despite server logs showing successful tools/list response delivery

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.1.2998

Claude Code Version

Claude Desktop 1.1.3189 (Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_