websex_hydra

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

With no annotations, the description carries the full behavioral burden, and it does disclose real execution semantics: hydra is invoked directly with argv tokens and never through a shell, runs from the engagement namespace, and expects relative artifact paths. It omits meaningful traits for a credential-attack tool such as account-lockout risk, target scope, or whether output is persisted, so it adds value without being complete.

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 tight sentences with the core action front-loaded and no filler. It could be trimmed slightly, but every sentence carries execution-model information rather than restating metadata.

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 described, and the description covers the invocation model adequately. For a credential-attack tool with zero annotations and zero schema coverage, however, it is still missing guidance on targets, blast radius, and argument conventions that an agent would need to call it safely.

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 loosely maps three parameters (arguments as argv tokens, engagement_id via the engagement namespace, working_directory via relative paths) but leaves stdin entirely unexplained and gives no constraints on the arguments array itself, which is the core payload.

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?

Names a specific verb (run) and resource (hydra) and frames it as part of the WebSex credentials toolkit, so the agent knows this invokes the hydra binary. However, it never distinguishes hydra from closely related siblings such as websex_medusa or websex_patator, which cover overlapping credential-attack territory.

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 when-to-use guidance and no mention of alternatives, even though medusa and patator are direct sibling overlaps. The only usage-adjacent content is the mechanics (argv tokens, relative paths, engagement namespace), which is not the same as telling the agent when this tool is the right choice.

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