Default JSON Schema validators reject declared draft-07, which the spec permits

[chelojimenez]

Both default validators (AjvJsonSchemaValidator and CfWorkerJsonSchemaValidator) throw on any tool schema that declares a non-2020-12 dialect:

Tool 'example' has an invalid outputSchema: JSON Schema declares an unsupported dialect
("$schema": "http://json-schema.org/draft-07/schema#"). The default validator supports
JSON Schema 2020-12 only.

Per the spec, 2020-12 is only the default when $schema is absent — an explicitly declared draft-07 dialect is valid on all protocol versions (the spec's own examples include it). So schemas the spec permits currently hard-fail tools/call in the client.

The practical impact is wide: zod-to-json-schema, which v1 SDK servers use for outputSchema, stamps "$schema": ".../draft-07/schema#" on every schema. Any v2-SDK client talking to any v1-SDK server with an output schema fails on every tool call, with no server-side fix available short of rewriting the server.

Repro:

import { AjvJsonSchemaValidator } from "@modelcontextprotocol/client/validators/ajv";

new AjvJsonSchemaValidator().getValidator({
  $schema: "http://json-schema.org/draft-07/schema#",
  type: "object",
}); // throws "unsupported dialect"

Expected: validate the schema using the dialect it declares (or at minimum draft-07, given its ubiquity via zod), rather than rejecting it.

Seen on @modelcontextprotocol/client@2.0.0-beta.4. Happy to contribute a fix — we currently work around this with a dispatching validator that routes on the declared $schema.

[Sakshamm-Goyal]

I’d like to take this on with a narrow bug fix and regression coverage. I’ll first reproduce the declared draft-07 path in both default validators, then keep the change limited to dialect selection/registration required for standards-compliant validation. Please assign it to me if that approach is welcome; I’ll wait for assignment before implementation.