›_ 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 56 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 ↗

56 Comments

amitfin · 2 months 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 · 2 months 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 · 2 months 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 · 2 months 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 · 2 months ago

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

Tigershawk · 2 months 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 · 2 months 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] · 2 months 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 · 2 months 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 · 2 months 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month ago

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

biergeliebter · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month 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 · 1 month ago

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

Tigershawk · 1 month 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 · 1 month 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.

m13v · 1 month ago

validating under only the 'common structural keywords' skips the draft-07-specific ones (dependencies, boolean exclusiveMinimum), so structuredContent that violates those now passes clean instead of erroring. the reject didn't narrow, it went silent on exactly the keywords the dialects differ on.

m13v · 1 month ago

the '2.1.233 already fixes it' vs 'Desktop still breaks' split isn't a bisect gap, it's the delivery model: one binary shipping both validators, arm-selected at runtime by tengu_brindle_causeway. version can't be the variable when the strict path is unchanged and just sits on a different arm, so bisecting by build keeps pointing at the wrong axis. the fix has to land on the v2 arm's getValidator, not a release number.

m13v · 1 month ago

that "fix on the server/connector side" line in the paste is the misdirect this issue already ruled out: the draft-07 reject fires client-side before dispatch, so the server never sees the call to fix. and falling back to list-active-jobs just turns a dead system-status tool into adjacent data that reads as success, which is how the real registration failure goes quiet.

m13v · 1 month ago

the two different error strings aren't two call sites of one validator, they're two engines: AjvJs vs CfWorkerJsonSchemaValidator. draft-07 has to be registered on each separately, so a fix proven on the Ajv path leaves the CfWorker path still rejecting. not a call-site sweep, two validators.

m13v · 1 month ago

"listed but dead on arrival" is the loud version of this. the skip-validation fallback people are asking for flips it to: call returns, structuredContent unchecked, reads as a clean result. and with no server-side upgrade path on HTTP, that quiet failure isn't a stopgap, it's the permanent state.

m13v · 1 month ago

"which version fixed it" isn't answerable while a GrowthBook flag picks the validator arm at runtime. tengu_brindle_causeway is remote config, not a build constant, so a frozen CLI can flip working→failing with no update. 2.1.229-worked is a snapshot of flag state, not a property of the version.

m13v · 1 month ago

the 'and/or' in 'register the meta-schema and/or skip validation' hides two opposite outcomes. your tarball diff proves draft-07 is the SDK default for every zod outputSchema server, so 'skip validation' isn't dropping one tool quietly, it's switching structured-output checking off across the whole SDK ecosystem and leaving it off. only the register-meta-schema arm keeps the mismatch detectable.

m13v · 1 month ago

the raw file bridge isn't a workaround here, it's what a device-bridged setup structurally forces. you can't patch the client validator and the server was already spec-valid, so the only lever left is regressing past MCP back to file I/O, which is exactly why you lose live-sync and indexed search.

m13v · 1 month ago

the catch in 'just register draft-07 client-side': #80402 shows a sibling Ajv instance already rejects 2020-12, so patching only the loud validator fixes Cowork but leaves the inverse polarity live. SEP-1613's flip to 2020-12-default then re-breaks the same surface you just fixed, unless both meta-schemas land on every instance rather than draft-07 on the one that's failing today.

m13v · 1 month ago

moving construction earlier costs the one signal in your own trace: the lazy 2.1.233 path let the first call round-trip a real -32602, proving the server parsed it. pair eager rejection with the skip-validation fallback and you bury the draft-07 mismatch before anything reaches the server at all, so the tool just looks empty instead of misconfigured.

m13v · 1 month ago

the .mcpb path makes skip-validation the only lever left: an extension install gives you no config file to inject a pre-configured Ajv into, so the error's own remedy ("pass a pre-configured Ajv instance") is literally unreachable. and skip just green-lights unvalidated structuredContent, so a broken listDecks over the bridge reads identical to a clean one. the loud client-side reject you're hitting is the only thing currently telling you the draft-07 mismatch exists.

m13v · 1 month ago

the CLI executing end-to-end isn't proof the schemas validated, only that nothing on that side checked them. so "make Desktop match CLI" is skip-validation wearing a parity argument: it green-lights unverified structuredContent instead of registering draft-07 so the dialect check keeps firing.

