Built-in Filesystem connector: every tool call rejected with "invalid outputSchema: JSON Schema declares an unsupported dialect (draft-07)"

### What happened?

Every tool of the built-in local "File System" MCP connector (@modelcontextprotocol/server-filesystem) fails deterministically on the first call. The tool call is rejected client-side, before ever reaching the server, with:

```
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
```

The same error occurs for all 14 tools (list_directory, read_text_file, write_file, move_file, create_directory, ...). The server shows as connected (state: "announced"); only tool calls fail.

### What did you expect to happen?

Tool calls to the filesystem connector should succeed. Since the server itself has always stamped a draft-07 "$schema" on its inputSchema without issue, the client should accept (or ignore) the same dialect declaration on outputSchema instead of hard-failing before the call ever reaches the server.

### Steps to reproduce

In Claude Desktop, add the local "File System" connector pointing to any folder.
Ask Claude to list that folder (or call any filesystem tool).
Every tool call fails with the outputSchema/draft-07 error above.

Tested without effect: full app restart, disconnecting/reconnecting the folder, npm cache clean --force, full uninstall + reinstall of the app.

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

filesystem (@modelcontextprotocol/server-filesystem)

### Error messages or logs

```shell
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

Same error for all 14 tools (list_directory, read_text_file, write_file, move_file, create_directory, ...).
```

### Additional context

Environment: Claude Desktop 1.49585.0 (MSIX), Windows 11 Pro 10.0.26200, x64. Claude for Teams plan. Connector: built-in "File System" (local MCP), launched by the app via npx @modelcontextprotocol/server-filesystem (resolves to latest, currently 2026.8.31). Node.js 24.19.0.

Root cause (verified by direct MCP handshake probes: initialize, initialized, tools/list over stdio, against multiple server versions):

server version 2025.8.21: 14 tools, 0 with outputSchema
server version 2025.11.25: 14 tools, 14 with outputSchema, dialect draft-07
server version 2025.12.18: 14 tools, 14 with outputSchema, dialect draft-07
server version 2026.1.14: 14 tools, 14 with outputSchema, dialect draft-07
server version 2026.7.4: 14 tools, 14 with outputSchema, dialect draft-07
server version 2026.7.10: 14 tools, 14 with outputSchema, dialect draft-07
server version 2026.8.31 (latest): 14 tools, 14 with outputSchema, dialect draft-07

Since 2025.11.25, server-filesystem attaches an outputSchema to all tools, generated with zod-to-json-schema, which stamps "$schema": "http://json-schema.org/draft-07/schema#" on every schema. The Claude client validates tool results against outputSchema using the MCP SDK's default Ajv validator, which only accepts JSON Schema 2020-12 and hard-fails on a declared draft-07 dialect. Result: an official Anthropic client rejects 100% of the tool calls of an official Anthropic reference server, in its default configuration. The same draft-07 stamp has always been present on inputSchema without causing failures; the regression is specific to the new strict outputSchema validation path.

No published server version passes both client validations. Attempting to work around the issue by pinning an older server version revealed a second, independent client-side validation that rejects the OLD versions. The client validates MCP servers at two stages, and no published version of the official filesystem server passes both:

server version >= 2025.11.25, including latest: tools/list validation (inputSchema shape) passes; tool-call validation (outputSchema dialect) is rejected with the draft-07 dialect error above.
server version <= 2025.8.21: tools/list validation (inputSchema shape) is rejected with the error below; tool-call validation (outputSchema dialect) passes since there is no outputSchema.

Pinning @modelcontextprotocol/server-filesystem@2025.8.21 produces this at startup (old versions emit $ref/definitions-wrapped inputSchemas without a top-level type: "object"):

```
MCP filesystem: Couldn't start for Cowork and Code sessions. Error: Invalid result for
tools/list: [ { "code": "invalid_value", "values": [ "object" ], "path": [ "tools", 0,
"inputSchema", "type" ], "message": "Invalid input: expected \"object\"" }, ... ]
```

So an official Anthropic client currently rejects every published version of the official Anthropic reference filesystem server: new versions at call time, old versions at announce time.

Suggested fixes, any one resolves it. Client: configure the validator to accept draft-07 (pass a pre-configured Ajv instance, as the error message itself suggests), or strip/ignore the $schema member before validation. Server: emit 2020-12 schemas (e.g. switch to zod-to-json-schema target "jsonSchema2020-12", or z.toJSONSchema from zod v4). App: pin the bundled connector to a known-compatible server version instead of latest.

Workaround for affected users: since no published version passes both validations, pinning alone is not enough. The only working workaround found is a local stdio shim that launches the latest server and strips outputSchema (and the $schema member of inputSchema) from tools/list responses on the fly, registered through a manual mcpServers entry in claude_desktop_config.json:

```json
{
"mcpServers": {
"filesystem": {
"command": "node",
"args": ["C:\\path\\to\\filesystem-shim.mjs", "C:\\path\\to\\allowed\\folder"]
}
}
}
```

Verified working: tools/list accepted, all 14 tools callable. (Shim source available on request - approximately 40 lines, pure JSON-RPC passthrough with tool-list sanitization.)