Ssti Probe

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

The description goes well beyond the annotations (destructiveHint: true, readOnlyHint: false) by disclosing that it requires human approval, that it cannot be tricked into RCE, and that its scope is limited to detection, not exploitation. It explicitly defines the finding criteria and leaves proof of RCE to a human decision. This is exemplary transparency that exceeds what the annotations alone convey.

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 structured effectively: it opens with the exploit/human-approval warning, then covers parameters, then defines the finding and limitations. Every sentence adds value, and the length is justified by the tool's complexity. It is front-loaded with the most important safety constraint. Slightly more brevity could be achieved, but the organization is strong.

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 complex exploit tool, the description covers purpose, parameters, limitations, and expected behavior. It implicitly suggests a sequence (use http_probe first to identify the stack) but does not explicitly state that prerequisite. The output schema exists, so not describing return values is acceptable. The description is largely complete, but the explicit prerequisite of http_probe could be stated to make it fully self-contained.

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. It explains injection_points (Q,B,H,C) and engine (optional, narrows to a specific engine) in detail, and target is self-evident. However, the 'level' parameter is not explained at all; its meaning (likely probe intensity) is left to inference. While the most critical parameters are covered, the omission of level prevents a higher score.

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 clearly states the tool's purpose: 'Detect server-side template injection with SSTImap.' It uses a specific verb (Detect) and resource (server-side template injection), and distinguishes itself from siblings like cmdi_probe and nosqli_probe by naming the specific vulnerability class. It also defines what constitutes a hit (arithmetic evaluated in a template, e.g., {{7*7}} returning 49), removing ambiguity.

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 provides clear guidance on when to use the tool: it explains injection_points selection (Q,B,H,C) and defaults, notes that engine narrowing should follow http_probe results, and explicitly states that headers and cookies are usually not the reported sink. It also clarifies what the tool cannot do (denied shell, eval, file-transfer flags), setting boundaries. However, it does not explicitly compare to sibling tools or state 'use this instead of X', so it falls short of a perfect 5.

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