m13v · 1 month ago

of your two fixes, dropping $schema is the quieter failure: it strips the draft-07 label, not the semantics, so Ajv grades constructs like tuple items under 2020-12 rules and silently passes them. the reject is the only thing flagging the dialect gap right now; registering draft-07 keeps that check firing instead of burying it downstream.

m13v · 1 month ago

the server-side draft-2020-12 override you opened on kObsidian fixes those 66 tools but not the class: every other SDK-default server stays rejected client-side, so it's a per-server patch on a client-wide bug while the SDK keeps minting new casualties.

m13v · 1 month ago

registering draft-07 on the Ajv you hit fixes this polarity, but the issue itself lists the inverse in #80402: 2020-12 rejected by a different instance. patching one meta-schema on one Ajv leaves the other one broken. the real gap is per-instance registration across the codebase, not the dialect.

VolkerVV · 1 month ago

Same failure with the Filesystem desktop extension on Windows, Claude Desktop (current build, Sept 2026):

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

Only the tools that declare an outputSchema are affected — read_text_file, list_directory etc. on the same server keep working. So this is not limited to MongoDB/Perplexity; Anthropic's own Filesystem extension is hit as well.

rsalvucci-git · 1 month ago

Hitting this exact same error today (2026-09-01) with ClickUp's official remote MCP server (https://mcp.clickup.com/mcp), not just MongoDB — this issue shows as closed but the bug is still live in practice. Confirmed pattern: read tools work fine, write tools (create_task, update_task) fail client-side before any request reaches ClickUp's server, with the same "unsupported dialect" error. Reproduced both in Claude Code (CLI) and in the personal ClickUp connector on claude.ai/Claude Desktop.

sorenharrison · 1 month ago

Seeing this issue as well.

"OmniFocus MCP read tools broken — outputSchema uses draft-07, Cowork validator requires 2020-12."

EugeneKuvshinov · 1 month ago

