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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful context beyond this: the catalog is a static snapshot (not real-time), the data source is screenshots, and no authentication is required — information that shapes an agent's expectations about freshness and invocation prerequisites. This exceeds the minimal safety-only coverage.

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 four-sentence Korean description is tightly written and front-loaded: the first sentence states the core purpose, the second sets exclusions, and the third gives parameter guidance. The only waste is '인증 불필요' (no auth required) repeated at the end after '인증도 필요하지 않습니다' in sentence two — a minor redundancy that prevents a perfect score.

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 catalog tool with zero required parameters, fully documented schema, and comprehensive annotations, the description is nearly complete. It covers what the tool returns, what it excludes, authentication requirements, and one parameter's usage scenario. The only minor gap is that the default return format is not precisely described — 'built from screenshots' implies image or structured layout data, but the exact representation is left to inference.

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 (room_code, floor_code, include_layout) with examples like 'open-reading-2f'. The description adds modest value by hinting at the purpose of include_layout for text-based floor layouts, but it adds nothing beyond the schema for room_code or floor_code. This matches the baseline-3 expectation for fully-covered schemas.

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 and resource: it returns a static catalog of Soongsil University library reading room/seat layout maps built from screenshots. It explicitly distinguishes itself from real-time sibling tools by stating '실시간 좌석 현황은 포함하지 않으며' (does not include real-time seat status), which separates it from get_library_seat_status, get_library_available_seats, and get_room_available_seats.

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 clear context on when this tool is appropriate: when a static layout catalog is needed rather than real-time seat data, and notes that no authentication is required. It also instructs when to use the include_layout parameter ('LLM이 간단한 텍스트 기반 층별 배치도가 필요할 때'). However, it never names a specific alternative tool to use when real-time status IS needed, stopping short of the explicit routing the top tier demands.

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