kali_run_sqlmap

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the default invocation is '--batch --banner' and 'non-interactive banner scan', which is useful. However, it does not mention the potential impact of custom 'options' flags, output behavior, or any caution about running a security tool that could perform intrusive database operations.

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 concise and well-structured: one purpose sentence followed by a compact Args block. It front-loads the tool's purpose, uses an example to remove ambiguity, and contains no filler. Every sentence 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?

For a two-parameter wrapper with an output schema, the description covers the core invocation surface: tool purpose, target URL format, optional flags, and default non-interactive mode. It is slightly incomplete in not providing usage boundaries or risk context for a security tool, but nothing essential to making a correct call is missing.

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%, so the description must compensate, and it does. It explains target_url with a concrete example URL, and options as 'Sqlmap flags' with a clear default and mode. Both parameters are meaningfully documented beyond their bare schema names and types.

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 ('Runs'), a specific tool ('Sqlmap'), and its domain ('SQL injection and database takeover'), which clearly distinguishes it from siblings like kali_run_nmap and kali_run_gobuster. The example target URL further clarifies what the tool operates on. This is specific, non-tautological, and easy for an agent to match to the right task.

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 implies the tool is for SQL injection testing through phrases like 'SQL injection and database takeover' and the vulnerable-URL example, but it never explicitly states when to choose this tool over alternatives or when not to use it. No sibling tools or exclusion conditions are mentioned, so usage guidance is only implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.