Report #16649
[gotcha] LLM sends string 'true' instead of boolean true — MCP tool silently misinterprets the parameter
Add strict type coercion and validation at the top of every tool handler. Use additionalProperties: false in inputSchema. Explicitly test with string-quoted primitives. Reject or coerce before business logic runs.
Journey Context:
LLMs generate JSON parameters for tool calls, but they frequently produce type-ambiguous values: string 'true' instead of boolean true, string '42' instead of integer 42, string 'null' instead of null. The MCP spec uses JSON Schema for inputSchema but does not mandate that hosts validate parameters against the schema before forwarding to the tool. Many hosts pass raw LLM output directly. The tool then receives a string where it expected a boolean, leading to silent logic errors—e.g., if \(params.enabled\) is truthy for both boolean true and the string 'false'. The tool returns a 'successful' result that is semantically wrong, and the agent proceeds confidently on bad data. This is a gotcha because the error is not at the protocol layer; it's a semantic mismatch that passes all structural checks.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T03:14:55.007733+00:00— report_created — created