How to use the MCP Tool Schema Validator
- Paste your JSON. Use one tool object with name, description and inputSchema, an array of tools, an object with a tools array, or the full JSON-RPC response to tools/list.
- Fix the errors first. Errors break the specification, such as a missing inputSchema or a required name that is not in properties. Each message names the path of the field to change.
- Work through warnings and notes. Warnings are likely to confuse an agent or a stricter client. Notes are improvements, such as adding an example value to a parameter.
- Read the agent preview. The preview shows the name, description and each parameter with its type and whether it is required, which is the information an agent works from. If it reads badly to you, it will read badly to a model.
What the validator checks and where the rules come from
Method and sources
The rules follow the MCP specification page for tools on modelcontextprotocol.io (version 2026-07-28, read in October 2026). It lists name, optional title, description, optional icons, inputSchema, optional outputSchema and annotations as the fields of a tool. It states that inputSchema "MUST be a valid JSON Schema object (not null)", defaults to JSON Schema 2020-12 when there is no $schema, and recommends { "type": "object", "additionalProperties": false } for a tool with no parameters.
On names, the same page says tool names SHOULD be between 1 and 128 characters, case-sensitive, limited to ASCII letters, digits, underscore, hyphen and dot, and unique within a server. Because the specification words these as SHOULD, a breach is reported as a warning here, although a name with spaces or symbols is likely to fail in practice.
Checks that go beyond the specification
These are our own judgement calls, labeled as such in the results and never shown as errors (a name rule is a warning for the same reason): a name over 64 characters or containing a dot (stricter clients reject it), a description over about 1024 characters, schema keywords that some clients drop when they convert a schema (patternProperties, if/then/else, not, dependentSchemas, unevaluatedProperties, propertyNames), parameters without types or descriptions, missing example values, and parameter names that mix snake_case and camelCase.
The agent preview is a plain-text rendering built from the same fields. Real clients format tools their own way, so it shows the information available to a model, not its exact prompt.
Limitations
This is a structural check, not a full JSON Schema validator. It does not verify that every keyword is used correctly, resolve references outside the pasted schema, or test that your server actually accepts the arguments the schema allows. Passing here means the definition is well formed and readable, not that the tool works.
Frequently asked questions
What does MCP require in a tool definition?
A name, an inputSchema and, in practice, a description. The specification also allows an optional title, icons, outputSchema and annotations. The inputSchema must be a valid JSON Schema object and cannot be null. When it carries no $schema, 2020-12 is assumed.
Why does the validator mention a 64 character name limit when the spec says 128?
The specification says names should be 1 to 128 characters and may include dots. Some clients and model APIs are stricter, accepting only letters, digits, underscore and hyphen up to 64 characters. The validator labels each warning as a specification SHOULD or a stricter-client concern, so you can tell them apart.
Why is a long description a problem?
The description is sent to the model on every request that lists tools, so a long one costs context each time and buries the rules that matter. The validator warns past roughly 1024 characters. That figure is a practical guideline, not part of the specification.
What does the validator say about $ref?
A local reference such as #/$defs/Filter is fine when that definition exists in the same schema, and an error when it does not. A reference to an outside address is a warning, because clients cannot be expected to fetch it. Inlining the definition is the most portable choice.
Does it check my server or call my tools?
No. It reads only the JSON you paste, in your browser. It does not connect to a server, run a tool or send your definitions anywhere.
Is the TimeToPost example the live tool list?
No. It is a short static snapshot of five tools copied from TimeToPost's MCP server code on 2026-10-10, so you can see the validator on a real definition. Nothing is fetched when you press the button.