connects_rooms

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Cannot book or cancel rooms' adds a meaningful behavioral boundary beyond the annotations. It makes clear this is a read-only informational tool and not a mutation endpoint. No annotation contradiction exists.

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 a single concise sentence with no filler. It front-loads the core capabilities and immediately adds a clarifying limitation. Every word contributes value.

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 8 parameters, zero parameter descriptions, and no explanation of how filters combine or what values capacity/duration/time_of_day accept, the description is not sufficient for reliable invocation. The output schema may help with return values, but input construction remains underspecified. The tool definition is too thin relative to its complexity.

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 has 0% description coverage for its 8 parameters, so the tool description must compensate, but it only hints at the 'view' parameter by listing availability, filters, details, and reservations. The parameters day, capacity, duration, time_of_day, room_id, limit, and offset remain unexplained. This is a significant gap for an agent trying to invoke the tool with correct filter semantics.

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 identifies the resource (rooms) and the scope: availability, filters, details, and existing reservations. It also differentiates itself from booking/cancellation operations and from sibling tools like connects_events or connects_schedule by focusing on room-specific data. It lacks an explicit verb like 'query' or 'list', but the meaning is unambiguous.

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 should be used for room availability, details, filters, or reservations, and explicitly states it cannot book or cancel rooms. However, it does not name alternative tools or provide explicit when-to-use/when-not-to-use guidance beyond the booking/cancellation exclusion. The usage context is mostly inferred.

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