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

The description adds a significant behavioral guarantee beyond the annotations: the server never requests assessment notes or reports and instructs the AI to keep them local. This privacy/security disclosure is not captured in readOnlyHint or idempotentHint, providing valuable context for agents handling sensitive data. No contradiction with annotations.

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 concise and well-structured: a clear purpose statement, a topic list, a deferral note, and a behavioral guarantee. Every sentence adds value and the most important information is front-loaded. It avoids redundancy with the schema and annotations.

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 single-parameter tool with rich annotations and no output schema, the description provides complete guidance: it specifies the exact topics, notes the special handling for 'tone', and discloses the server's data-handling behavior. No significant gaps remain for an agent to effectively select and invoke this tool.

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 schema already covers the single 'topic' parameter with an enum and a description of the default behavior. The tool description enriches semantics by explaining specific topics: 'severity' is described as 'the risk-adjusted severity model — the spine', and 'brief' as 'one-page brief section guidance'. It also clarifies that 'tone' is handled by another tool, adding meaning beyond the schema. Not every enum value is elaborated, but enough context is provided to aid selection.

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 clearly states the tool's function: retrieving Lenny Zeltser's expert security assessment report writing guidelines. It explicitly lists the covered topics, which differentiates it from sibling tools like cti_get_guidelines or ir_get_guidelines. The specific mention of deferring the 'tone' topic to get_security_writing_guidelines also distinguishes this tool from that alternative.

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 provides clear context for when to use the tool (for assessment report guidelines) and explicitly states an alternative for the 'tone' topic: use get_security_writing_guidelines instead. It does not explicitly compare with all sibling guidelines tools, but the deferral rule provides a concrete when-not scenario, earning a 4.

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