Tools / MCP Tool Schema Linter
MCP Tool Schema Linter
Check a Model Context Protocol Tool definition — or a whole server's tools/list response — against the spec right in your browser. Nothing is uploaded.
Paste a single Tool object, a bare array of tools, or a tools/list response ({ "tools": [...] }) to lint every tool at once.
- info /title
No "title" set — clients fall back to "name" for display. A human-facing title improves UX.
- warning /description
Description is very short (<10 chars) — likely not enough for a model to disambiguate this tool from others.
- warning /annotations/destructiveHint
Meaningless combination — "destructiveHint" only applies when "readOnlyHint" is false.
- error /inputSchema/properties/reason/$ref
External $ref URIs must not be auto-dereferenced per spec; this schema references an external URI: https://example.com/schemas/reason.json
// About this tool
MCP Tool Schema Linter
This linter checks MCP Tool objects against the Model Context Protocol spec — not generic JSON validity, but the constraints specific to tool definitions: required fields, the inputSchema/outputSchema root-type rule, annotation hint semantics, and safe use of $ref in schemas. Paste one Tool object, or a whole tools/list response, and every tool gets its own findings.
It's built against the current spec plus the 2026-07-28 release candidate, which newly permits $ref, $defs, and composition keywords (allOf/anyOf/oneOf/not) inside tool schemas. That surface area is new, so this tool specifically flags the two failure modes it introduces: external $ref URIs (which must not be auto-dereferenced) and unbounded schema nesting.
Findings are grouped into Structure, Annotations, and Schema safety, each with a severity — error for spec violations, warning for likely bugs, info for completeness notes. Everything runs in your browser; the tool definition you paste is never uploaded.
// When to use it
Review a tool before publishing an MCP server
Paste each Tool definition to catch a missing inputSchema type or a description too thin for a model to act on, before clients see it.
Audit annotations before shipping destructive tools
Confirm readOnlyHint, destructiveHint, and idempotentHint are set consistently — a mis-set default can make a safe tool look destructive to a client that gates on hints.
Check a schema after adding $ref/$defs
The 2026-07-28 RC allows composition keywords in tool schemas; this catches external $ref URIs and excessive nesting depth before they reach a client.
Audit a whole server's tool roster at once
Paste the server's tools/list response directly and get a per-tool breakdown, so a bad tool doesn't hide among the good ones.
// Questions
Is my tool definition uploaded anywhere?
No. Linting runs entirely in your browser via JavaScript. Nothing is sent to a server.
Which MCP spec revision does this check against?
The 2025-11-25 Tool schema plus the 2026-07-28 release candidate, which adds $ref/$defs/composition support to tool schemas — the source of the $ref and nesting-depth checks.
Why does inputSchema need type: "object" at the root?
MCP constrains tool input schemas to an object root, unlike generic JSON Schema which allows any root type. A tool whose inputSchema root isn't an object is spec-non-compliant.
Why flag a tool with no annotations at all?
MCP clients apply defaults when annotations are absent: readOnlyHint=false, destructiveHint=true. A genuinely read-only tool with no annotations will be treated as destructive by clients that respect hints, which can trigger unnecessary confirmation prompts.
Does this validate arguments passed to the tool, or the tool definition itself?
The definition itself — the Tool object a server declares. To validate arguments against a tool's inputSchema, use the JSON Schema Validator.
Can I lint my whole server's tool list at once?
Yes. Paste a bare array of Tool objects, or a full tools/list response ({ "tools": [...] }), and each tool is linted individually with its own findings and status.
// Related tools