A client that implements only JSON Schema 2020-12 receives a tool whose inputSchema declares, through $schema, an older dialect that the client has never implemented. What does the specification require of the client?

The JSON Schema usage rules require clients and servers to validate schemas according to their declared or default dialect, and they MUST handle unsupported dialects gracefully by returning an appropriate error indicating that the dialect is not supported. This keeps behavior predictable: the caller learns exactly why validation could not happen instead of receiving a silent and possibly wrong verdict. Validating the schema as 2020-12 anyway is incorrect because the default applies only when $schema is absent; an explicit $schema is a declaration that the client must respect, and keyword semantics differ between dialects. Treating the unknown dialect as permissive and accepting all arguments removes input validation entirely, the same failure the specification warns against for unresolved $refs, which SHOULD be rejected rather than silently treated as permissive. Stripping the keyword and resending changes the meaning of the schema and shifts a client obligation onto the server without any protocol basis. Exam caveat: implementations SHOULD document which dialects beyond 2020-12 they support, which helps server authors avoid this situation. Operational check: feed the client a tool whose $schema names an unimplemented dialect and confirm it surfaces a clear unsupported-dialect error and does not validate, accept or rewrite the schema.