MCP schema normaliser skips a tool whose parameter is anyOf [string, string[]] (DeepWiki ask_question)

[CybotTM]

Importing https://mcp.deepwiki.com/mcp on the demo (nr-llm 0.31.1) reports "ask_question" has no usable parameter schema and was skipped — the other two tools import. Its schema: repoName: {anyOf: [{type: string}, {type: array, items: {type: string}}]}, question: string. anyOf of a scalar and its array form is a common shape in public servers; the normaliser could represent it as the array form (or the first scalar) with the description carried over, rather than dropping the tool. Refusing an unrepresentable schema is ADR-161's rule and right for genuinely foreign shapes; this one is representable. Repro: tools/list against the server above.

[CybotTM]

Fixed on main by #853, though by a different route than this issue proposed.

Rather than representing the union as one of its members (the array form, or the first scalar), the import now carries anyOf — along with oneOf, allOf and not — to the provider verbatim. The rule these keywords were caught by protects against dropping a constraint, because a schema missing it permits calls the server rejects. Carrying one unchanged never drops it, and ToolSpec::toArray() puts the stored schema into the provider payload as-is, so what the server declared is what the model sees. Collapsing the union to one member would have been the lossy option: a caller passing the other shape would then be refused by our own schema.

What stays refused is what genuinely cannot be represented: $ref/$defs (the definition block is not carried, so the pointer would arrive dangling) and the draft-2019/2020 applicators (no dependable provider support). ADR-161's rule is intact; the line just runs between self-contained and not.

Verified with this issue's own case: McpSchemaNormalizerTest::aRealWorldUnionSchemaIsCarriedThrough carries DeepWiki's ask_question schema verbatim from the server's tools/list response and asserts the anyOf block survives the import, not merely that the tool is no longer skipped.

Separately, #849 made the skip message name the keyword, so the next tool that genuinely cannot be represented says why instead of reporting an unactionable "no usable parameter schema".