Public parking availability

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by noting the real-time nature and the limitation to 122 linked parking lots ('실시간 연계 122곳 한정'). It also clarifies that keyword matching applies to lot name and address. This is strong for a read-only tool, though it does not describe return format or error behavior.

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 compact and front-loaded: a clear English sentence, a Korean restatement with a key limitation, and a concrete usage example. Every sentence contributes value, with no redundancy or filler.

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 two-parameter read tool with no output schema, the description covers the essential aspects: purpose, filtering behavior, limitation, and usage context. It does not explicitly describe the return format, but the tool name and phrasing 'available spaces' make this fairly clear. Minor gaps remain around result ordering or no-match behavior, but overall it is sufficient.

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 baseline is 3. The description adds extra meaning for the query parameter by specifying that it matches against 'lot name and address,' which is not in the schema description. This additional semantic nuance justifies a score above baseline.

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 tool's function: 'Get real-time available spaces in Seoul public parking lots, filtered by place/district keyword matched against lot name and address.' It uses a specific verb and resource, and the mention of keyword-based filtering distinguishes it from sibling tools like get_bike_stations or search_place.

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 includes an explicit usage example: '"종로 주차 자리 있어?" 류 질문에 사용.' This provides clear context for when to apply the tool, but it does not mention alternatives or explicitly state when not to use it, so it falls short of a 5.

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