A tool's inputSchema contains no $schema field and is consumed by clients from two different vendors. How should both clients interpret the schema?
Select an answer to reveal the explanation.
Short Explanation
When a schema doesn't say which rulebook it follows, MCP picks one for you: JSON Schema 2020-12. That way both of your clients validate the same way. The traps are 'whatever each vendor likes' and 'it must declare a dialect.'
Full Explanation
MCP specifies how JSON Schema is used throughout the protocol. When a schema has no $schema field, it defaults to JSON Schema 2020-12. Schemas may declare a different dialect explicitly, implementations MUST support at least 2020-12, and clients and servers MUST validate schemas according to their declared or default dialect. Because the default is fixed by the specification, two independent clients reading the same undeclared schema apply the same rules, which is exactly what makes tool definitions portable between vendors. Letting each vendor apply its preferred draft would allow the same arguments to pass in one client and fail in another, defeating the purpose of a defined default. Requiring an explicit $schema is wrong; the field is optional, and its absence is precisely the case the default dialect covers. Naming draft-07 as the default is also incorrect; draft-07 may be declared explicitly, and the specification's own example shows such a schema, but the default and recommended dialect is 2020-12. Exam caveat: implementations must not automatically dereference $ref values that point to network URIs, so a schema relying on remote references may be rejected rather than silently fetched. Operational check: validate a sample of tool arguments against the schema with a 2020-12 validator in each client and confirm both produce identical pass or fail results.