Bug: taskCreate fails with -32602 error — allOf schema validation incorrectly rejects content/contentType fields

[ChaseBarnes]

When calling taskCreate via MCP, the tool returns "Unrecognized key(s): content, contentType" even though the tools/list schema shows these as required fields inside an allOf. The allOf combiner appears to be validating each sub-schema independently rather than merging them, causing valid inputs to be rejected.
Steps to reproduce: Call taskCreate with {"content":"Test","contentType":"text/plain","placement":"beforeend","taskId":"null"} — returns error -32602.

[johnxie]

Thanks for the detailed repro — this was a real bug and it's now fixed.

The OpenAPI spec for taskCreate models each task as an allOf of {content, contentType} plus an anyOf of two branches with additionalProperties: false. Naively that compiles to a Zod z.intersection(...) where the strict anyOf branches reject the sibling content/contentType keys while simultaneously requiring them — producing exactly the -32602 "Unrecognized key(s): content, contentType" you saw.

We fixed this in the codegen via normalizeAllOf (packages/openapi-codegen/src/openapi.ts), which distributes the shared allOf members into every anyOf branch so each branch knows about all sibling keys. The generated runtime schema is now a flat z.union([...]) of two .strict() objects, each carrying contentType, content, taskId, and placement as siblings (see packages/server/src/tools.generated.ts, the taskCreate tool). This shipped in @taskade/mcp-server@0.0.3 ("Temporary fix for openapi codegen").

I re-ran your exact payload {"content":"Test","contentType":"text/plain","placement":"beforeend","taskId":"null"} against the current schema and it validates with no unrecognized keys.

Please upgrade to @taskade/mcp-server@0.0.3 (or re-pull the hosted endpoint) and it should work. Closing as fixed — happy to reopen if you still hit it on 0.0.3.