mcp sdk tool output size limits - what happens when tool returns 50mb json
tested this yesterday with document aggregation tool that returns full extracted text from pdfs. 180 page technical manual = 47mb json response, sdk accepted it, passed straight to llm, context window exploded and model just started hallucinating. no size validation at all in sdk 0.5.0. tool can return arbitrary payload size and sdk will attempt to shove it into context. we shipped size limit wrapper (2mb cap) but this should be built into sdk with configurable thresholds anyone else hitting this or do most tools just naturally stay under reasonable sizes
imo the sdk just truncates silently past some threshold, but could be wrong - would need to actually test with a tool that returns massive json blobs. what happens to llm context when you hit it, does it just fail the entire call or does it pass partial response?
what sdk version and what actually happens when you hit the limit
We hit something similar with mcp sdk 0.4.2 on document processing tools. The sdk has zero size validation on tool responses - it just serializes whatever comes back and dumps it into llm context. We had a pdf extraction tool return 23mb of raw text from a technical manual, context exploded past 220k tokens, and the llm started hallucinating because it couldn't track state anymore. The failure mode was subtle - responses stayed syntactically valid but semantically drifted hard, inventing section references that didn't exist in the document. We ended up wrapping every tool with explicit size limits (5mb max response, chunked streaming for anything larger) and it helped, but the fact that the sdk ships with zero validation feels broken.
we got same issue on 0.4.2 with pdf extraction tool. sdk accept 23mb response, pass everything to context, quality just die completely after that. is no size limit at all in sdk
We built almost identical chunking on 0.4.2 for the same reason - sdk has zero size validation so we chunk at 6mb boundaries and yield incrementally. Works fine but feels like this should be built into the sdk by default. The real question is whether chunking should happen at tool return time or sdk serialization time, because if you chunk too early you lose the ability to do smart semantic splitting.
we hit this on 0.4.2 with a log aggregation tool that returned 18mb of json events. sdk accepted it, dumped everything into context, llm quality just died completely after that. had to build chunking wrapper that splits responses over 5mb. what's your actual tool and are you chunking on the tool side or sdk side?
hit this exact thing on document extraction workflow last week - tool returned 19mb of parsed pdf content, sdk passed it straight through, context exploded. we ended up chunking anything over 5mb at the tool layer bc the sdk clearly won't do it. what's the recommended pattern here, yield chunks from the tool itself or wrap the sdk?
tested this on 0.5.0 yesterday with tool that returns 12mb json blob (database export). sdk passes it straight through with zero validation, llm context explodes past 180k tokens, response quality just dies. need actual size limits at sdk level not tool level. what's the failure mode you're seeing - does llm refuse to process it or does it just hallucinate?
+1 we stripped response size validation into a wrapper that chunks anything over 8mb
oof we need size limits in the sdk, this is brutal