{"version":"2.1.290","anchor":"mcp-http-responses-size-cap-gzipdeflate-handling-brzstd","canonical_anchor":"mcp-http-responses-size-cap-gzipdeflate-handling-brzstd","heading":"MCP servers over HTTP get response size limits and a clear error for br or zstd","tier":"notice","area":"MCP","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/mcp-http-responses-size-cap-gzipdeflate-handling-brzstd","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### MCP servers over HTTP get response size limits and a clear error for br or zstd\n\nClaude Code now caps MCP HTTP response sizes, unpacks gzip and deflate itself, and refuses responses compressed with br or zstd\n\n**Unclear.** The size limits are not known, and it is not settled in which cases Claude Code does the unpacking itself.\n\n**What**\n\nMCP servers are outside tools you connect to Claude Code, and some of them talk to it over the web (HTTP). Claude Code now handles their responses with new rules:\n\n- Responses compressed with gzip or deflate are unpacked by Claude Code itself.\n\n- Responses compressed with br or zstd are refused, with a message saying the server sent a response compressed with br or zstd, that Claude Code reads only gzip and deflate, and that it did not read the response.\n\n- Response bodies and streamed events have a size cap, counted after unpacking, and going over it ends in an error.\n\nThe plain HTTP connection and the connection used for claude.ai connectors now share the same tracking of whether a connection is alive.\n\n**Why**\n\nA server that replies in a compression format Claude Code can't read now fails with a clear explanation, and very large replies from an MCP server can no longer grow without limit.\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}