›_ Claude Code Issues
Claude Code Issues / #86142

MCP servers declaring draft-07 outputSchema are entirely unusable: "unsupported dialect" rejected client-side before dispatch

Status Fixed / completed
Reported on v2.1.214
Maintainer reply ✓ Yes — bcherny
Workaround ✓ Mentioned in thread ↓
Activity 32 comments · opened Aug 12, 2026 · closed Aug 17, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Every tool on an MCP server that declares outputSchema with the JSON Schema draft-07 dialect is now unusable. The call fails at schema registration, before any request reaches the server, with:

Tool '<name>' 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; pass a pre-configured Ajv instance to AjvJs

This affects the entire server, not one tool: count, aggregate, find, and list-collections on mongodb-mcp-server all fail identically. The server process is never contacted — this is purely client-side.

The MCP specification does not require outputSchema to use 2020-12, and declaring $schema: draft-07 is valid. MongoDB has explicitly declined to remove the field (closed 2026-08-06, internal ref MCP-101), calling it "an internal field documented on the JsonSchema spec and it's standard." So this cannot be resolved server-side, and any MCP server using a draft-07 schema generator is affected — mongodb-mcp-server is likely just the most visible instance.

The error text itself (pass a pre-configured Ajv instance to AjvJs) reads like an internal Ajv message surfacing directly to users.

What Should Happen?

Claude Code should validate outputSchema documents that declare draft-07 (and ideally draft-04/06/2019-09), e.g. by registering the corresponding meta-schemas on the Ajv instance, or by falling back to skipping structured-output validation rather than disabling the tool entirely.

Disabling every tool on a server is a severe failure mode for what is a validator configuration gap — the previous behavior (accepting these servers) was strictly more useful.

Error Messages/Logs

Error: Tool 'count' 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; pass a pre-configured Ajv instance to AjvJs

Identical for aggregate, find, list-collections.

Steps to Reproduce

  1. Configure any MCP server whose tools declare outputSchema with "$schema": "http://json-schema.org/draft-07/schema#". Minimal config:
{
  "mongodb": {
    "command": "npx",
    "args": ["-y", "mongodb-mcp-server@2.1.0", "--readOnly"],
    "env": { "MDB_MCP_CONNECTION_STRING": "mongodb://127.0.0.1:27017" }
  }
}
  1. Call any of its tools. All fail with the error above; the server logs show no incoming request.

To confirm the payload is draft-07 independently of Claude Code, this script speaks JSON-RPC to the server over stdio and prints the declared dialects. It needs no reachable database — tools/list responds regardless:

import json, subprocess, sys, os

