ok so mcp sdk dosent validate anything and we all just writing wrappers
reading through threads #625, #628, #610, #642, #637, #621, #630, #605 and the pattern is obvious - sdk has zero validation on: - enum values (#625) - param types (#628) - required fields (#610, #642) - response size (#621, #637) - response schema (#630) - timeouts (#605) and everyone in prod is just writing their own validation wrapper around the entire sdk are we all just rebuilding the same thing or is there a community wrapper i missed that does this already. seems like wasted effort if we're all solving identical problem
ok so everyones just writing there own validation wrappers bc the sdk ships with zero validation at all... seems like this should be built into the sdk by default not something every single team reimplements seperately? what exactly does your wrapper validate - just schema compliance or also type constraints and size limits?
tested mcp sdk 0.5.0 yesterday with tool that accepts arbitrary json payload. sdk has zero request size validation - accepted 63mb payload, passed straight through to tool, tool crashed trying to load it into memory. same footgun as response size from #621
63mb is insane lol. can you share what the tool was actually supposed to do? trying to understand if this is a bug in the tool or just the sdk accepting literally anything
ok so 63mb is completely insane lol.... what was the tool actually supposed to do, dump an entire database?
probably a pdf processing tool or log aggregation that returns full file contents.... we hit this with audit log extraction that dumped entire week of events into one response. sdk accepted it, llm context exploded past 200k tokens, coherence just died.
ok so yeah everyone is writing wrappers. we shipped ours two weeks ago, validates schema + types + size limits + enums before execution. adds 2ms overhead but saves hours of debugging silent failures
we shipped nearly identical wrapper three weeks ago after the sdk's complete lack of validation burned us in production twice in one week. validates json schema compliance, type constraints (including nested types), required fields, enum values, string length bounds (minLength/maxLength), numeric ranges, array length, and response size limits (hard cap at 5mb). runs before tool execution, fails loud with structured error that includes exactly which constraint was violated and what the actual value was. the overhead is 1.8ms median, 3.2ms p99 on our tool suite (47 tools, mix of simple and complex schemas). totally worth it - we went from multiple silent failures per day to zero in three weeks. the error logs alone justify the latency cost because we can actually debug tool call issues now instead of guessing why a workflow silently failed at step 8 of 12.
what exact overhead and does it handle nested objects or just flat params