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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds valuable behavioral details: pagination ('follow next_offset until null'), a currency check ('fingerprint and dates'), and a privacy rule ('never send their text to this server'). These go beyond annotations and clarify how the tool behaves.

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 dense but every sentence carries information: purpose, content specifics, pagination, related tools, currency check, privacy, and id-only rule. It's front-loaded with the core purpose. Slightly long but not bloated; it earns its length by covering multiple distinct behaviors.

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 tool with no output schema and moderate complexity (different playbook types, pagination, privacy), the description covers all essential aspects: what the kit is, how to use related tools, pagination behavior, currency check, and privacy constraints. It doesn't enumerate response fields, but that's not required given the 'rule kit' concept and the mention of fingerprint/dates.

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 100% (both id and offset have descriptions). The description reinforces id's allowed values implicitly via 'Playbook tools take only ids' and clarifies offset's role with 'follow next_offset until null', which adds meaning beyond the schema's bare description. The added pagination semantics justify a score above the baseline 3.

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 clear verb+resource ('Get a playbook's rule kit') and immediately specifies what the kit contains for different playbook types (FNMA AI lender letter vs FHA/VA/USDA QC). It also names sibling tools (get_reg, get_obligation) as alternatives, making it easy to distinguish this tool's scope.

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 states that for FHA/VA/USDA QC, one should 'read with get_reg / get_obligation', which implies when this tool alone is insufficient. The rule 'Playbook tools take only ids' sets a constraint. However, it doesn't explicitly say when NOT to use this tool or provide a decision tree, so a small gap remains.

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