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

Since no annotations are provided, the description fully carries the burden. It discloses the pending_confirmation status, the return of confirmationToken and bookingToken for lifecycle management, rate limiting, and auditing with semantic decision codes. This far exceeds basic schema information.

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 dense but well-organized, using numbered requirements and a clear flow sequence. Every sentence contributes useful information with no redundancy or filler.

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 the complex nested schema and absence of an output schema, the description provides the necessary lifecycle context, return tokens, prerequisites, and end-to-end flow. This is sufficient for an agent to correctly select and invoke the 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?

The description adds important semantics beyond the schema, such as requiring 'fullName plus at least email or phone', submission channel and agent assistance context, and authorization.humanIntentConfirmed=true. However, it does not clarify startAt format or idempotencyKey behavior, so it is not fully comprehensive for all 8 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 'Create a public booking request', specifying the verb and resource. It further distinguishes itself from sibling tools like booking_create by emphasizing the 'public' nature and lack of API key requirement.

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 provides explicit prerequisites and an explicit flow: 'Use public_service_list → public_availability_get_slots → public_booking_create → public_booking_confirm as the complete public booking flow.' It also notes when no API key is required and describes rate limiting, giving clear situational context.

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