def probe(ver):
    env = dict(os.environ, MDB_MCP_CONNECTION_STRING="mongodb://127.0.0.1:27099/?serverSelectionTimeoutMS=200")
    p = subprocess.Popen(["npx", "-y", f"mongodb-mcp-server@{ver}", "--readOnly"],
        stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL, text=True, env=env)
    def send(o): p.stdin.write(json.dumps(o) + "\n"); p.stdin.flush()
    send({"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}})
    send({"jsonrpc":"2.0","method":"notifications/initialized"})
    send({"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}})
    tools = None
    try:
        for _ in range(200):
            line = p.stdout.readline()
            if not line: break
            try: m = json.loads(line)
            except: continue
            if m.get("id") == 2:
                tools = m.get("result", {}).get("tools", []); break
    finally:
        p.kill()
    withos = [t for t in tools or [] if "outputSchema" in t]
    dialects = {t["outputSchema"].get("$schema", "<none>") for t in withos}
    return f"v{ver}: {len(tools or [])} tools, {len(withos)} with outputSchema, dialects={dialects or '-'}"

for v in sys.argv[1:]:
    print(probe(v))

Output — note that the version working before the regression emits the identical payload:

$ python3 probe.py 1.14.0 2.0.0 2.1.0
v1.14.0: 16 tools, 13 with outputSchema, dialects={'http://json-schema.org/draft-07/schema#'}
v2.0.0:  18 tools, 15 with outputSchema, dialects={'http://json-schema.org/draft-07/schema#'}
v2.1.0:  18 tools, 15 with outputSchema, dialects={'http://json-schema.org/draft-07/schema#'}

Is this a regression?

Yes — this worked before and broke recently.

Last Working Version

Last successful MCP call: 2026-08-04. First failure: 2026-08-12. Same machine, same MCP config, unchanged throughout.

The MongoDB server was upgraded from 1.14.0 to 2.1.0 on 2026-08-11 (the config pins @latest), which initially looked like the cause. The probe above rules it out: 1.14.0 — the version in use during the working period — declares the same draft-07 outputSchema. The server payload is unchanged; the client's handling of it changed.

Claude Code Version

Claude.app 1.28929.0

Platform

Claude Desktop (macOS)

Operating System

macOS (Darwin 25.6.0, Apple Silicon)

Additional Context

Possibly related, same subsystem:

  • #76257 — outputSchema servers fail wholesale; validation appears to run against the whole CallToolResult envelope instead of structuredContent.
  • #80105 — tools declaring outputSchema are never dispatched to the server, while tools without it work on the same server.
  • #80402 — the inverse polarity: --json-schema rejects schemas declaring the 2020-12 meta-schema, reported as a regression since 2.1.214.

The presence of both polarities (draft-07 rejected here, 2020-12 rejected in #80402) suggests inconsistent meta-schema registration across the different Ajv instances in the codebase, rather than one isolated bug.

View original on GitHub ↗

32 Comments

amitfin · 18 days ago

Follow-up: I traced where the draft-07 dialect actually originates, and it significantly widens the scope of this bug.

It is not a MongoDB-specific choice. It is the default in the MCP TypeScript SDK. From @modelcontextprotocol/sdk@1.30.0, dist/esm/server/zod-json-schema-compat.js:

function mapMiniTarget(t) {
    if (!t)
        return 'draft-7';          // default when no target is passed
    if (t === 'jsonSchema7' || t === 'draft-7')
        return 'draft-7';
    if (t === 'jsonSchema2019-09' || t === 'draft-2020-12')
        return 'draft-2020-12';
    return 'draft-7';              // fallback
}

mongodb-mcp-server passes no target, so it inherits 'draft-7'. Under zod 4.4.3 that emits exactly the dialect this client now rejects:

target: 'draft-7'        -> "http://json-schema.org/draft-07/schema#"
target: 'draft-2020-12'  -> "https://json-schema.org/draft/2020-12/schema"

Implication for severity: any MCP server built on the TypeScript SDK with zod v4 that declares outputSchema and does not explicitly pass target: 'draft-2020-12' will emit draft-07 and be entirely unusable in Claude Code. That is the SDK's default path, so the affected set is likely broad rather than one vendor — mongodb-mcp-server is simply where I hit it.

This also means the fix cannot realistically be pushed onto server authors: it would require every SDK-based server to override an SDK default. Accepting draft-07 client-side (or registering the older meta-schemas on the Ajv instance) looks like the only fix with the right blast radius.

Tracking the server-side workaround at mongodb-js/mongodb-mcp-server#1427.

StableSoftwareDev · 18 days ago

Confirming this on Windows as well — it's labelled platform:macos, but it isn't platform-specific.

Same error, different server: mssql-mcp-node@3.0.0 (@modelcontextprotocol/sdk ^1.29.0, zod ^3.24.2), launched via npx -y. All six tools fail identically — execute_read_query, list_databases, list_views, list_tables, describe_database, describe_table — and four separately-configured instances of that server broke simultaneously.

Tool 'execute_read_query' 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; pass a pre-configured Ajv instance to AjvJs

Version data point in case it helps narrow the window: working on Claude Desktop 1.24012.9, broken on 1.28929.0, with no change to the MCP server, its version or its config in between — the app updated underneath it. Electron 42.7.0, app-bundled Node 24.18.0, Windows x64.

Also ruled out on this end:

  • Restarting the desktop app.
  • Refreshing the MCP tool list — re-read all tools, zero added or removed, so the schema is what the server has always advertised.
  • Updating the server. mssql-mcp-node@3.0.0 is current, and @modelcontextprotocol/sdk@1.30.0 still depends on zod ^3.23.8 and zod-to-json-schema ^3.24.1, both of which emit draft-07. There is no server-side version available today that emits 2020-12, so users can't work around this by upgrading — which is worth weighing when prioritising.

Agreed on the suggested fix: registering the draft-07 meta-schema on the Ajv instance, or skipping structured-output validation for an unrecognised dialect, both beat disabling the tool outright.

Vantso · 17 days ago

Reproducing with a different server family, which widens this beyond mongodb-mcp-server: an n8n instance-level MCP server (33 tools, built on the MCP TS SDK). All 33 tools fail identically — the message differs only by tool name. Verified on get_workflow_details, search_workflows, search_projects, get_sdk_reference, get_execution, execute_workflow. Same build 1.28929.0 (d1a6bc, built 2026-08-11T18:58:06Z), Windows x64, Electron 42.7.0, Node 24.18.0. Last known good on this end: 2026-08-11.

Transport does not matter either: here the server runs locally and is proxied into a cloud session over the desktop bridge, and it fails the same way — the schema is rejected at registration, so nothing is dispatched.

Three earlier reports that look like the same seam and are not linked here yet:

  • #41361 — 2.1.88 regression: a hard outputSchema guard replaced the graceful fallback that 2.1.87 had.
  • #25081 — client drops all tools of a server when outputSchema is present in tools/list. Closed as not planned.
  • modelcontextprotocol/mcpb#174 — Claude Desktop on Windows: schema compilation failures stop tools/call from reaching the server. Closed as not planned.

Counting this one, outputSchema handling has now failed fatally in four different ways. Each was addressed (or not) as its own case, and the fixes have not generalised. The fallback requested in this issue — skip validation rather than disable the tool — is the one change that would have covered all four.

SebCool · 17 days ago

Another data point, and one that widens the blast radius: Anthropic's own reference server is affected.

@modelcontextprotocol/server-filesystem@2026.7.10 (current), launched via npx -y, on Windows. All of its tools fail identically at registration:

Tool 'list_allowed_directories' 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; pass a pre-configured Ajv instance

Confirms @amitfin's root cause: the package itself contains zero draft-07 strings — the dialect comes from the SDK default. mapMiniTarget() in @modelcontextprotocol/sdk@1.30.0 returns 'draft-7' when no target is passed, and server-filesystem passes none. Worth noting for anyone grepping to confirm this on their own setup: the SDK source uses 'draft-7' (no leading zero), so grepping for draft-07 in dist/ returns nothing and looks like a clean bill of health.

Independent confirmation of @StableSoftwareDev's version boundary. Same transition observed here, with no change to any MCP server config:

| Date | Claude Desktop | server-filesystem |
|---|---|---|
| 2026-08-02 | 1.24012.9 | working |
| 2026-08-13 | 1.28929.0 | all tools rejected |

The app auto-updated in between. Also confirms this is not macOS-specific (label says platform:macos); this is the second Windows report in this thread.

Ruled out on this end, in case it saves anyone time:

  • Updating the server — 2026.7.10 is current, and outputSchema has been declared since at least 2026.1.14, so there is no "fixed" version to move to.
  • Pinning an older server version — same reason.
  • Config or credentials — list_allowed_directories touches no filesystem path at all and still fails, so this is not a permissions issue.

One impact angle not yet raised in this thread. For filesystem-type servers, the allowed-directories sandbox is a security boundary, not a convenience. When the server dies at registration, the natural workaround is to fall back to the client's built-in file tools — which have no path restriction at all. So the failure mode isn't just "a server is unavailable": it silently removes a containment guarantee and substitutes an unrestricted one, with nothing surfacing that the boundary is gone. In our case the sandbox was scoped to a single vault directory precisely to prevent cross-project writes.

That makes the graceful-fallback behaviour referenced in #41361 (pre-2.1.88) meaningfully safer than a hard reject: a tool that still works under a relaxed output-validation is strictly better than a tool that disappears and gets replaced by an unsandboxed equivalent.

Either suggested fix works from here — registering the draft-07 meta-schema on the Ajv instance, or skipping structured-output validation for an unrecognised dialect.

ymeskini · 16 days ago

All my MCPs are no longer working with Claude Desktop and Claude Code

Tigershawk · 16 days ago

Confirming this same regression on a different MCP server — the IBM i connector (mcp__remote-devices__ibm-i__*) exposed through Cowork. So far, Chat seems to work so indicates that our MCP server is functioning at least correctly.

Every tool on this connector fails identically before dispatch:

Tool 'system_status' 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; pass a pre-configured Ajv instance to AjvJs

Confirmed affected tools: system-status, execute_sql (likely all tools on the connector, since it appears to be a connector-wide schema declaration). This makes the entire connector unusable, not just one tool.

This matches the pattern described above — client-side rejection prior to any request reaching the server, and not caused by any change on the server/connector side. Adding as a second data point since it suggests this isn't isolated to mongodb-mcp-server but affects any MCP server declaring draft-07 outputSchema.

Would strongly support the proposed fix of registering draft-07 (and ideally draft-04/06/2019-09) meta-schemas on the Ajv instance, or falling back to skipping output validation rather than disabling the tool entirely.

bcherny collaborator · 15 days ago

Could not reproduce on Claude Code CLI v2.1.233 (macOS). Note the report and both confirmations are against Claude Desktop 1.28929.0, which we did not test here.

Steps (CLI):

  1. Minimal stdio MCP server (plain Node) exposing one tool count whose outputSchema declares "$schema": "http://json-schema.org/draft-07/schema#" (plus type: object, properties, required), returning structuredContent: {"count": 42}.
  2. Config: {"mcpServers":{"draft07":{"command":"node","args":["server.mjs"]}}}
  3. claude -p --strict-mcp-config --mcp-config mcp.json --allowedTools mcp__draft07__count "Call mcp__draft07__count with what='apples' and report the exact result or error"

Observed: the call reached the server and succeeded; the model reported {"count":42}, and no "unsupported dialect" error appeared anywhere, including the debug log. Same result with a draft-07 schema using $ref/definitions.

Expected: same. The CLI tolerates draft-04/06/07/2019-09 $schema declarations on outputSchema (it drops the dialect marker and validates the structure under the default rules), so servers built on the MCP TypeScript SDK's default zod target work.

Assessment: this looks like a genuine bug, but in Claude Desktop's MCP client rather than the Claude Code CLI. The error text is the MCP SDK's stock validator message, which is exactly what you get when a client uses that validator unmodified; the CLI ships a wrapper that avoids it. Based on the versions above it regressed in Desktop somewhere between 1.24012.9 and 1.28929.0. It should be routed to the Claude Desktop team; a longer-term upstream fix (a dialect-aware default validator in the MCP TypeScript SDK) would cover every client. If you do hit this in the CLI itself, please share claude --version and claude --debug output around the failing call.

🤖 Generated with Claude Code

github-actions[bot] · 15 days ago

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

amitfin · 15 days ago

@bcherny thanks for testing — that's a useful narrowing, and I don't think it conflicts with the report. Confirming the surface explicitly, since the template didn't have a field that distinguishes them:

This is Claude Desktop, not the CLI. The original report is Claude Desktop 1.28929.0 on macOS (the "Platform: Claude Desktop (macOS)" field), and the confirmations above are also Desktop — @StableSoftwareDev on Windows Desktop, @Vantso, @SebCool, @ymeskini ("Claude Desktop and Claude Code"), @Tigershawk via Cowork. Nobody has claimed a CLI reproduction, so a green CLI run is consistent with every data point here rather than contradicting them.

Your result actually sharpens the diagnosis in a useful way. If the CLI drops the dialect marker and validates structurally, while Desktop passes the document to a stock Ajv instance, then the two clients have materially different outputSchema handling — and the user-visible error is Ajv's own text, including the internal-sounding tail pass a pre-configured Ajv instance to AjvJs. That reads like the Desktop stack constructs Ajv without registering the older meta-schemas, which is exactly the fix suggested in the original report.

@Tigershawk's observation is probably the sharpest lead: Chat works, agent-mode fails, same machine. That's a within-Desktop split, which points at one specific client path rather than the app as a whole. #80174 describes chat vs agent-mode MCP routing differences that may be the same seam.

Why closing would be premature

The blast radius is the thing I'd weigh here. The dialect is not a quirk of any one server — it's the MCP TypeScript SDK's default for Zod v4 (mapMiniTarget returns 'draft-7' when no target is passed, and no target is reachable through registerTool). So every SDK-based server on Zod v4 that declares outputSchema is affected on Desktop. Confirmed in this thread across mongodb-mcp-server, mssql-mcp-node, an n8n server with 33 tools, an IBM i connector — and Anthropic's own @modelcontextprotocol/server-filesystem (@SebCool above).

Upstream I've opened modelcontextprotocol/typescript-sdk#2653 to move the SDK default to draft-2020-12. That reduces exposure once it ships, but it doesn't fix Desktop: draft-07 remains valid JSON Schema, the MCP spec explicitly permits an explicit $schema, and the v2 SDK's own validator accepts draft-07/06/2019-09/2020-12. Any server that legitimately declares draft-07 will keep failing on Desktop.

Repro on Desktop

Same minimal server you built, loaded through Desktop instead of the CLI:

  1. ~/Library/Application Support/Claude/claude_desktop_config.json:

``json
{ "mcpServers": { "draft07": { "command": "node", "args": ["/abs/path/server.mjs"] } } }
``

  1. Restart Claude Desktop (config is read at launch).
  2. Ask it to call draft07:count.

Observed on 1.28929.0: the call fails before dispatch with Tool 'count' has an invalid outputSchema: … unsupported dialect …, and the server logs no tools/call. Tools on the same server without outputSchema work normally — that contrast is the tell.

If it's easier to reproduce against a published server, npx -y mongodb-mcp-server@2.1.0 --readOnly with any MDB_MCP_CONNECTION_STRING fails on all tools; @1.13.0 fails on exactly the 8 of its 16 tools that declare outputSchema and works for the other 8, which isolates the trigger cleanly without needing a reachable database.

Happy to gather Desktop logs if that helps — could this be relabelled to the Desktop client rather than auto-closed?

m13v · 15 days ago

the fallback in your suggested fix, skip structured-output validation instead of disabling the tool, trades a loud reject for a quiet one. once validation is skipped, a tool returning malformed structuredContent looks identical to one returning a clean result, and the draft-07 vs 2020-12 mismatch that's the actual bug goes silent. registering the draft-07 meta-schema on the Ajv instance keeps the check firing; skipping just pushes the failure downstream where nothing surfaces it.

bcherny collaborator · 14 days ago

Thanks for the detailed report — I tried to reproduce this on 2.1.233 (Linux) and could not.

I configured a stdio MCP server whose tool declares outputSchema with "$schema": "http://json-schema.org/draft-07/schema#" and returns structuredContent, then called it via claude -p --mcp-config. The call reached the server and succeeded, with the structured result validated — no "unsupported dialect" error. I also verified this on the exact code path that performs the strict schema validation.

This looks already fixed in a recent release: Claude Code now accepts outputSchema documents declaring the draft-04/06/07 and 2019-09 dialects (it validates them under the common structural keywords instead of rejecting the tool), which matches the behavior you asked for. Older builds from around when you filed this did reject them.

Please update to the latest version (2.1.233 or newer) and re-try your mongodb-mcp-server setup. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Closing — reply here if you still see this on the latest version and we'll reopen.

🤖 Generated with Claude Code

amitfin · 13 days ago

Requesting a reopen — GitHub won't let me reopen this myself (both gh issue reopen and a REST state=open PATCH are rejected for non-collaborators on this repo), so I'm asking here. The close was based on a non-repro, and I can now point at the code. Still failing for me today on Claude Desktop 1.30096.5 (much newer than the 1.28929.0 I filed against), same mongodb-mcp-server config, unchanged:

Error: Tool 'list-databases' 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; pass a pre-configured Ajv instance to AjvJs…

@bcherny — your CLI run was green for a real reason, but it isn't a fix. There are two MCP client stacks in the shipped binary, picked at runtime by a rollout flag. You landed on the lenient one; Desktop puts me on the strict one.

1. The arm selector

From the shipped claude binary, 2.1.233 (minified, symbols are the build's own):

function $5(){
  let e = V.MCP_SDK_GENERATION,
      t = e==="v1"||e==="v2" ? e : void 0;
  if (e!==void 0 && t===void 0)
    w(`MCP_SDK_GENERATION=${e} is invalid; expected 'v1' or 'v2' — ignoring`,{level:"warn"});
  let r = t===void 0 && rt("tengu_brindle_causeway",!1)===!0,
      n = t ?? (r ? "v2" : "v1"),
      o = t!==void 0 ? "env" : r ? "growthbook" : "default";
  return fKs.latch(n), w(`mcp runtime arm: ${n} (source: ${o})`),
         H("tengu_mcp_sdk_generation",{generation:he(n),source:he(o)}), n
}

Default is v1; v2 comes from the GrowthBook flag tengu_brindle_causeway. So which validator a given user hits is a flag arm, not a version — which is exactly why a CLI run and a Desktop run of the same build disagree.

2. The two validators — only one has the gate

v1 (lenient), the arm your CLI run used — compiles whatever it's given, no dialect check at all:

function $ky(){ let e = new u8c.default({strict:!1,validateFormats:!0,validateSchema:!1,allErrors:!0}); return d8c.default(e), e }
class Qfn{
  constructor(e){ this._ajv = e ?? $ky() }
  getValidator(e){
    let t = "$id" in e && typeof e.$id==="string" ? this._ajv.getSchema(e.$id) ?? this._ajv.compile(e) : this._ajv.compile(e);
    …

v2 (strict), the arm Desktop puts me on — same shape, plus a two-entry allowlist that throws the exact string users see:

Dib = new Set([
  "https://json-schema.org/draft/2020-12/schema",
  "http://json-schema.org/draft/2020-12/schema"
]);
function Mib(){ let e = new Pib.Ajv2020({strict:!1,validateFormats:!0,validateSchema:!1,allErrors:!0}); return tMd(e), e }
class /* AjvJsonSchemaValidator */ {
  getValidator(e){
    if (!this._userAjv && "$schema" in e && typeof e.$schema==="string" && !Dib.has(e.$schema.replace(/#$/,""))) {
      let n = e.$schema.slice(0,200);
      throw Error(`JSON Schema declares an unsupported dialect ("$schema": "${n}"). The default validator supports JSON Schema 2020-12 only; pass a pre-configured Ajv instance to AjvJsonSchemaValidator(ajv) to validate other dialects.`)
    }
    …

Two things stand out:

  • validateSchema: !1. The instance never checks a document against a meta-schema, so the missing draft-07 meta-schema isn't actually what blocks anything. The rejection is a bare string comparison on $schema in front of a compiler that was never going to consult it.
  • Plain Ajv is already bundled in that same module — the build has both Pib.Ajv2020 and Lib = Iib.Ajv side by side. The draft-07-capable compiler is sitting right there, unused on this path.

3. Why the whole server dies

v2's callTool turns a compile failure into a pre-dispatch throw:

o = t?.toolDefinition===void 0
      ? await this._cache.outputValidator(e.name,(l)=>this._compileOutputValidator(l)).catch(…)
      : this._compileOutputValidator(t.toolDefinition),
i = () => {
      if (o===void 0 || o.ok) return;
      let c = (o.compileError instanceof Error ? o.compileError.message : String(o.compileError)).slice(0,200);
      throw new Hg(wp.InvalidParams, `Tool '${e.name}' has an invalid outputSchema: ${c}`)
};
i();                                             // ← throws here
let s = await this.request({method:"tools/call", params:e}, await n());   // ← never reached

i() runs before this.request, which is precisely the "the server process is never contacted" symptom in the original report, and why tools without outputSchema on the same server keep working.

4. Version evidence

I pulled the real darwin-arm64 binaries from npm and ran the minimal draft-07 server through each:

| CLI build | draft-07 outputSchema call |
| --- | --- |
| 2.1.214 | works — {"count":42} |
| 2.1.221 | works |
| 2.1.229 | works |
| 2.1.233 ("already fixed") | works |

2.1.229 is the build Claude Desktop embeds and where this fails for me right now (Claude.app/…/claude-code/2.1.229/…/claude). Same binary, both outcomes — version isn't the variable. I also ran the real mongodb-mcp-server@1.13.0 through the 2.1.229 CLI: the call reached the server and returned MongoDB's own connection error, i.e. dispatch succeeded.

And the rejecting code is unchanged in 2.1.233 — the error string is present verbatim, 4 occurrences, in the binary published as the fix. Nothing in CHANGELOG.md matches dialect|draft|ajv|2020-12|meta-schema for any release in this window.

One thing I could not do: force the failure from the CLI with MCP_SDK_GENERATION=v2 — that run still succeeded against a stdio server negotiating 2025-06-18. So the strict path appears to need the v2 client's modern-era/bridged connection, which is what Desktop uses. I'm reporting that as an open gap rather than claiming a full bisect; someone with the flag internals can close it in a minute.

5. Same gap, second copy, in the Desktop bundle

Claude.app/Contents/Resources/ion-dist/assets/v1/c2a6d07ee-BdDPXPoZ.js ships an independent validator with the identical assumption:

Ai = new Set(["https://json-schema.org/draft/2020-12/schema","http://json-schema.org/draft/2020-12/schema"]);
…
throw new Error(`JSON Schema declares an unsupported dialect ("$schema": "${t}"). The default validator supports JSON Schema 2020-12 only; pass an explicit { draft } to CfWorkerJsonSchemaValidator to validate other dialects.`)

Different library, different message, same two-URI allowlist — which supports the "inconsistent meta-schema registration across validator instances" read in the original report, and is presumably the other polarity behind #80402.

6. Suggested fix

Primary — dispatch on dialect instead of rejecting (v2 AjvJsonSchemaValidator.getValidator). Both compilers are already bundled; key off $schema and memoize one instance per dialect:

const DIALECT = {
  "https://json-schema.org/draft/2020-12/schema": Ajv2020,
  "http://json-schema.org/draft/2020-12/schema":  Ajv2020,
  "https://json-schema.org/draft/2019-09/schema": Ajv2019,
  "http://json-schema.org/draft-07/schema":       Ajv,      // already bundled
  "http://json-schema.org/draft-06/schema":       Ajv,      // + ajv.addMetaSchema(draft6MetaSchema)
  "http://json-schema.org/draft-04/schema":       Ajv,
};
// unknown/absent $schema → current 2020-12 default, unchanged

Same {strict:false, validateFormats:true, validateSchema:false, allErrors:true} options; no behavior change for schemas that already work. This is what the v2 SDK's own validator does, and it's the outcome @m13v argued for — validation keeps firing, it just fires under the right dialect.

Secondary — don't let a validator gap disable a working tool. In _compileOutputValidator's consumer, a compile failure should degrade to "no structured-output validation for this tool", logged loudly, instead of throwing InvalidParams before dispatch. I'd apply this only as the safety net behind the primary fix, not instead of it — @m13v's objection to skipping validation is correct, and with dispatch-on-dialect there's nothing left to skip for the dialects that matter.

Third — same treatment for CfWorkerJsonSchemaValidator in the Desktop bundle: derive { draft } from $schema rather than throwing on anything that isn't 2020-12.

The blast radius argument from the original report is unchanged and is the reason this is worth fixing rather than closing: draft-07 is the MCP TypeScript SDK's default for Zod v4 (mapMiniTarget → 'draft-7' when no target is passed, and no target is reachable through registerTool), so every SDK-based server on that path is affected in the v2 arm — confirmed in this thread across mongodb-mcp-server, mssql-mcp-node, an n8n server, an IBM i connector, and Anthropic's own @modelcontextprotocol/server-filesystem.

🤖 Generated with Claude Code

Tigershawk · 13 days ago

Still seeing issue on Claude Code. This is version Version 1.30096.5 (6e1346) on Windows Claude Desktop app. I originally was seeing the issue in Cowork, but to satisfy complaints that this issue was originally opened for Code, I'm also seeing it in Claude Code. Error is as follows. Chat continues to work.

I tried to pull the IBM i system status, but the call failed before it could return any data:

This is a bug in the mcp__ibm-i__system-status tool's schema definition (draft-07 vs. the 2020-12 dialect the client validator expects) — not something I can work around from here, and not related to permissions or connectivity. It'll need a fix on the MCP server/connector side.

A couple of related tools are available if useful in the meantime: list-active-jobs and recent-job-log-entries. Want me to try one of those instead, or do you want me to flag this tool issue somewhere?

lylealliedhealth · 13 days ago

Still reproducing on the latest Claude Desktop, so requesting a reopen — adding a data point from a different MCP server than the ones already reported here.

Failing server: the Cypress Cloud MCP connector (Cypress Cloud, org-level connector configured in the desktop app, not via .mcp.json). Every tool on it is disabled — the call fails client-side before anything reaches the server:

Error: Tool 'cypress_get_runs' 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; pass a pre-configured Ajv instance to AjvJs

Environment

Claude Desktop 1.30096.5 (macOS 26.6.1, Apple silicon / arm64)
MCP server: Cypress Cloud connector
Reproduces 100% — 7 calls across 3 tools (cypress_get_runs, cypress_get_flaky_tests, cypress_get_projects), varying parameters, and again after a full app restart

All 5 tools the connector exposes declare "$schema": "http://json-schema.org/draft-07/schema#", so the whole server is unusable, not just one tool. Restarting doesn't help — after a restart the tool list is re-fetched and still declares draft-07, which is what the client then rejects. There's nothing to configure on our end and no newer connector version to move to.

One detail that might explain the earlier non-repro: the error I get ends in pass a pre-configured Ajv instance to AjvJs, which is different wording from the dialect error that appears in the desktop app bundle itself (pass an explicit { draft } to CfWorkerJsonSchemaValidator). That suggests more than one validator path, and that a fix verified on one may not cover the other — worth checking both call sites.

StevenJerez · 12 days ago

Still reproducing, adding a data point that differs from the ones already in this thread: a remote HTTP MCP server, not stdio.

Failing server: the MCP endpoint that n8n serves itself, at /mcp-server/http on a self-hosted instance running n8n 2.34.5 (current release, not an outdated install). Configured in .claude.json as {"type": "http", "url": "https://…/mcp-server/http"}, Bearer/OAuth auth.

Every tool on the server is unusable — I tried search_workflows, list_credentials, search_projects and search_nodes, all failing identically before any request leaves the client:

Tool 'search_workflows' 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; pass a pre-configured Ajv instance to AjvJs

Two things that may matter for the non-repro on 2.1.233: this is an HTTP transport server rather than stdio, and the server side is fully up to date, so there is no server-side upgrade available as a workaround. The tools are listed but every call is dead on arrival.

niino-atsuko · 11 days ago

Reproducing this on Claude Code CLI 2.1.235 (native install, Windows) — newer than 2.1.233, which @bcherny reported as fixed above.

Error: Tool 'obsidian_get_note' 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; pass a pre-configured Ajv instance to AjvJs

Steps: updated from 2.1.209 → 2.1.235 via claude update, started a fresh session, asked it to read a note via the mcp-obsidian MCP server (obsidian-mcp-server on npm, unrelated to MongoDB's server). Same failure on every tool call, identical to before the update.

@amitfin noted nobody had claimed a CLI reproduction yet, and traced the split to the MCP_SDK_GENERATION v1/v2 arm (gated by the tengu_brindle_causeway GrowthBook flag) rather than OS/version — CLI 2.1.214/221/229/233 all worked for them, only Desktop failed. For what it's worth, on this machine tengu_brindle_causeway is true in the cached GrowthBook features (~/.claude.json), yet the CLI still fails here — so if this is the first confirmed CLI-side repro, the v1/v2 split may not be as clean as it looked. Happy to attach claude --debug output from a repro run if that'd help narrow it down.

antoniojguerra-bit · 11 days ago

Confirming this also breaks the official Perplexity MCP server (@perplexity-ai/mcp-server, run via npx -y @perplexity-ai/mcp-server) — every tool (perplexity_ask, perplexity_search, etc.) fails on the very first call with the identical error:

Error: Tool '<tool_name>' 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; pass a pre-configured Ajv instance to AjvJs
One data point that may be useful for the fix: I downloaded and diffed the published tarballs for @perplexity-ai/mcp-server at v0.9.0, v1.0.0, and v1.2.0 (latest) to check whether pinning an older server version would work around this. It doesn't — the server package never touches JSON Schema generation itself, it just hands a Zod shape to server.registerTool(). The draft-07 $schema is produced by @modelcontextprotocol/sdk's internal use of zod-to-json-schema, which has defaulted to draft-07 output across its entire 3.x line regardless of SDK version (checked SDK 1.21.1 → zod-to-json-schema@^3.24.1, SDK 1.29.0/1.30.0 → zod-to-json-schema@^3.25.1, both draft-07 by default).

So this isn't something individual MCP server authors can fix by bumping/pinning versions — it really does need the fix on the Claude Code / Ajv-instance side described above (register draft-07 meta-schema and/or fall back to skipping structured validation instead of disabling the tool). This confirms the issue is systemic to any SDK-based MCP server with a Zod outputSchema, not limited to mongodb-mcp-server.

UffeHammer · 11 days ago

FileSystem plugin is now unusable for me in Claude, and it was much more convenient than the built in way of handling directories, where you need to accept every access..

mikezieg · 10 days ago

Adding another data point: this also breaks Cowork (not just the Claude Code CLI), via the remote-devices MCP bridge to a local Obsidian Local REST API / MCP server. Every tool call against that server (obsidian_get_note, obsidian_list_notes, obsidian_search_notes, etc.) now fails client-side with:

Tool '<name>' 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; pass a pre-configured Ajv instance to AjvJs

This was a production integration that had worked reliably for months without any change on the user's end (no plugin update, no config change) — it started failing between Aug 4 and Aug 12, 2026, matching the timeline already reported here. Restarting the Obsidian plugin, updating it to the latest version, and reconnecting the device bridge had no effect, which confirms the regression is entirely client-side, as already established in this thread.

The practical impact is that a previously-working, spec-compliant MCP server became silently unusable overnight, with no warning and no fallback — the only workaround is bypassing the MCP server entirely and reading/writing vault files directly over a raw file bridge, which loses live-sync with the Obsidian UI, structured section/frontmatter editing, and indexed search.

Given draft-07 is explicitly valid per the MCP spec and multiple independent servers are affected (mongodb-mcp-server, Obsidian Local REST API, presumably many others), this reads as a broad, high-severity regression rather than an edge case. Would appreciate a status update on timeline — registering the older meta-schemas (draft-04/06/07, 2019-09) on the Ajv instance seems like a narrowly-scoped fix.

akristiansson · 9 days ago

Corroborating report with a minimal repro, plus one data point the thread doesn't have yet: which Claude surfaces are affected appear to differ.

Summary

Any MCP tool that declares an outputSchema built with the current reference TypeScript SDK (@modelcontextprotocol/sdk@1.30.0, the latest release, via zod-to-json-schema@3.25.2) is rejected client-side before the call is dispatched:

Tool 'echo' 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; pass a pre-configured Ajv
instance to AjvJs

The server is unmodified reference-SDK output — the draft-07 $schema marker is what the SDK emits for every zod-registered schema. A validator that only accepts 2020-12 therefore rejects the entire current reference-SDK server ecosystem, not misbehaving servers.

Minimal reproduction

server.mjs (deps: npm i @modelcontextprotocol/sdk@1.30.0 zod@3.25.76; "type": "module" in package.json):

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
 
const server = new McpServer({ name: "repro", version: "0.0.1" });
server.registerTool(
  "echo",
  {
    description: "echoes its input",
    inputSchema: z.object({ text: z.string() }),
    outputSchema: { text: z.string() },
  },
  async ({ text }) => ({
    structuredContent: { text },
    content: [{ type: "text", text: JSON.stringify({ text }) }],
  }),
);
await server.connect(new StdioServerTransport());

claude_desktop_config.json:

{ "mcpServers": { "repro": { "command": "node", "args": ["/abs/path/server.mjs"] } } }

Steps: restart Claude Desktop → open a Cowork session → ask Claude to call the echo tool. The call fails with the error above; the error is raised client-side by the schema validator, before dispatch to the server.

Surface matrix (all same machine, same server, same day — macOS)

| Surface | Result |
|---|---|
| Claude Desktop, Cowork session (local-MCP bridge relay) | ❌ rejected with the error above; tools/list succeeds, every tools/call fails |
| Claude Desktop, plain chat | ✅ works |
| Claude Code (CLI, this machine's installed version) | ✅ works |

The original issue reports Claude Code affected since ~2026-08-12; on this machine (2026-08-20) Claude Code accepted the same schemas while the Cowork bridge rejected them — so the strict validator configuration appears to vary by surface and/or version rather than being uniform. That may help localise which component picked up the 2020-12-only Ajv configuration.

Why this should be fixed client-side

  • The emitting side is the reference SDK at its latest release — there is no server-side upgrade that changes the emission today (typescript-sdk#745 tracks moving it to 2020-12; typescript-sdk#2532 reports the same rejection in the SDK's own default validators, noting the spec permits declared draft-07).
  • The spec transition to 2020-12-as-default is in flight (SEP-1613, implementation typescript-sdk#2192); until servers built on released SDKs emit 2020-12, a 2020-12-only validator guarantees ecosystem breakage.
  • Suggested fix: register the draft-07 meta-schema in the validating Ajv instance (accept declared draft-07 alongside 2020-12), or at minimum fail soft (skip output validation with a warning) instead of hard-failing every call to the tool.

Environment: macOS, Claude Desktop (current as of 2026-08-20), server under Node 22.x, @modelcontextprotocol/sdk@1.30.0 (npm latest), zod@3.25.76, zod-to-json-schema@3.25.2.

tennisgent · 7 days ago

Still reproducing on Claude Code CLI 2.1.241 (macOS, Darwin 25.5.0) — eight builds past the 2.1.233 that was reported as a non-repro when this was closed.

Server: mongodb-mcp-server, pinned to 1.12.0 in .mcp.json via npx -y mongodb-mcp-server@1.12.0 --connectionString <...> --readOnly. 2.1.0 reproduces identically; both emit draft-07, so the pin makes no difference.

Every tool declaring an outputSchema (count, find, aggregate, list-databases, list-connections) fails client-side before dispatch:

Error: Tool 'count' 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; pass a pre-configured Ajv instance to AjvJs

One new data point: the rejection timing changed between 2.1.233 and 2.1.241.

  • On 2.1.233, the validator compiled lazily. The session's first tool call actually reached the server — list-databases came back with a server-side -32602 about a missing connectionId, i.e. the server received and processed it. Every subsequent call, including to that same tool, was rejected client-side with the error above.
  • On 2.1.241, the first call of the session is rejected eagerly. Nothing reaches the server at all.

So the code path has been touched between those builds, but only to move the rejection earlier. That the same tool could be dispatched once and then blocked also suggests the strict Ajv instance is constructed on first structured response rather than at tool registration, which may help localise it.

Requesting a reopen — this has been broken continuously here since 2026-08-12, and the version it was closed against still fails.

kezouke · 6 days ago

Confirming this also reproduces with a different MCP server via Cowork's desktop
extension path: anki-mcp-server (@ankimcp/anki-mcp-server v0.22.2), installed as
a Claude Desktop extension (.mcpb) rather than a manual claude_desktop_config.json
entry.

Every tool call fails identically before dispatch, e.g.:

Tool 'listDecks' 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; pass a pre-configured Ajv instance
to AjvJs

Confirmed tools affected: listDecks, modelNames, collection_stats — same error
across all, reachable through the remote-devices/Cowork bridge, so the same v2
strict-validator path already reported by @mikezieg and @akristiansson for
other servers.

Environment: Claude Desktop 1.34493.1, Electron 42.9.2, macOS (Apple Silicon).
Local server unmodified, AnkiConnect reachable directly at localhost:8765
independent of this — confirms client-side rejection, not a connectivity issue.

jordy-dam-inqdo · 6 days ago

Also hitting this in Claude Desktop (macOS) as of 2026-08-24, with a different MCP server, which confirms it isn't MongoDB-specific and matches the report's prediction that any draft-07 schema generator is affected.

Server: @cyanheads/git-mcp-server (latest, v2.15.1). Every tool is rejected at registration before any request reaches the server, e.g.:

Tool 'git_set_working_dir' 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; pass a pre-configured Ajv instance to AjvJs

Same failure mode as the original report: the whole server is disabled and nothing is dispatched.

Still present on a newer build than the original report. Claude Desktop version: 1.34493.1 (255293), build 2026-08-21 (report was on 1.28929.0).

Verified client-side, not server-side. The same server, same machine, loads fine and all its tools register and execute end-to-end in Claude Code (CLI). Only Claude Desktop rejects it. So the git logic and the schemas are sound; the two clients just handle the same payload differently, consistent with the "inconsistent meta-schema registration across different Ajv instances" note above.

To be precise about the mechanism: this is the tool's outputSchema declaring the draft-07 dialect ("$schema": ".../draft-07/schema#"), not an unsupported schema construct. Desktop's Ajv validator only has the 2020-12 meta-schema registered, so it throws on the dialect label before inspecting the schema body. Per the MCP spec an explicitly declared draft-07 outputSchema is valid, so this is a client-side meta-schema registration gap in Desktop, not something the server can resolve.

Impact note: git-mcp-server is one of the few git MCP servers that supports remote push/pull/fetch, so there's no drop-in replacement (the official Python git server is local-only). The fallback is running git outside MCP entirely, which defeats the point of the integration.

lylealliedhealth · 6 days ago

@bcherny Looks like this is still causing issues. Can we get a reopen? Thanks

biergeliebter · 6 days ago

I'm not sure if this is the right place but my Claude Desktop indicates 86142 is what Anthropic needs to ship a fix for.

+1 request for getting this fixed in Claude Desktop.
The previously working Filesystem connector to the Project files on my Windows D drive no longer works because of this bug in Claude Desktop's Ajv validator.

{
"path": "D:\\Projects\\<Project Name Goes Here>"
}
Results in:
Error: Tool 'list_directory' 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; pass a pre-configured Ajv instance to AjvJs

{}
Results in:
Error: Tool 'list_allowed_directories' 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; pass a pre-configured Ajv instance to AjvJs

And so on. The tool will change but the rest of the error for each attempt by Claude is the same:

Error: Tool 'read_multiple_files' 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; pass a pre-configured Ajv instance to AjvJs

cyanheads · 6 days ago

@jordy-dam-inqdo I've implemented a workaround in git-mcp-server to explicitly advertise JSON Schema 2020-12 instead of draft-07 in the tools/list call. Please update git-mcp-server to v2.15.2 and let me know if you continue having issues.

@niino-atsuko @mikezieg In obsidian-mcp-server v3.3.0 I've updated to the latest mcp-ts-core which includes the explicit 2020-12 schema as well as MCP SDK v2 support. Please update to the latest obsidian-mcp-server and let me know if you continue having issues.

cpignata · 5 days ago

Also hitting this via the bundled Filesystem extension (ant.dir.ant.anthropic.filesystem v2026.7.10), reached through a Cowork session — so this isn't limited to third-party MCP servers, it affects Anthropic's own shipped extension too.

Environment: Claude Desktop 1.34493.1, macOS 26.6.2 (Apple Silicon).

Tool move_file rejected before dispatch:

Error: Tool 'move_file' 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; pass a pre-configured Ajv instance to AjvJs

Checked the extension's source (dist/index.js): every tool it registers (read_file, write_file, list_directory, move_file, etc.) uses the same outputSchema: { content: z.string() } shape, generated via zod-to-json-schema, which stamps $schema: draft-07 by default. So this likely isn't specific to move_file — any tool call through this extension that goes through output-schema validation should hit the same wall.

Given the extension is Anthropic's own and ships in the base Desktop/Cowork install, seems like a reasonable candidate for the fix to land in first — either have Desktop's Ajv instance register draft-07 (and ideally draft-04/06/2019-09) alongside 2020-12, or have the bundled extension stop emitting a $schema field on its output schemas. Requesting a reopen given it's still reproducing on the latest build.

OliverBokan · 5 days ago

Confirming this also fully breaks third-party MCP servers beyond the MongoDB case already mentioned here — same failure mode with bezata/kObsidian (npm kobsidian-mcp, 66 tools across notes., wiki., vault.*, etc.). It uses @modelcontextprotocol/sdk@1.29.0, which still emits outputSchema as draft-07 by default via zod-to-json-schema, and since the client rejects the whole server at registration time, all tools go down — not just ones exercising structured output. Opened bezata/kObsidian#35 on their side for a server-side mitigation, but the underlying issue is the same one tracked here. Any update on priority/ETA? This is silently taking out entire third-party servers with zero indication to the end user beyond a cryptic schema error.

mswdev · 5 days ago

Issue is happening to me and my team too with Triple Whale MCP from https://triplewhale.com

---

Confirming this on a second, unrelated server: Triple Whale's Moby MCP (commercial analytics/SQL server). Every tool fails client-side with the identical error before the request reaches the server:

```Error: Tool '<name>' 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; pass a pre-configured Ajv instance to AjvJs


100% failure rate across all tools tested on this server. Not a stale-cache issue: re-synced the tool list mid-session and it still failed. 

Matches the root cause in modelcontextprotocol/typescript-sdk#2532: draft-07 is spec-valid when explicitly declared, but the client's Ajv instance only has the 2020-12 meta-schema registered.

Since this now hits at least two unrelated third-party servers, it looks like it breaks any server built on the v1 SDK / `zod-to-json-schema` default (draft-07), which is a pretty common combination.
jordy-dam-inqdo · 3 days ago

@cyanheads: with the new version the issue has been resolved regarding the git-mcp-server! Thanks!

Tigershawk · 3 days ago
@cyanheads: with the new version the issue has been resolved regarding the git-mcp-server! Thanks!

Just to clarify this comment, I believe the new version is referring to an update to a specific MCP server to workaround the regression introduced by Anthropic, so, this update is only to git-mcp-server, not a fix to the issue other MCP servers are experiencing with Claude.

pwilliams-sketch · 2 days ago

Still reproducing after closure, on a different platform and path. Cowork mode on Windows: the MCP server is the reference filesystem server running locally under the desktop app and proxied to a cloud Cowork session through the linked-device bridge. Every tool on the server is rejected before dispatch with the identical error:

Tool 'list_directory' 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; pass a pre-configured Ajv instance to AjvJs

This confirms the validation failure also lives in the Cowork device-bridge path, not only direct desktop MCP registration on macOS. Per the comments above, the git-mcp-server change was a server-side workaround, not a client fix, and other draft-07 servers remain broken. Observed 2026-08-28, Claude desktop app on Windows.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on this topic page, alongside a backlog trend for the whole topic.

MCP server connection issues →

Browse all Claude Code issue topics →