{"version":"2.1.248","anchor":"mcp-servers-that-flood-the-connection-are-now-disconnected-i","canonical_anchor":"mcp-servers-that-flood-the-connection-are-now-disconnected-i","heading":"MCP servers that flood the connection are now disconnected instead of eating memory","tier":"notice","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/mcp-servers-that-flood-the-connection-are-now-disconnected-i","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### MCP servers that flood the connection are now disconnected instead of eating memory\n\nMCP servers that flood the connection are cut off instead of endlessly eating memory.\n\n**What**\n\nTwo new errors cut off a misbehaving MCP server: one for an oversized HTTP response body, one for a server that writes logs to stdout instead of stderr and so never produces a message boundary. Before this, that output accumulated without limit.\n\n**Details**\n\n- The stdio transport records the overflow error and closes the connection on the next tick rather than mid-read.\n- The stdout error message names the likely cause directly, so the fix is to move server logging to stderr.\n\n**Evidence**\n\n`without a JSON-RPC message boundary. The server is likely writing logs or other non-protocol data to stdout instead of stderr.`\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 2\/5"}