실시간 도시데이터

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

Annotations already declare readOnlyHint: true, so the description need not repeat read-only status. It adds valuable behavioral context by explaining that output size can be reduced with the categories parameter and by listing the 13 data domains. It does not discuss rate limits, caching, or error behavior, but for a read-only data retrieval, the provided context is sufficient.

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 two well-structured sentences: the first states the core purpose and scope, the second gives a practical usage tip. Every word adds value, with no repetition of schema information or fluff.

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?

Given the tool's complexity (13 data types) and lack of output schema, the description provides a comprehensive list of available data categories and explains the output reduction behavior. It could additionally note the exact return format or behavior for invalid places, but the schema covers place matching details, so overall completeness is strong.

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 already provides 100% coverage with descriptions for both place (including partial matching and examples) and categories (enum values). The description adds semantic meaning by translating the enum names into human-readable Korean categories (e.g., population → 인구 혼잡도), which helps an agent understand what each parameter controls.

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 states the action ('retrieves real-time city data for one major place in Seoul') and enumerates the specific data types provided. It distinguishes itself from sibling tools (list_places, get_congestion_ranking) by focusing on detailed data for a single location, not listing or ranking.

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 usage for querying detailed data of a single place and offers guidance on filtering with categories, but it does not explicitly state when to use this tool over alternatives. It lacks clear exclusions or direct references to sibling tools, such as 'for rankings, use get_congestion_ranking'.

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