analyze_toolsInspect MCP tool metadata to identify security risks. Analyze tool names, descriptions, and input schemas to receive SAFE, REVIEW, or HIGH RISK verdicts without executing target tools.
Basic Lite-edition inspection of MCP tool names, descriptions and JSON Schemas without executing target tools.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes |
Changes observed during successful MCP inspections.
v0.1.0-lite.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses that the tool does not execute target tools, implying a non-mutating safety profile. It does not describe output format, limitations, or what 'Basic Lite-edition' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence that front-loads the action and includes a useful safety qualifier. 'Basic Lite-edition' is somewhat redundant and undefined, but the overall structure is tight and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter inspection tool, the description covers the input domain and the non-execution safety aspect. However, with no output schema and no sibling tools, the complete absence of return-behavior information and the undefined 'Lite-edition' scope leave meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only property names and 0% description coverage, so the description must supply parameter meaning. It connects the lone 'tools' parameter to MCP tool metadata (names, descriptions, JSON Schemas), which helps. But it adds no constraints, optionality guidance, or format details, so it only partially compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('inspection' of 'MCP tool names, descriptions and JSON Schemas') and a clear resource scope. It also explicitly distinguishes the tool from executing target tools. 'Basic Lite-edition' is vague, but the core purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing target tools' implies this is the safe, lightweight metadata-analysis choice rather than a runtime tool. However, it does not explicitly name alternatives, prerequisites, or conditions under which this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.