websex_whatweb

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that shell parsing is never used (argv tokens) and that it runs from the selected engagement namespace with relative paths for artifacts. However, it doesn't describe output format, rate limiting, or authentication requirements beyond the engagement context.

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?

Three sentences, each serving a clear purpose: stating the action, clarifying execution mechanics, and noting working directory context. It is front-loaded with the core action and avoids unnecessary verbosity.

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?

An output schema exists, so return values need not be explained. However, with 4 parameters, 0% schema coverage, and no annotations, the description is incomplete: it doesn't clarify the required 'arguments' array format, the optional 'stdin' behavior, or defaults for 'working_directory'. For a tool that executes an external binary, more context is needed to invoke it correctly.

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?

With schema description coverage at 0%, the description must compensate significantly. It mentions 'argv tokens' which maps to the 'arguments' parameter and 'engagement namespace' mapping to 'engagement_id', but does not explain stdin, working_directory defaults, or the expected format of arguments, leaving critical parameters undocumented.

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 a specific verb+resource combination: running whatweb from the WebSex web toolkit. It distinguishes this tool from generic execute/bash tools by clarifying it executes whatweb directly with argv tokens. However, it does not explicitly compare to sibling reconnaissance tools like nikto or httpx that might also fingerprint web technologies.

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?

There is no explicit guidance on when to use this tool versus alternatives. A reader might infer it's for web fingerprinting based on the name, but the description doesn't say when to choose whatweb over nikto, nuclei, or httpx, nor does it state any prerequisites or exclusions.

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