This is still live in Desktop/Cowork — closing it via the stale-bot after @bcherny's CLI-only "could not reproduce" seems to have been premature, since the CLI wrapper he tested isn't the client this report is about, and the thread has kept getting confirmations on Desktop/Cowork since the close (filesystem extension, ClickUp's remote server as recently as 2026-09-01, and an MCP connector "exposed through Cowork").

Adding one more data point on the Cowork/desktop-bridge path specifically: SmartBear's official smartbear-mcp server (https://github.com/SmartBear/smartbear-mcp), run locally as a stdio server via node dist/index.js and proxied into a Cowork session over the desktop bridge. Every tool declaring outputSchema fails identically at registration — confirmed on zephyr_get_priorities, zephyr_get_test_cases, zephyr_get_projects — with valid credentials and config on our end, so this is purely the client-side dialect rejection described above, not anything server- or auth-related.

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

Given the CLI/Desktop split @bcherny identified, and the continued reports since the close, could this be reopened and routed to the Desktop/Cowork client team specifically? Happy to provide more detail if useful.

pawandprosper · 1 month ago

Reopening this with a live, dated reproduction, this was closed based on Claude Code CLI testing, but CLI was never actually affected by this bug (it runs the older, lenient validator). Desktop and Cowork are still broken on the current build.

Confirmed case: Obsidian vault connected via @modelcontextprotocol/server-filesystem (npx, local MCP server in Claude Desktop's Developer settings), affecting Cowork specifically.

Every tool call fails with:
Tool 'X' 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.

Details:

  • Connector shows "Running" in Settings the entire time, no indication anything is wrong until a tool is actually called.
  • Deleted the server entry, manually re-added it via claude_desktop_config.json, fully quit and relaunched Claude Desktop. Reconnected cleanly, same error persists. Not a stale-connection issue.
  • The exact same vault connection works fine in regular Claude Desktop chat. Only Cowork hits this validator.
  • Confirmed today, September 13, 2026, on Claude Desktop 1.52386.3, so this is still broken as of the latest build.

This is blocking a real daily workflow, not a hobby project. Would appreciate this being reopened and prioritized.

michael-evrythngwrx · 27 days ago

Easy fix is to add a shim that bypasses the $schema validation. You can implement the shim like so:
`import { spawn } from "node:child_process";

const [, , command, ...args] = process.argv;
if (!command) {
process.stderr.write("mcp-schema-shim: usage: node mcp-schema-shim.mjs <server-command> [args...]\n");
process.exit(2);
}

const child = spawn(command, args, { stdio: ["pipe", "pipe", "inherit"], env: process.env });

// Client -> server: pass through untouched.
process.stdin.pipe(child.stdin);
process.stdin.on("end", () => child.stdin.end());

// Server -> client: JSON-RPC over stdio is newline-delimited JSON, so buffer by line.
let pending = "";
child.stdout.setEncoding("utf8");
child.stdout.on("data", (chunk) => {
pending += chunk;
let newline;
while ((newline = pending.indexOf("\n")) !== -1) {
const line = pending.slice(0, newline);
pending = pending.slice(newline + 1);
process.stdout.write(rewrite(line) + "\n");
}
});
child.stdout.on("end", () => {
if (pending) process.stdout.write(rewrite(pending));
});

function rewrite(line) {
if (!line.includes("$schema")) return line; // fast path: nothing to strip
let message;
try {
message = JSON.parse(line);
} catch {
return line; // not JSON; leave it alone
}
const tools = message?.result?.tools;
if (!Array.isArray(tools)) return line; // only tools/list results are rewritten
let changed = false;
for (const tool of tools) {
for (const key of ["inputSchema", "outputSchema"]) {
const schema = tool?.[key];
if (schema && typeof schema === "object" && "$schema" in schema) {
delete schema.$schema;
changed = true;
}
}
}
return changed ? JSON.stringify(message) : line;
}

// Lifecycle: mirror the child's exit status and forward termination signals.
child.on("exit", (code, signal) => process.exit(code ?? (signal ? 1 : 0)));
child.on("error", (err) => {
process.stderr.write(mcp-schema-shim: failed to start "${command}": ${err.message}\n);
process.exit(1);
});
for (const sig of ["SIGINT", "SIGTERM", "SIGHUP"]) {
process.on(sig, () => child.kill(sig));
}`

name the file whatever you like and then shell copy to ~/.config/claude (mkdir -p ~/.config/claude && cp ~/Downloads/mcp-schema-shim.mjs ~/.config/claude/)

check that the shim is functional:
node --check ~/.config/claude/mcp-schema-shim.mjs && echo "shim OK"
which node

Add the MCP:
"example_mcp_server": {
"command": "/opt/homebrew/bin/node",
"args": [
"/Users/YOUR-USERNAME/.config/claude/mcp-schema-shim.mjs",
"npx", "-y", "mongodb-mcp-server@latest", "--readOnly"
],
"env": {
"MDB_MCP_CONNECTION_STRING": "keep your existing value"
}
}

christophepub · 24 days ago

Still reproducible on Claude Desktop and Cowork with @modelcontextprotocol/server-filesystem v2026.8.31 (checked 2026-09-20). The CLI was never affected, so the "could not reproduce" that closed this issue doesn't match what Desktop users see.

A warning for anyone applying the $schema shim posted above: it fixes the rejection, but there is a second problem right behind it. Recent versions of the filesystem server replace all their allowed directories with the roots announced by the client (this is documented server behaviour). The client announces the session folder, so the directories from your config become unreachable. The tools load, and your vault is gone.

The shim below handles both. It strips $schema from tools/list responses, and it removes capabilities.roots from the initialize message (and drops roots/list_changed notifications), so the server falls back to its command-line arguments.

Tested today against v2026.8.31: 14 tools accepted, no dialect left in the schemas, and list_allowed_directories still returns the directory passed on the command line even though the client announced roots.

claude_desktop_config.json:

"filesystem": {
  "command": "node",
  "args": [
    "/path/to/strip-schema-dialect.mjs",
    "@modelcontextprotocol/server-filesystem",
    "/your/allowed/dir"
  ]
}

<details>
<summary>strip-schema-dialect.mjs</summary>

#!/usr/bin/env node
/**
 * MCP stdio shim.
 *
 * 1. Servers built on the MCP SDK (e.g. @modelcontextprotocol/server-filesystem)
 *    stamp their tool schemas with
 *      "$schema": "http://json-schema.org/draft-07/schema#"
 *    Claude Desktop / Cowork only validate JSON Schema 2020-12 and reject every
 *    tool of the server. This shim removes the "$schema" key from inputSchema /
 *    outputSchema in tools/list responses. With no dialect declared, the validator
 *    falls back to its default and accepts the schemas, whose structure is valid
 *    in both dialects.
 *
 * 2. Recent versions of the filesystem server replace ALL their allowed
 *    directories with the "roots" announced by the client (documented behaviour).
 *    The client announces the session folder, so the directories passed on the
 *    command line become unreachable. This shim removes `capabilities.roots`
 *    from the `initialize` message and drops `roots/list_changed` notifications,
 *    so the server falls back to its CLI arguments.
 *
 * Usage: node strip-schema-dialect.mjs <npm-package> [server args...]
 * Remove once the upstream incompatibility is fixed.
 */
import { spawn } from "node:child_process";
import readline from "node:readline";

const [pkg, ...rest] = process.argv.slice(2);
if (!pkg) {
  process.stderr.write("strip-schema-dialect: missing server package\n");
  process.exit(2);
}

const child = spawn("npx", ["-y", pkg, ...rest], {
  stdio: ["pipe", "pipe", "inherit"],
});

child.on("error", (e) => {
  process.stderr.write(`strip-schema-dialect: cannot start server: ${e.message}\n`);
  process.exit(1);
});
child.on("exit", (code, signal) => process.exit(signal ? 1 : code ?? 0));

// client -> server: hide roots support so the CLI directories are kept
readline.createInterface({ input: process.stdin }).on("line", (line) => {
  if (!line.trim()) return;
  let msg;
  try {
    msg = JSON.parse(line);
  } catch {
    child.stdin.write(line + "\n");
    return;
  }
  if (msg?.method === "initialize" && msg?.params?.capabilities?.roots) {
    delete msg.params.capabilities.roots;
  }
  if (msg?.method === "notifications/roots/list_changed") return; // not forwarded
  child.stdin.write(JSON.stringify(msg) + "\n");
});

const strip = (schema) => {
  if (schema && typeof schema === "object") delete schema.$schema;
};

// server -> client: clean tools/list responses
readline.createInterface({ input: child.stdout }).on("line", (line) => {
  if (!line.trim()) return;
  let msg;
  try {
    msg = JSON.parse(line);
  } catch {
    process.stdout.write(line + "\n"); // non-JSON: passed through untouched
    return;
  }
  const tools = msg?.result?.tools;
  if (Array.isArray(tools)) {
    for (const t of tools) {
      strip(t.inputSchema);
      strip(t.outputSchema);
    }
  }
  process.stdout.write(JSON.stringify(msg) + "\n");
});

</details>

Could this be reopened? It was closed by the stale bot after a CLI-only test, and the affected clients are Desktop and Cowork.

danielzarioiu · 14 days ago

Still reproducible on Desktop/Cowork — remote HTTP MCP variant, updater version 2.9939.4 (checked 2026-09-30)

Adding a non-CLI data point since the issue was closed on a Claude Code CLI repro and the CLI was never affected (it runs the older, lenient validator). This reproduction is Claude Desktop in third-party managed deployment mode (deploymentMode: 3p), Cowork chat engine, updater version 2.9939.4, macOS ARM64, against a remote HTTP MCP server — MongoDB Atlas (https://mcp.mongodb.com), i.e. not a local stdio server and not the filesystem extension.

What happens

  1. OAuth completes normally using the official Claude CIMD client identity (https://claude.ai/oauth/claude-code-client-metadata, the client id MongoDB ships in their mongodb-atlas plugin) — dynamic client registration is never attempted, tokens are stored, connector shows connected.
  2. tools/list succeeds: 21 tools discovered (atlas-list-orgs, atlas-list-projects, atlas-list-clusters, …). No ingestion-time rejection.
  3. Tool permission prompts render and are granted.
  4. Every tools/call fails identically, e.g. for all three read tools above (sanitized log, 2026-09-30):
[custom3p-mcp] server connected { name: 'MongoDB Atlas', toolCount: 21 }
Emitted tool permission request <redacted> for mcp__MongoDB_Atlas__atlas-list-orgs in session <redacted>
Received permission response for <redacted>: always (tool: mcp__MongoDB_Atlas__atlas-list-orgs)
[custom3p-mcp host] [directMcpHost:MongoDB Atlas] callTool failed: atlas-list-orgs: Tool 'atlas-list-orgs' 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 line is truncated by the SDK's own .slice(0, 200) on the message; the reported tool id / permission uuids / session id are redacted.)

tools/call is never sent to the MCP server

Confirmed by locating the bundled MCP TypeScript SDK client's throw-site: output-schema validators are compiled lazily at the first callTool() against the cached tools/list entry, and an uncompilable schema throws ProtocolError(InvalidParams, "Tool 'X' has an invalid outputSchema: …") before the request is sent — the SDK's own changelog documents this exact ordering. Consistently, nothing shows up on the server side: no Atlas API call is ever made, and no org/project identifiers leave the client.

Minimal reproducer

Any tool whose outputSchema is:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object"
}

MongoDB's actual schemas are otherwise completely ordinary (trivial zod-derived objects — no $ref, no definitions/$defs, no oneOf/anyOf, no format). The dialect marker alone is sufficient to reproduce the failure; nothing else about the schema matters.

Upstream SDK already fixed this class

modelcontextprotocol/typescript-sdk#2534 — "fix(validators): honor declared draft-07/06 JSON Schema dialects instead of rejecting them" (merged 2026-07-27, released in @modelcontextprotocol/client 2.0.0) — made the default validator dispatch on the schema's declared dialect: 2020-12, 2019-09, draft-07 and draft-06 are all honored, with unknown dialects still erroring. That PR's description matches this failure byte-for-byte ("a client with default options cannot call tools on those servers … client.callTool fails with -32602 before the request reaches the wire").

The error text observed on 2.9939.4 — "The default validator supports JSON Schema 2020-12 only" — matches the pre-#2534 code path (the current SDK message instead enumerates the four supported dialects). So the Desktop/Cowork host appears to bundle the older, restricted validator path. I'm not claiming a specific bundled SDK version — only the observable wording and behavior.

What this is NOT

  • not an OAuth problem (auth completes, tokens persist, connector stays connected);
  • not a server or managed-deployment delivery problem (21 tools listed, permissions work);
  • not a malformed MCP request, and not a server response validation problem — response validation never happens, because schema compilation fails before the network call.

Ask

Please ship the #2534-era validator behavior in Desktop/Cowork (or pass a pre-configured multi-dialect Ajv instance to the SDK's validator provider). This also fully explains the still-open filesystem report #88988; the server-side counterpart is tracked by MongoDB at mongodb-js/mongodb-mcp-server#1427.

digikittens · 14 days ago

Hopefully this will help people!

----------------------------------------
If you upgraded Claude Desktop recently and your MCP filesystem tools stopped working with an error like:

unsupported dialect: http://json-schema.org/draft-07/schema

Here's what happened and how to fix it.

The cause: Claude Desktop's AJV validator was upgraded to require JSON Schema 2020-12 only. The MCP package but @modelcontextprotocol/server-filesystem (and many other MCP servers) output draft-07 schemas that include a $schema key. Claude now rejects those tools entirely on startup — silently, or with the above error.

There are open issues on Anthropic's GitHub across IBM, n8n, Anki, Withings, Oura, and more. Still unpatched upstream.

How I built the fix (with Claude Code): I used Claude Code to diagnose the AJV validator version conflict, write a lightweight Python stdio proxy that strips the $schema key before Claude Desktop sees it, and package the whole thing as a macOS .pkg installer — all in one session. No modifications to your MCP server required, no config changes beyond pointing Claude at the proxy instead of the tool directly.

DigiKitten MCP Schema Bridge 🔗 https://github.com/digikittens/mcp-schema-bridge/releases

macOS,pkg installer — double-click, restart Claude Desktop, done. Uninstaller included.

One-command install (if you prefer terminal):

curl -fsSL https://raw.githubusercontent.com/digikittens/mcp-schema-bridge/main/digikitten-install.sh | bash

Free and open source.

Irony note: the fix for a Claude Desktop bug was built by Claude itself, in one session, with one user. Still waiting on the official patch.

Built by DigiKitten. For Amy. 💙

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 →