Analyzes Python source code via AST deconstruction to detect unsafe constructs, shell injection, dynamic eval, and socket egress before autonomous tool calls execute.
Deconstructs and analyzes Python code AST for unsafe constructs, shell injection, dynamic evaluation, and socket egress.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v2.2.3v0.1.2v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the types of unsafe constructs it looks for, but does not explicitly state whether the inspected code is executed, what permissions are needed, or whether the operation has side effects. Because an output schema exists, return-value explanation is not required, but the safety profile remains partially unclear.
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 a single front-loaded sentence with no filler. It immediately states the analysis scope and lists the detection categories, so every phrase earns its place.
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?
Given the tool has one required parameter and an output schema, the description covers the essential purpose and detection scope. It is slightly incomplete regarding sibling-tool routing and input-format expectations, but it does not need to explain return values because an output schema is present.
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?
Schema description coverage is 0% for the single required parameter. The description implies the input is Python source code suitable for AST analysis, which adds some meaning beyond the bare 'Code' title, but it does not clarify format expectations such as snippet vs. full file, size limits, or encoding.
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 verb and resource: deconstructs and analyzes Python code ASTs for unsafe constructs, shell injection, dynamic evaluation, and socket egress. It clearly distinguishes what the tool inspects, though it does not explicitly differentiate itself from the sibling tools inspect_tool_arguments or get_containment_status.
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 description gives no explicit guidance on when to use this tool versus alternatives. It implies a security-inspection context but does not state when-not-to-use or name any sibling tool as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.