AI & agents

MCP Tool Manifest Inspector

Inspect MCP-style tool manifests locally for naming issues, weak descriptions, invalid input schemas, risky capabilities, and agent safety gaps.

Runs locally in your browser
Tools2
Findings4
High severity2
Medium severity1
Description is too thinMEDIUM · delete_user: Agents need descriptions that explain when to use the tool and what it returns.
Risky capability needs guardrailsHIGH · delete_user: Destructive, production, payment, admin, or credential-related tools should clearly describe approval and safety boundaries.
Required field missing from propertiesHIGH · delete_user: Required field reason is not defined in schema.properties.
Parameter description missingLOW · delete_user: Parameter userId should explain expected values, units, and constraints.

How to use this tool

Paste an MCP-style tool manifest as JSON or YAML.

Review findings about tool names, duplicate tools, descriptions, input schemas, required fields, and risky capabilities.

Fix the manifest before exposing the tools to an AI assistant, coding agent, or automation system.

Why MCP tool manifests need review

Tool manifests are the contract between an AI agent and the actions it can take.

Weak names, vague descriptions, missing input schemas, or invalid required fields make tools harder for agents to call correctly.

Risky tools such as delete, deploy, payment, admin, token, or credential operations need explicit safety boundaries outside the schema as well.

What the inspector checks

The inspector accepts a tool array or an object with a `tools` array.

It checks duplicate names, ASCII-safe naming, description quality, object input schemas, missing properties, invalid required fields, missing parameter descriptions, and risky capability language.

The scan runs locally in the browser and does not upload your manifest.

Agent safety beyond JSON Schema

A valid schema does not prove a tool is safe for autonomous use.

Destructive or production-facing tools should require confirmation, rate limits, audit logs, and strong authorization on the server side.

Descriptions should tell the model when to use a tool, when not to use it, and what result to expect.

Examples

Risky delete tool

This is flagged because the description is thin, the capability is destructive, and `reason` is required but not defined.

Input
{"name":"delete_user","description":"Delete user","inputSchema":{"type":"object","properties":{"userId":{"type":"string"}},"required":["userId","reason"]}}

Better search tool

Output
{"name":"search_docs","description":"Search public documentation and return matching pages with titles and URLs.","inputSchema":{"type":"object","properties":{"query":{"type":"string","description":"Search query."}},"required":["query"]}}

FAQ

Does this validate the full MCP specification?

No. It is a practical manifest inspector for common tool quality and safety issues, not a complete MCP compliance suite.

Is my manifest uploaded?

No. Parsing and inspection run locally in your browser and manifest contents are not stored for analytics.

Why are delete or deploy tools flagged?

Those capabilities can change production systems or destroy data. Agents should only use them with clear approval and server-side authorization boundaries.

Can a good schema make a dangerous tool safe?

No. JSON Schema helps the agent call the tool correctly, but safety also needs authentication, authorization, confirmation flows, rate limits, and audit logs.