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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses a useful behavior: data may be empty outside bus operating hours. However, it does not describe response contents, error cases, or latency behavior, so some transparency gaps remain.

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?

Two short sentences with no filler. The core operation is front-loaded, followed by the prerequisite and the key availability caveat, so every sentence earns its place.

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 tool with two parameters, the description plus schema covers how to obtain bsId, optional routeNo filtering, and the empty-data possibility. Without an output schema, a brief note on returned fields would make it fully complete, but nothing essential is missing for invoking the tool correctly.

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 coverage is 100%, and the schema already describes bsId as a search_bus_stop result and routeNo as an optional filter. The main description adds no meaning beyond that, so the baseline score of 3 is appropriate rather than higher.

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 operation and resource: '정류소 ID(bsId) 기준 실시간 도착예정 버스 목록을 가져온다' — get the real-time expected-arrival bus list for a stop ID. This cleanly differentiates it from sibling tools like search_bus_stop (stop lookup) and get_bus_location (vehicle location) without needing to inspect schemas.

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?

It explicitly instructs callers to first find bsId via search_bus_stop and warns that data may be absent outside bus operating hours. It does not explicitly name sibling alternatives or state when not to use the tool, so it stops just short of full routing guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states it fetches data but does not disclose any caveats such as empty results, potential errors, or that it is a read-only operation. The description is minimal and does not add context beyond the basic action.

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 short sentences, with the primary action front-loaded and the prerequisite clearly stated. No wasted 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?

For a simple tool with one parameter and no output schema, the description provides the essential usage steps. It could benefit from noting the return format (e.g., a list of coordinates) but is adequate for its complexity.

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 input schema already describes the only parameter (routeId) with the same guidance as the description, so the description adds little value. Schema coverage is 100%, warranting the baseline score of 3.

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 action (fetch real-time locations of buses) with a clear resource (route identified by routeId). It distinguishes itself from siblings like search_bus_route and get_bus_arrivals by focusing on current positions, and it explicitly ties to search_bus_route for the prerequisite.

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?

Provides clear usage context by specifying that routeId must be obtained from search_bus_route first, which is an important prerequisite. However, it does not explicitly state when to use this over other location-related tools like get_bus_arrivals, though the purpose is clear enough.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds a key trait: parking lots without real-time info (hasRealtime=true) return only static data, and it itemizes returned content (details, real-time status, remaining spaces). It does not discuss response shape or errors, but the core behavior is well disclosed.

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?

Three dense sentences: the first states the resource and result set, the second names the filters, and the third clarifies a conditional behavior. No redundant phrases 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?

Given no output schema and no annotations, the description is reasonably complete for invocation: it names the data source, the returned fields, the optional filters, and the real-time vs static fallback. It does not specify pagination or result ordering, but the optional limit parameter and filter semantics are sufficiently covered.

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 repeats that gu and name act as narrowing filters and adds no syntax, format, or default details beyond the schema, which already documents example values and the limit default.

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?

States a specific operation and resource: it retrieves Daegu parking-lot details (location/fees) plus real-time congestion and remaining spaces from the integrated parking information system. This clearly distinguishes it from sibling tools, which target bus stops, routes, arrivals, locations, and road traffic.

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: use it for parking-lot lookups in Daegu, optionally filtered by district name or parking-lot keyword. It does not explicitly state exclusions or alternative conditions, though the domain separation from bus/road siblings makes the intended use obvious.

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

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

With no annotations, the description carries the behavioral burden and does it well: it discloses partial keyword matching, the lack of a server-side location filter, client-side filtering, and the limitation that rare place names may not be found. It is transparent about a real failure mode.

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?

Two dense sentences that front-load the tool's purpose and then add the key caveat. No filler or repeated schema text.

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 fetch tool with two optional parameters and no output schema, the description covers purpose, search behavior, examples, and an important limitation. An agent has enough to invoke it correctly.

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 coverage is 100%, so the baseline is 3. The description adds value by explaining keyword as a partial search over road/segment/point names and giving concrete examples, while the schema already documents limit and the default behavior when keyword is absent.

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 names a specific action ('가져온다') and resource ('표준노드링크 기준 도로 구간의 실시간 속도/소통상황'), including the three traffic states. This clearly separates it from the bus- and parking-related siblings.

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 title and description make clear it is for Daegu road-segment traffic, so an agent can infer when to choose it. It does not explicitly name alternatives or state when not to use it, so it stops 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.

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

No annotations are provided, so the description carries the full disclosure burden. It conveys the core behavior (read-only route lookup yielding a routeId) and its role as a prerequisite. However, it omits edge-case behavior: what happens with ambiguous matches, no matches, or partial input, and the response format. For a search tool with zero annotation coverage this is a moderate gap.

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?

Two tightly packed sentences in Korean with zero filler. The core purpose is front-loaded, followed immediately by the usage pattern and concrete examples. Every sentence earns its place.

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?

Complete for a simple 2-parameter lookup tool: purpose, prerequisite workflow, and input examples are all covered, and the schema documents both parameters. The only omissions are return format and ambiguous-match handling, which are minor given no output schema exists and the operation is straightforward.

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% - both query and limit have inline descriptions in the schema. The description reinforces the query semantics with the same examples ('급행1', '805') already in the schema, adding the workflow context that query maps to routeId. It doesn't meaningfully expand on the limit parameter beyond the schema's default-5 note, so 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 states a specific verb+resource ('버스 번호로 노선 ID(routeId)를 찾는다' - finds routeId by bus number) and gives concrete input examples ('급행1', '805'). It distinguishes itself from siblings like search_bus_stop (stop search) and get_bus_arrivals (arrivals) by clarifying it's the routeId lookup step, so an agent can tell them apart.

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 explicitly states when to use it: 'get_bus_location을 쓰기 전에 먼저 호출해서 routeId를 확보한다' (call before get_bus_location to secure routeId). This establishes a clear prerequisite workflow. It doesn't explicitly name alternatives or state when-not-to-use, so it stops 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.

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (search by name, return bsId) but does not mention potential multiple matches, ordering, or error behavior. It is adequate but not rich.

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 sentences that front-load the purpose and then the usage workflow. Every word earns its place with no redundancy.

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 search tool with two parameters and no output schema, the description covers the essential purpose, the workflow (before get_bus_arrivals), and an example. It does not elaborate on limit behavior or response format, but these are minor gaps.

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 coverage is 100%, so both parameters are already described. The description adds only an example keyword, which mirrors the schema. No additional semantic meaning is provided 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 (찾는다) and resource (정류소 ID(bsId)) by stop name, and explicitly differentiates from sibling tools by naming get_bus_arrivals as the downstream consumer. This makes the tool's purpose unambiguous.

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 explicitly instructs to call this before get_bus_arrivals to obtain bsId, giving a clear usage context. It does not explicitly state when not to use it versus search_bus_route, but the stop-vs-route distinction is implied.

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