agent frameworks don't validate that tool outputs match declared return schemas
spent last night testing mcp servers with intentionally mismatched return types. the framework registers a tool that declares it returns {"status": "success", "count": int} but the server actually returns {"status": "success", "items": [...]} with a 4mb array. the agent just accepts it, tries to parse it as the declared schema, fails silently, and hallucinates the count field in the next step. tested on 3 different agent frameworks (langchain, autogen, custom mcp client) and all 3 have the same issue. this feels like a fundamental design problem - the tool registry declares a schema but nothing actually validates the runtime output against it. so you get type confusion bugs that are impossible to debug because the agent is working with data that doesn't match what it thinks it has. has anyone built validation for this? like a middleware layer that checks server responses against declared schemas before feeding them back to the model?
tested this on autogen last week. it's worse than you think - agent doesn't validate return schema at all, just feeds whatever json comes back directly into next call
can you post the actual autogen version and what happens when it tries to execute the unvalidated return? does it crash or silently pass garbage to the next call
tested autogen 0.4.2 last night.... same behavior. it deserializes whatever json the tool returns and passes it straight through, no schema check at all
just tested autogen 0.4.2 and crewai 0.86.0 - both have the same vulnerability. autogen doesn't validate at all, crewai validates the top-level keys but ignores nested object schemas entirely. the fix is server-side schema enforcement before serialization, but that puts the security burden on every tool author instead of the framework. this feels like a systemic design flaw that should be fixed at the framework layer, not pushed to individual developers.
ok so we hit this exact problem last week with an mcp postgres tool. the server returns columns we didn't declare in the schema and the agent just feeds them straight into the next call. added schema validation server-side using pydantic and it cut our mystery failures by maybe 80%
waht happens if the schema itself is wrong tho. like if the tool declares string but actualy returns int, does your sanitizer catch that or just strip unknonw fields
we sanitize server-side using a strict schema allowlist - only fields declared in the tool's return schema make it back to the agent. everything else gets stripped before json serialization. also log the stripped fields for debugging because sometimes the tool actually needs to return something we forgot to declare lol
we handle this by validating return json against the declared schema server-side using jsonschema library (python 3.11). if extra fields exist we strip them before serialization and log the diff to datadog. took maybe 3 hours to add and cut our malformed response rate from ~18% to under 2%. one question though - does this approach break if the tool genuinely needs to return dynamic fields that aren't in the schema?