A client receives two tools. The first tool's inputSchema has type, properties and required keywords but no $schema keyword. The second tool's schema declares $schema pointing at draft-07. How should the client interpret the two schemas?
Select an answer to reveal the explanation.
Short Explanation
No $schema? Then you read it as JSON Schema 2020-12, full stop. A schema that names draft-07 gets validated as draft-07, so long as your client supports it. Don't fall for the idea that draft-07 is the fallback.
Full Explanation
MCP uses JSON Schema throughout the protocol and sets a clear default: when a schema does not include a $schema field, it is interpreted as JSON Schema 2020-12. A schema MAY include $schema to name a different dialect, and implementations MUST validate each schema according to its declared or default dialect. Every implementation MUST support 2020-12 and SHOULD document which additional dialects it supports, so the draft-07 schema is validated as draft-07 by a client that implements that dialect. Treating draft-07 as the default reverses the rule; the specification names 2020-12 and also recommends it for new schemas. Rejecting a schema for lacking $schema is wrong because omission is the normal case and simply triggers the default; the spec's own tool examples omit the keyword. Skipping validation when no dialect is named would turn the most common schema shape into an unchecked one, which defeats the purpose of input validation. Exam caveat: a client that meets a dialect it does not implement must handle that gracefully with an error stating the dialect is unsupported, rather than guessing. Operational check: confirm the validator defaults to 2020-12 for schemas without $schema, honors an explicit $schema, and documents the dialects it supports beyond 2020-12.