websex_feroxbuster

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

With no annotations, the description carries the full burden and does add real execution context: feroxbuster is invoked directly with argv tokens and shell parsing is never used, and it runs inside the engagement namespace. However it does not disclose what feroxbuster actually does to a target, whether requests are sent (network side effects), rate/aggressiveness characteristics, or permissions required.

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 short, front-loaded sentences with no filler; the identity and execution model lead, and the path convention follows. Efficient and readable, though slightly terse relative to what it omits.

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 needn't be explained, but for a 4-parameter tool with zero schema coverage and no annotations, the definition leaves engagement_id and stdin undocumented, provides no usage context, and never describes what the tool does to the target. Not sufficient for correct invocation.

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% across 4 parameters, so the description must compensate. It adds meaning for 'arguments' (argv tokens, not a shell string) and 'working_directory' (relative paths resolve to engagement artifacts), but leaves 'engagement_id' and 'stdin' completely unexplained, so half the parameters remain opaque.

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+resource: run feroxbuster from the WebSex web toolkit. It is clear what the tool does, but it offers no differentiation from the many sibling directory/URL fuzzing tools (gobuster, ffuf, dirb, dirsearch, wfuzz), so an agent can't tell from the text alone why it should pick feroxbuster over those.

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 gives operational hints ('runs from the selected engagement namespace', 'use relative paths for engagement artifacts') but never says when to use this tool versus the sibling dir-busting alternatives, nor any preconditions such as needing a live target or wordlist. No when/when-not guidance at all.

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