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

Goes well beyond annotations: declares billability, a one-review-in-flight-per-project constraint, per-workspace rate limiting, and the refusal contract (ok: false plus a next step, no work started). It also flags the disclaimer_md output obligation and clarifies that no changes are made, which is consistent with destructiveHint=false; the readOnlyHint=false reflects that it starts a job.

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?

Front-loads the core action in the first sentence and then layers constraints, prerequisites, and billing in short paragraphs. Every sentence carries operative information, though the prerequisite/refusal/rate-limit logistics could be tightened slightly.

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?

Since an output schema exists, return values need not be explained, and the description covers what an agent needs to decide and invoke correctly: prerequisites, billable/rate-limit constraints, in-flight limits, refusal behavior, and the disclaimer obligation for the user.

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% for the single project_id parameter, so the description carries the burden; it only implies scope via 'for one project' without naming the parameter or its expected form. It does add the disclaimer_md field context, but that is an output/adjacent field rather than the request parameter.

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 ('Start a ... security control gap review') and scopes it to one project. It clearly distinguishes itself from run_security_review and run_legal_exposure_review by framing the work as framework-context control observations (Cyber Essentials / CMMC L1-L2) rather than a generic security or legal review.

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?

It lists prerequisites (saved framework profile, eligible plan, allowlist) and states the negative scope ('does not determine framework standing'), which implies usage context. However, it never routes the agent explicitly against the close siblings run_security_review, run_legal_exposure_review, or get_control_gap_findings, so the when-vs-alternative decision is left to inference.

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