pentest_exploit_msf_run

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

No annotations exist, so the description carries the full burden and does well: it discloses the two prerequisite rule flags, the exact confirmation-token mechanism, and that execution is live rather than simulated. It does not state whether actions are reversible, what happens on partial failure, or what a successful run returns, which keeps it below the top score for a high-impact exploit tool.

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 lines, front-loaded with the action, then the gating conditions, then the human-confirmation warning in the terminal position where it has most weight. No filler, though the line breaks fragment what could be two tight sentences.

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 live-exploitation tool with no annotations and no output schema, the description covers the safety gates and confirmation protocol well. It is not quite complete: module/target/options formats and the shape of a result or failure are left to the agent to guess.

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 coverage is 0%, so the description must compensate. It adds real meaning for confirm_phrase (must equal the engagement_id), but leaves module (path vs. short name), target (IP, host, CIDR?) and the options string-map keys entirely undefined in both schema and description.

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: run a Metasploit module against an in-scope target, with 'for real' distinguishing it in spirit from pentest_exploit_msf_check. It stops short of naming the check/search siblings explicitly, so the differentiation relies on the agent inferring that msf_check is the dry-run counterpart.

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?

Strong when-not guidance: requires rules.exploit_authorized and rules.allow_payload_execution to be true, requires confirm_phrase to equal the engagement_id, and explicitly says not to call without human confirmation. It never names pentest_exploit_msf_check as the safe alternative to try first, which is the one obvious routing gap.

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