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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered; the description adds genuinely useful behavior beyond that: the 60-second cache with a fresh bypass subject to rate limits, the minor-unit currency convention (13125 GBP = GBP 131.25), and venue-local times that carry a real UTC offset and are safe for time math. The one gap is that it doesn't describe failure modes or what happens when a product has no availability, and it sits slightly awkwardly against idempotentHint=false while advertising a reusable idempotency_key.

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 tool's purpose and trigger are front-loaded in the first sentence, and the following sentences pack in high-value caveats about currency units and timezone handling without padding. It is dense but every clause carries information an agent needs, though the return-value detail is somewhat redundant given an output schema exists.

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 100% schema coverage, an output schema, and full annotations, the description supplies the one thing structured fields can't: when to reach for this live-check tool and how to interpret its units and timestamps. An agent could invoke it correctly from this text alone; only sibling disambiguation is missing.

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 the schema already documents all ten parameters and the baseline is 3. The description reinforces the product_id vs slug+city_slug choice but adds no syntax or format detail beyond the schema, and its richer currency/timezone notes describe return values rather than 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 names a specific verb and resource: checking live bookable dates, times, prices, and remaining spaces for one selected product, and explicitly frames itself as "the live supplier-check tool." That is clear on its own, but it never distinguishes itself from the sibling check_availability, whose name suggests the same operation, leaving the agent to guess which one to pick.

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 gives a concrete trigger condition ("when the user is ready to check live bookable dates...") and tells the agent which identifier to pass (product_id from search, or slug plus city_slug). However, it offers no when-not guidance, no prerequisites, and no routing against the near-identical check_availability sibling.

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