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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly focuses on what annotations cannot express: required role, plan gating (ENTERPRISE+), default/max limit, and the caveat that client attribution columns are null on pre-backfill history. It does not explain pagination behavior (offset semantics, total counts), which is the only notable gap.

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 and filters are front-loaded, and each sentence carries substantive information. The closing clientSurface/clientLabel paragraph is longer than the rest and drifts toward return-value documentation, but it conveys non-obvious domain nuance (distinct axis from actorType, deliberate non-backfill) that prevents misreads.

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 compensates by explaining the two client-attribution fields and their null semantics, and it discloses auth/plan requirements for an 8-parameter tool with zero required params. Missing pagination/total-count behavior keeps it short of fully complete.

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?

With 63% schema description coverage, the description names most parameters, but the semantics it gives for since/until, search, and limit largely restate what the schema already documents, and it omits offset as well as any meaning for action/userId/resource beyond their names. It adds marginal value over the structured fields rather than compensating for the coverage gap.

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 specific verb+resource ('List AuditLog rows for the caller's org') and immediately scopes it with the common filter set. It explicitly distinguishes itself from the sibling export_audit_log, so an agent can route between list and export without opening either schema.

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 preconditions (OWNER or ADMIN org role, auditLogs feature on ENTERPRISE+) and names the alternative with the condition that selects it: 'PREFER export_audit_log for bulk CSV/JSON export.' That is exactly the when-to-use / when-to-use-something-else guidance the dimension asks for.

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