Workflow: Run Pentest

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description is consistent with it (it returns instructions, not actions). It adds useful context beyond that: the step sequence including a credit check and domain-verification gate implies prerequisites and potential cost. It does not disclose the shape of the returned instructions or behavior when the target domain is unverified.

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, zero padding. The purpose and the full lifecycle scope come first, and the client-compatibility condition is placed last where it belongs.

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 two-parameter workflow-guidance tool with a fully documented schema and no output schema, this is nearly complete: it says what it returns, what the sequence covers, and when to prefer it. A brief note on what the instructions reference (e.g. that they call the start_pentest/get_findings tools) would close the last gap.

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% and the tier enum is fully documented in the schema (agent counts and durations), so the baseline of 3 applies. The description adds only 'against a target' and echoes the verified-domain requirement that the schema already states. No extra meaning about tier selection trade-offs is provided in the 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 ('Returns step-by-step instructions') and enumerates the lifecycle it covers: domain verification, credit check, launch, progress monitoring, findings summary, report offer. It also makes clear it is a guidance tool rather than an executor, which separates it from turbopentest_start_pentest. It stops short of explicitly naming that sibling as the alternative, so it is clear but not fully differentiated.

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?

Gives an explicit when-to-use condition and a counterfactual: use this in MCP clients (like Codex) that don't support the 'run_pentest' MCP prompt. That routes the agent meaningfully. It doesn't address when an agent should instead call turbopentest_start_pentest / get_pentest / get_findings directly, which are the obvious sibling alternatives for a client that does support multi-step calls.

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