inputSchema
inputSchema is the JSON Schema object describing a tool's arguments. It tells the client what parameters exist, their types, and which are required, so a model can construct a valid call without a human writing an integration. It is required on every tool and was present on all 288 tools we read.
Updated
What is inputSchema?
inputSchema is a JSON Schema object attached to each MCP tool, describing the arguments that tool accepts. It names the properties, gives each one a type, and lists which are required.
This is what lets a model call a function it has never seen before. The schema is the contract.
What the spec requires of it
The current spec revision (2026-07-28) says an inputSchema MUST be a valid JSON Schema object and never null. The root is an object schema, "type": "object", because a call's arguments travel as one JSON object of named parameters.
When the schema carries no $schema field, it is read as JSON Schema 2020-12. A server that writes draft-07 schemas says so explicitly with "$schema": "http://json-schema.org/draft-07/schema#".
A tool with no parameters still needs a schema. The spec recommends {"type": "object", "additionalProperties": false}, which accepts only an empty object; a bare {"type": "object"} is also valid but accepts anything.
To see a server's schemas in practice, read its tools/list response: every tool object in it carries its inputSchema.
Why is it the field that matters most?
Because it is the only structural guarantee in the response. The description tells a model what a tool is for in prose, which can be vague; the schema tells it exactly what shape the call must take, which cannot.
It is also the field with no fallback. A missing description makes a tool hard to choose. A missing or wrong inputSchema makes it impossible to call correctly.
How consistently do servers provide it?
Universally, in our sample. All 288 tools returned by 14 servers on 5 August 2026 carried an inputSchema, the same 100% coverage name and description had.
That is the strongest consistency finding in the corpus, and it is what makes MCP usable in practice: a client can rely on the schema being there and validate against it, rather than probing.
Example
A search tool's inputSchema typically declares a single required string:
{"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]}
A model reading that knows it must send an object with a query string and nothing else is mandatory. https://mcp.exa.ai/mcp returned 2 tools on 5 August 2026, each with a schema of exactly this kind, which is enough for a client to call them without any hand-written integration code.