MCP Tool Schema Validator

Paste a single MCP tool definition or an array of them and get an instant pass/warn/fail report. The validator checks the Model Context Protocol tool schema contract: name regex, description quality, inputSchema structure, and that every required field is declared in properties.

How to use the MCP Tool Schema Validator

Paste your MCP tool JSON — either a single tool object or a JSON array of tool objects — and click Validate. Results appear for each tool individually:

• PASS — the field passes its check.
• WARN — not a hard spec violation, but a likely mistake (e.g. description too short to be useful).
• FAIL — violates the MCP tool schema contract; this tool will be rejected by the protocol or silently ignored by the client.

Each tool's card lists every check with its status and a message. Fix all FAILs first, then address WARNs. Click Example to load one valid and one broken tool definition so you can see both states.

The MCP tool schema contract

The Model Context Protocol (MCP) standardises how AI assistants discover and call external tools. A tool definition is a JSON object with three required top-level keys: name, description, and inputSchema. The name must match the pattern ^[a-zA-Z0-9_-]{1,64}$ — alphanumeric, underscores, and hyphens only, 1-64 characters. Spaces, dots, and slashes are rejected by the protocol and cause the tool to be invisible to the model. The description field is optional in the JSON sense but critical in practice: it is the primary signal the model uses to decide whether to call a tool at all. A missing or one-word description almost always means the tool is never invoked.

The inputSchema must be a JSON Schema object with "type": "object" at the top level. The properties key maps parameter names to their schemas; the optional required array lists which parameters the caller must supply. A common bug is declaring a field in required that does not appear in properties — this creates a contract the client cannot satisfy, resulting in a validation error at call time. Another common issue is omitting inputSchema entirely for tools with no parameters; the correct form is {"type": "object", "properties": {}}, not a missing key.

Because MCP is consumed by language models, schema quality directly affects reliability. Vague descriptions, misnamed parameters, and missing type annotations all reduce the probability that the model calls the tool correctly. Think of the tool definition as an API doc written for an LLM reader: precision and brevity both matter.

Common use cases

• MCP server development — validate tool definitions during development before registering them with a client, catching schema errors before they manifest as silent failures.
• CI quality gate — paste your tool JSON into this validator as part of a pre-merge review to enforce schema compliance on every change.
• Debugging invisible tools — if a tool never gets called by the model, check whether its name contains illegal characters or its description is too short.
• Learning the MCP spec — use the Example button to see what a valid vs invalid definition looks like side-by-side before writing your own.
• Porting tools from other formats — when converting OpenAPI specs or JSON Schema definitions to MCP format, validate the result immediately to catch incompatibilities.