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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, yet the description adds substantial behavior the annotations cannot: watch-window completeness guarantees, the meaning of an empty list, the three independent dispute signals behind `disputed`/`dispute_reason`, the `applies_from: unknown` semantics, the metadata_only_units/instruction_only_units naming, and an explicit legal-advice disclaimer.

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?

Purpose is correctly front-loaded in the first clause, and most sentences carry distinct semantics about edge cases. However, the closing disclaimer is stated three times over ('no lawyer's review', 'engineering assistance only', 'not legal advice'), and the single dense paragraph of caveats could be trimmed without losing information.

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?

An output schema exists, so return values need not be explained, yet the description goes further and defines the semantics of disputed, dispute_reason, applies_from and the *_only_units fields. Combined with completeness guarantees across the watch window, the agent has nearly everything needed; only the boundary against sibling list tools is unstated.

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. The description adds real meaning beyond the schema's terse 'Part of a key, title or alias' and 'A catalogue sector' by specifying that `query` matches case-insensitively and that `domain` matches the catalogue's sector specifically.

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 states a specific verb and resource ('List the acts the record holds') and enumerates what each entry carries (label, aliases, sector, newest version, updated_on, counts). It is far from a tautology. It does not, however, explicitly distinguish this tool from close siblings such as list_disputed or changes_since, so the agent must infer the 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?

There is no statement of when to pick this tool over the alternatives in the sibling set. The description explains what `query` and `domain` do and what an empty list means, but never names a competing tool or a selecting condition. Usage has to be inferred from the scope phrase 'the record holds'.

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