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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful context beyond that: the shape of returned records (owner, activity, area, start/end, paid state, recurrence) and the fact that removed bookings can be surfaced via a filter. It does not discuss pagination behavior, which the schema partly covers.

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?

Two compact sentences plus the endpoint: the purpose and returned fields are front-loaded, then the filter surface, with no filler. Every clause carries content an agent can act on.

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 13-parameter, no-required-param list tool with no output schema, the description compensates by describing the returned record fields and the available filters. It is slightly thin on pagination/response shape, though the schema's limit/offset/next_offset descriptions partially cover that.

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 all 13 parameters are already documented in the schema; the description mostly restates the filter dimensions (member, activity, area, mode, recurring, paid/removed) without adding syntax or semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource ('List resource bookings') and immediately disambiguates what a booking is with '(courts, rooms, lanes)', distinguishing it from siblings like list_check_ins, list_access_logs, or list_events. It also enumerates the fields returned and pins the underlying endpoint (GET /booking), so an agent knows exactly what it is.

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?

The description says what can be filtered ('date range, member, activity, mode, area, recurring, paid or removed'), which implies the read/filter use case, but it never states when to reach for this tool versus list_check_ins or list_access_logs, nor any prerequisite. Usage is inferable but not explicit.

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