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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral context that the shop's calendar is authoritative and should be read before booking_intent, but it does not go deeper into return behavior, error conditions, or rate limits. With annotations carrying the safety burden, a 3 is appropriate.

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 compact: two sentences, no filler, and the core purpose is front-loaded. The phrasing 'What a shop sells TIME for' is stylized but still efficient. It earns its place by also including the critical relationship to booking_intent without needing extra explanation.

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 read-only lookup tool with a rich input schema and safety annotations, the description covers the essential points: what is returned (services, prices, deposits, openings), the role of the calendar, and the relationship to booking_intent. There is no output schema, so an agent would benefit from slightly more explicit return formatting, but the current description plus schema is sufficient for correct invocation.

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 three parameters thoroughly, including the optional day and service semantics. The description adds little beyond saying that openings come back for a given service and day, which loosely aligns with the service and day parameters. Since the schema does the heavy lifting, the baseline 3 is correct.

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 conveys that the tool returns a shop's services with real prices and deposits, plus availability openings for a service on a given day. It also distinguishes itself from booking_intent by establishing the shop's calendar as the authority. However, it relies on noun phrases ('What a shop sells TIME for') rather than an explicit verb like 'get' or 'list', so it is slightly less direct than ideal.

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 'Read this before booking_intent', giving clear sequencing guidance and naming the primary sibling alternative. It also implies that this tool should be used to discover what actually exists before attempting a booking. It does not describe broader when-not-to-use scenarios, but the context is adequate for an agent to select it.

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