Read open call slots

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower. The description still adds real value by disclosing required scopes (bookings:read, luca:read), data sensitivity (redacted), and the workspace override mechanism. The 'does not require idempotency' line is slightly redundant against idempotentHint=true but describes idempotency keys, not effect semantics, so it is not a genuine contradiction.

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?

The intent sentence is front-loaded and the metadata lines (operation, scopes, workspace override) are compact and scannable. No filler sentences, though the 'Does not require idempotency' line is marginally redundant with the annotations.

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, return values need not be described, and the annotations already cover the safety profile. The description completes the picture with auth scopes and workspace-override guidance, leaving only the sibling-differentiation gap.

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 67%, so the schema carries most parameter documentation. The description only clarifies the workspaceId/workspaceSlug override behavior and says nothing about the nested query filters (start, end, leadId, provider, timezone, calendarId, eventTypeId), leaving a gap the schema alone must fill.

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 open slots the coach can actually be booked into') and even the intent behind it. However, it does not distinguish itself from sibling tools like luca_bookings_managed_availability or luca_bookings_types_schedule, which an agent could plausibly confuse with this one.

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?

'Check this before booking' gives one implied when-to-use condition, which is helpful context. But it names no alternatives and no exclusions, so an agent cannot tell from the description alone when to prefer this over luca_bookings_managed_availability.

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