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

Annotations already establish read-only, idempotent, non-destructive, non-open-world, so the safety bar is met. The description goes further with genuinely non-obvious behavior: venueClock is returned, later dates resolve against venueClock.today rather than the caller's today, and times are deliberately text with no timezone identifier to prevent hour-offset bookings. It stops short of describing result shape or error cases, but the time-resolution warning is high-value context.

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?

Three dense sentences, correctly ordered: what it returns, why to call it first, then the timezone trap that would otherwise cause real booking errors. No filler and the most consequential warning is kept adjacent to the return-value discussion.

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?

There is no output schema, so the description must carry the return contract, and it does: venueClock is named and its resolution semantics are explained. Combined with 100% parameter coverage in the schema, an agent has everything needed to call and interpret this tool.

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% and the schema already explains the slug format, the /book/<slug> and <slug>.gaplessly.com derivations, and the 'not the business name' warning. The description adds only a light cross-reference (the slug comes from get_venue, a service id feeds appointment searches), so 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?

Specific verb+resource with scope spelled out: reads a venue's public booking profile and enumerates what that contains (identity, location, bookable services, local clock). It also positions itself relative to siblings by declaring itself the entry point that supplies the slug the others need.

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?

Explicit ordering guidance: 'Call this first: the other tools need this venue's slug, and appointment searches need a service id from here.' It states when to use it and why, tying it directly to find_appointment_times / start_appointment_booking rather than leaving the agent to infer a sequence.

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