Repository navigation
server-filesystem: missing inputSchema.type breaks JSON Schema 2020-12 validators (all versions 0.6.2–2025.8.21) #4772
Description
Every published version of @modelcontextprotocol/server-filesystem omits the type: "object" field on inputSchema for its tools' JSON Schema. Clients that validate tools/list responses strictly against JSON Schema draft 2020-12 reject the server outright with an error like:
Invalid result for tools/list: [{"code":"invalid_value","values":["object"],"path":["tools",0,"inputSchema","type"],"message":"Invalid input: expected "object""}]
Impact: In Claude Desktop specifically, this causes the filesystem server to work normally in the main chat window (which tolerates the missing field) but fail to start under the "Cowork and Code sessions" shared-pool context, which validates strictly. Log excerpt:
[filesystem] [error] Couldn't start for Cowork and Code sessions. Error: Invalid result for tools/list: ... "path":["tools","0","inputSchema","type"] ... "message":"Invalid input: expected "object""
Root cause (verified by direct inspection): Every version of the package from 0.6.2 through 2025.8.21 was checked by spawning the server and inspecting its raw tools/list JSON-RPC response directly — inputSchema.type is undefined for every tool in every version. This is not a regression introduced by a specific release; it's present from the first published version. It cannot be worked around by pinning to an older or newer version.
Suggested fix: Add type: "object" to each tool's inputSchema in the server's tool definitions (likely a one-line fix per tool, or a fix in the shared schema-generation helper if one is used).
Separately noted (different, unrelated bug): The reference server-memory package defaults its outputSchema generation to JSON Schema draft-07 dialect instead of 2020-12 (via zod-to-json-schema's default target), which trips the same class of validator for versions ≥ the release that added outputSchema. Pinning server-memory to 2025.9.25 (before outputSchema was added) avoids this.
Activity
Tiancheng-Xu commentedon Sep 7, 2026
I’d like to take this. I’ll add a regression at the tools/list boundary that asserts every filesystem tool advertises an object input schema, then make the smallest registration/schema change needed so strict JSON Schema 2020-12 clients receive
type: "object"without changing tool arguments. I’ll keep the fix scoped to server-filesystem and run its build and Vitest suite.anythingoah commentedon Sep 8, 2026
Did this surface as a hard validator rejection, or did it silently pass and cause weirder downstream behavior? Also curious, did you catch this because you upgraded a validator, or because something using this server just started failing?
cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. On the v2 line every filesystem tool schema is an object schema declaring JSON Schema 2020-12, and tests pin type object on tools/list, so strict 2020-12 validators accept it.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.