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

Annotations already declare this a safe, idempotent, non-destructive read, so the description's job is to add anything else the agent needs. It adds a real access gate ("Requires ClevSec Pro") and describes the deliverable's contents and priority ordering, which go beyond the structured fields. It stops short of describing volume, pagination, or error behavior for a Pro-gated tool, so not a full 5.

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: trigger/ordering first, then output contents, then the licensing prerequisite. No filler and no restatement of the tool name or schema.

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?

No output schema exists, so the description must convey what comes back, and it does enumerate the output components including the roadmap. Combined with the tier requirement and the answers-count-as-level-1 rule in the schema, an agent can invoke this correctly; only return shape/formatting details are absent.

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 50%: the `answers` parameter is well documented in the schema itself (question id to level, unanswered = 1), while `target_level` carries only a bare enum. The description partially compensates by tying the target level to "3 or 4" and explaining that the listing is relative to it, but it adds little on the answers structure beyond what the schema already says.

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 output: a list of capabilities below the target level, each with a next action, NIST CSF 2.0 subcategory, NIS2 article, and a 30/60/90-day roadmap. This is unmistakably distinct from siblings like nis2_remediation_plan or iso27001_remediation_plan, and even names its upstream tool (maturity_assessment).

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?

"Use after maturity_assessment when the user wants to raise their maturity" gives both the precondition and the triggering intent, and the parenthetical "govern and identify first" tells the agent how results are prioritized. The agent needs no inference to pick this over maturity_assessment.

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