Escaneo estático completo

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that with 'sin ejecutarla' (the target code is never run) and discloses the aggregate-and-deduplicate post-processing; however it says nothing about runtime cost, that semgrep/OSV/Trivy need network and downloadable rule/DB data, or what happens when a scanner is missing.

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?

Two sentences, densely packed but front-loaded with the core action and organized by scanner category via parentheticals. The category-by-category structure earns its space, though the single run-on sentence with nested parentheses is harder to scan than a bulleted breakdown.

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 7-parameter orchestrator with no output schema, the description omits important context: what the merged/deduplicated result actually contains (per-scanner sections, counts, finding IDs usable with finding_get), rough runtime expectations, and how missing or uninstalled scanners are handled. The composite nature of the tool is well conveyed, but an agent still lacks enough to set expectations before invoking it.

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 100%, so the schema already documents all seven parameters, which sets the baseline at 3. The description adds some conditional semantics not in the schema, notably that Bandit only applies when Python is present and that Gitleaks walks git history when a .git exists, but it does not clarify the interaction between `tools` and the individual engine-specific parameters.

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?

States a specific verb and resource ('Analiza una carpeta de código sin ejecutarla') and enumerates exactly which engines run under each category (SAST: Semgrep/Bandit; SCA: OSV-Scanner+Trivy; secretos: Gitleaks/Trivy; IaC: Trivy misconfig) plus the merge/dedupe step. It implicitly distinguishes itself from narrower siblings like scan_iac or scan_codeql by showing they are sub-components here, but never names those alternatives explicitly.

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 makes clear this is a broad, all-in-one scan, so the intended usage is inferable, and there is no explicit when-to-use/when-not statement. An agent must deduce on its own that scan_iac or scan_codeql should be preferred for a narrower or non-overlapping scan, and no prerequisites (network access, installed scanners, repo containing a language) are stated.

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