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

Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds meaningful context beyond these: it automatically fetches current reservation info (so charge_id is unnecessary), and most importantly, the swap does not execute with this tool alone — confirm_action must be called. This two-phase behavior is foundational for the agent to invoke the tool correctly and is not encoded in the annotations.

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?

Five short Korean sentences, each earning its place: core action, auto-lookup behavior, confirm_action requirement, alternative routing, and session requirement. The purpose is front-loaded in the first sentence with no redundant filler, though the session note slightly overlaps with the schema's mcp_session_id documentation.

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 moderate-complexity tool with no output schema, the description covers the essential workflow constraints: the two-phase execution, the alternative tool, and the session/login requirement. However, it omits what the tool returns — an agent needs to know the output shape to pass to confirm_action — and it doesn't clarify whether the current seat return is provisional until confirmation, which is material for a state-changing operation.

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 fully documents both new_seat_id (including where to find it) and mcp_session_id (including fallback behavior), setting the baseline at 3. The description adds only marginal parameter context: the note that charge_id is not needed clarifies the parameter surface, and the 'mcp_session_id 필요(LIBRARY 로그인)' note reinforces the session requirement, but neither adds substantial meaning beyond the schema.

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 states a specific verb+resource: it automatically returns the current reserved library seat and changes to a new one. It clearly distinguishes itself from siblings, explicitly saying to use prepare_reserve_library_seat when there is no current reservation, which differentiates it from the related prepare_* tools without requiring schema inspection.

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 gives an explicit when-not condition and names the alternative: '현재 예약이 없으면 prepare_reserve_library_seat를 사용하세요.' It also discloses the critical two-phase protocol (must call confirm_action for final execution) and the LIBRARY login requirement. However, it doesn't explicitly state the positive trigger condition (e.g., verify a current reservation exists first) or suggest checking get_my_library_seat to confirm reservation status before use.

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