booking

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

With no annotations, the description carries the full burden. It discloses critical behavior: slots are not held and are only reserved after payment at booking_url, clarifying the non-reserving nature. It omits auth/rate limits, but the key state-related behavior is well covered.

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 sentences pack all essential information without redundancy. Every clause adds value, making it highly efficient and well-structured.

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?

Given no output schema, the description adequately explains the tool's purpose and behavior. It could detail the response format (e.g., per-slot fields), but the core usage and constraints are sufficiently complete for a tool with simple inputs and clear intent.

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 covers all parameters, so baseline is 3. The description adds meaningful context: service_id is from list_services, and date_from defaults to today while date range is capped at 62 days, going beyond the schema descriptions.

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 clearly states the tool lists live open appointment slots for a given service id, with an optional date range. It distinguishes itself from siblings like list_services and get_booking_link by focusing on availability and including the booking_url context.

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 explicitly instructs that service_id comes from list_services and sets date range defaults/maximums, implying a prerequisite and constraints. It lacks explicit 'when not to use' or alternative comparisons, but the context is clear enough for correct selection.

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

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

No annotations are provided, so the description must disclose behavior. It does warn that payment can never go through this API, which is a crucial safety constraint. However, it does not clarify the return format (e.g., a URL), whether it is a read-only operation, or any authentication requirements.

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 description is two sentences and very concise. The first sentence states the core purpose, and the second adds an optional parameter and an important safety warning, with no wasted words.

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 simple tool with one optional parameter and no output schema, the description covers the essential purpose and a critical limitation. It could be more explicit about the return value (a link) but overall provides enough context for an agent to select and invoke the tool correctly.

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?

The schema already documents service_id with a helpful description referencing list_services. The description repeats 'Optionally pass a service_id' but adds no new meaning beyond the schema, which has 100% coverage.

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 identifies the tool as providing the page where customers complete an Opus Lumiere booking, which clearly differentiates it from sibling tools like check_availability and list_services. However, it lacks an explicit verb like 'returns' or 'gets', slightly reducing precision.

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 implies this tool is for retrieving a booking link but does not explicitly state when to use it versus checking availability or listing services. The only guideline is the caution that payment cannot travel through this API, which is an exclusion rather than a positive usage context.

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

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

Since there are no annotations, the description carries the full burden. It discloses the timezone (Europe/London) and the fact that sessions are by appointment, which is non-obvious and important for interpretation. It does not mention side effects or auth, but for a simple lookup tool, this is sufficient.

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 concise sentences with no filler. The main information is front-loaded, and the second sentence adds a crucial caveat.

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 parameterless tool with no output schema, the description fully covers the essential information: what is returned (opening hours by weekday), timezone, and the appointment caveat. It also links to the relevant sibling tool, making it comprehensive in context.

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?

There are zero parameters, so the baseline is 4. The description adds relevant output context (timezone, by-weekday) without needing to explain parameters.

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 clearly states the tool provides studio opening hours by weekday, with a specific timezone. It distinguishes itself from sibling tools like check_availability (which confirms slots) and get_booking_link.

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 explicitly tells the agent to use check_availability to confirm a real slot, implying this tool is for hours only. This provides clear guidance on when to use this tool versus an alternative.

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

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

No annotations are provided, so the description carries the full burden. It explicitly labels the operation as 'Read-only' and reveals that the result includes a booking_url, providing useful behavioral context beyond the structured schema.

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 description is two sentences, with the first sentence directly stating the purpose and the second adding critical read-only and booking context. Every word earns its place, and it is front-loaded for quick understanding.

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 zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it returns (services with prices, deposits, durations, category, and a booking_url), and its read-only nature. No significant gaps exist.

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?

The input schema has zero parameters, so the baseline is 4. The description adds no parameter details because none are needed; it focuses on the output and usage, which 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?

The description clearly states the tool lists services with specific attributes (prices in GBP, deposits, durations, category) for a named studio. This distinguishes it from siblings like check_availability or get_booking_link, which serve different purposes.

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 explicitly says booking and secure payment are completed on the website, signaling this tool is only for listing services and not for booking. While it doesn't explicitly name alternative tools, the context plus sibling list makes the usage boundary clear.

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