upc_library_seats

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. Beyond that the description adds nothing — it does not mention that results are paginated (limit defaults to 300, max 1000) nor that a large room silently truncates without offset paging, which is the main behavioral risk here.

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?

A single eleven-word sentence with no filler, and the scope constraint (one room) is front-loaded. It is efficient but so terse that it omits information rather than being trim of redundancy.

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 6-parameter, paginated, live-data read with no output schema, the description should say roughly what a seat entry contains (seat id, status FREE/YESSELECT/localOnly) and warn about page-size truncation. Neither is present, so an agent must open both schema and sibling tools to call it 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?

Schema description coverage is 83%, so the schema already explains room_id, date format, limit range, offset, and the only_available filter. The description contributes only "one room" and "real date," which adds essentially no meaning beyond the structured fields; baseline 3 applies.

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 pairs a specific verb ("Read") with a scoped resource ("one room's seat layout and status"), so an agent knows it returns per-room seat data rather than a room list. It stops short of naming a sibling like upc_library_rooms or upc_library_times to disambiguate the two-step flow.

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?

"For a real date" is the only usage constraint and it is ambiguous — it likely means a valid calendar date rather than today/placeholder, but that is inference. There is no statement of when to call this instead of upc_library_rooms or how it relates to upc_library_book/reservations in a workflow.

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