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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: retired events and zero rows are excluded, ungrouped nonzero rows remain visible, mirrored register observations appear once per event, the same movement surfaces under both endpoint accounts with opposite signs, and it is not metered. This is exactly the extra context annotations 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?

Dense but front-loaded: identity of the tool, then account selection, then data-shape caveats, then filtering/paging, then safety. Most sentences carry real information, though the signed-amount and mirroring sentences could be tightened to reduce cognitive load.

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 an output schema present, the description needn't document return shapes, and it correctly focuses on the non-obvious semantics (sign convention, exclusions, per-event mirroring). Minor gap: it doesn't state what happens when the account selector matches zero or multiple accounts, though the schema partly implies exactly-one.

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 description coverage is 100%, so the schema already documents every parameter including the mutually exclusive account selectors and the inclusive date semantics. The description restates the one-of rule and the paging model but adds no syntax or format detail the schema lacks. Baseline 3 is appropriate.

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?

Opens with a specific verb and resource ('Lists one account's side of each movement it touches') and explicitly negates what it is not ('not register rows and not journal entries'), which separates it from list_events and list_workspace_accounts. The domain jargon 'movement sides' is unusual and only partially self-defining, so the purpose is clear but not instantly legible.

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?

Gives operational conditions: exactly one of workspace_account_id or workspace_account_identifier, inclusive date_from/date_to filtering, and limit/cursor paging. It adds 'Read-only and not metered' as a usage signal. However, it never names a sibling alternative (e.g. list_events or list_workspace_accounts) or states when an agent should prefer one of those instead.

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