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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behaviour: counts are exact only for the units swept, the response self-reports when it hit its cap instead of implying full coverage, and an empty findings list explicitly does not mean compliance. That cap/empty-result semantics is exactly the kind of context structured fields cannot carry.

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?

Four sentences, front-loaded with the core action and output shape, with the caveat about empty findings placed last where it matters most. The four example queries are slightly repetitive but each maps to a distinct use case, so little is wasted.

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?

With no output schema, the description carries the return-value burden itself and does so: findings grouped by failing check, affected unit counts, example units to open, and a truncation flag. Combined with the annotations, an agent has everything needed to call it and interpret the result.

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%, so the baseline is 3, but the description adds real meaning to `limit` by framing it as a sweep cap whose truncation is signalled in the response, and it reinforces the pack-omission behaviour as 'sweep under every pack'. It does not explain the status enum values, but the schema already lists them.

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 (sweep) and resource (this organisation's units) and precisely what is reported: which regulatory checks fail, how many units each affects, and example units to open. The example queries ('broken custody chain', 'what will not pass on 18 February') sharpen the scope considerably, though no sibling such as dpp_readiness or list_findings is named to draw an explicit boundary.

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?

Usage is conveyed through four concrete user questions that map cleanly onto the tool, giving an agent a clear sense of when this is the right call. It stops short of naming alternatives (dpp_readiness, list_findings, trace_unit) or stating when not to use it, so it is context without exclusions.

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