As an SDK author exposing tools via MCP, I want to express "exactly one of fields A, B" as JSON Schema oneOf. The spec permits this, but in practice the LLM tool-calling layer downstream of MCP clients (Claude, GPT-4 family) does not reliably consume oneOf — models silently ignore the constraint or refuse the tool call. I ended up flattening union-types into separate tools or sentinel-string discriminators across anchor-x402-mcp (14 tools).
This isn't a protocol bug — the spec is internally consistent — but there's a documentation gap between "the spec allows this JSON Schema construct" and "implementers can actually use it in production." A SEP-level note listing which constructs are reliably consumed today (enum: yes, oneOf/anyOf: no, if/then: no, etc.) would save the next implementer from discovering it through failed tool calls.
As an SDK author exposing tools via MCP, I want to express "exactly one of fields A, B" as JSON Schema
oneOf. The spec permits this, but in practice the LLM tool-calling layer downstream of MCP clients (Claude, GPT-4 family) does not reliably consumeoneOf— models silently ignore the constraint or refuse the tool call. I ended up flattening union-types into separate tools or sentinel-string discriminators acrossanchor-x402-mcp(14 tools).This isn't a protocol bug — the spec is internally consistent — but there's a documentation gap between "the spec allows this JSON Schema construct" and "implementers can actually use it in production." A SEP-level note listing which constructs are reliably consumed today (
enum: yes,oneOf/anyOf: no,if/then: no, etc.) would save the next implementer from discovering it through failed tool calls.