retomar_sessao

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

No annotations are provided, so the description carries the burden. It mentions that outputs are saved automatically to a specific path, adding context about storage. However, it doesn't explicitly state whether this tool itself performs any modifications (e.g., it may only list existing scans), leaving some ambiguity about side effects. It does not contradict any annotations since none exist.

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 consists of exactly two sentences, with the first stating the core purpose and the second providing a useful detail (output storage location). It is front-loaded, free of filler, and every word adds value.

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 tool with a single parameter and no nested objects, the description is quite complete. It explains what the tool does, the context for use (resuming interrupted pentests), and where outputs are stored. It does not detail the output format, but an output schema exists, so that is not required. The only gap is some ambiguity about whether the tool modifies anything.

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 only parameter 'target' is described in the schema as 'Domínio ou IP do alvo' (domain or IP of the target), and the description adds an example ('exemplo.com.br', '192.168.1.10') which clarifies the expected format. Schema coverage is 100%, and the description enhances it with a concrete usage example.

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 verb 'Lista' (lists) and the resource 'todos os scans salvos em disco para um alvo' (all saved scans for a target), and explains its purpose 'permitindo retomar um pentest interrompido' (allow resuming an interrupted pentest). This distinguishes it from sibling scan-execution tools like 'scan_portas_nmap' or 'scan_nuclei'.

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 when to use the tool: when a pentest has been interrupted and you want to resume it without losing progress. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to decide. The sentence about automatic saving also gives a hint about where the scans reside.

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