Ttareungi (Seoul bike) station availability

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

The description adds behavioral details such as 'real-time available bike counts' and 'location-based works via name keyword matching.' However, it does not clarify how lat/lng and radiusM interact, what happens when both query and coordinates are provided, or what the response structure is. Given no annotations, more disclosure is needed.

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 relatively concise, using two sentences. There is some bilingual redundancy, but the Korean note adds a behavioral clarification. It is front-loaded with the main purpose and does not waste words.

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?

The description covers the primary purpose and real-time counts, but it does not explain the response format, default behaviors, or parameter interactions. Since there is no output schema, the description should better describe what the returned data contains. The gap is moderate but notable.

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 covers all 5 parameters with descriptions (100% coverage), so the description does not need to repeat them. It adds a query example ('강남역') and clarifies that query is a name keyword, but this is marginal beyond the schema. Baseline 3 is appropriate.

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 'Find Seoul public bike stations by name keyword and/or coordinates, with real-time available bike counts.' This specifies the verb, resource, and outcome, and the focus on bike stations distinguishes it from sibling location tools.

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 bike station queries by stating its purpose, but it does not explicitly mention when to use this tool versus alternatives like search_place or get_city_snapshot. It provides context through 'real-time available bike counts' but lacks exclusions or explicit alternative guidance.

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