A server publishes a tool that takes no parameters, with its inputSchema set to null, and several clients refuse to use the tool. Which fix aligns with the 2026-07-28 tools specification?
Select an answer to reveal the explanation.
Short Explanation
Even if your tool takes no inputs, it needs a real schema — think of it as an empty form, not a missing one. The recommended version is an object that allows no properties. Null, an empty array or leaving it out all break the contract.
Full Explanation
Every tool definition includes an inputSchema, and the tools specification states that it MUST be a valid JSON Schema object and not null. For tools with no parameters it gives two valid approaches: an object type with additionalProperties set to false, which is recommended because it explicitly accepts only empty argument objects, or a plain object type, which accepts any object. Clients that reject a null schema are behaving correctly, and the fix belongs on the server. Omitting inputSchema is not valid, because the field is part of every tool definition and clients rely on it to validate arguments and to describe the tool to the model. An empty array is not a JSON Schema object and has no documented meaning as a no-argument marker. Adding a $schema field does not rescue a null value; $schema selects a dialect for a schema object, and no dialect turns null into a valid MCP input schema. Exam caveat: the plain object form is valid but looser, since it would allow unexpected properties through, which is why the stricter form is recommended. Operational check: after the fix, call tools/list, confirm the tool's inputSchema is an object with additionalProperties false, and verify that a tools/call with empty arguments succeeds while one with extra arguments is rejected.