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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description goes beyond that by adding domain behavior: assessments still run against Rev 2, so Rev 2 gaps must be closed regardless of Rev 3 implementations. This tells the agent what kind of advice the tool outputs, and 'what happened to a specific requirement' implies the tool reports changes like moved/added/rescinded.

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?

The description is compact: two sentences that front-load the core purpose, then provide targeted usage scenarios and a policy rationale. Every sentence earns its place with no redundancy or filler.

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 read-only tool with one optional parameter and no output schema, the description is outstanding. It covers the tool's function, the specific triggers for invocation, and the crucial domain rule about Rev 2 assessment obligations. The structural-summary behavior is covered in the schema, and the description adds meaningful policy context beyond the structured fields.

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?

The input schema has 100% coverage with a clear description and examples for the optional 'requirement' parameter. The description reinforces that the parameter is a specific requirement, but it adds no new semantic details beyond the schema. The baseline of 3 is appropriate because the schema carries the burden, and this description does not materially enhance parameter understanding.

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?

The description opens with a specific verb and resource: 'Explain how NIST SP 800-171 Rev 2 and Rev 3 differ, and what happened to a specific requirement between them.' This clearly distinguishes it from sibling tools like crosswalk_control (control-level mapping) and lookup_rev3_requirement (single-revision lookup) by focusing on the comparison between revisions and the fate of specific requirements.

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?

The description gives explicit call-this-when guidance: 'Call this when someone is implementing Rev 3 early, holds a Rev 3 citation and needs the Rev 2 obligation, or asks which revision applies to them.' It also identifies the underlying DoD policy driver. It does not explicitly name alternative tools to avoid, but the sibling list and the 'versus' framing create sufficient differentiation.

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