Server Quality Checklist

Tool Scores

• analyze_parking_congestionB
  3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It does add one genuinely useful behavioral trait: it instructs the agent to surface availability_summary, distance_summary, and congestion_score in the reply, which tells the caller how to handle the output. However, it does not disclose whether the operation is read-only, how the scores are derived, what 'congested or high wait probability' means operationally, or what happens when no lots match the criteria.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The first sentence front-loads the core purpose and filtering criterion; the second sentence earns its place by telling the agent which result fields to include in the user-facing answer. Every clause carries information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a 7-parameter tool with 0% schema coverage, no output schema, and no annotations, yet the description is only two sentences. It does not explain how latitude/longitude, destination, radius_m, or target_hour shape the analysis, nor what ranges or defaults govern them, nor how to interpret the three result fields. For a tool with this complexity and zero structured support, the description leaves substantial gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for all seven parameters, but it only implicitly references day_type through '평일/주말' (weekday/weekend). The remaining parameters (limit, latitude, longitude, radius_m, destination, target_hour) are entirely unexplained in both schema and description. The minimal partial coverage of day_type is the only semantic contribution.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action (analyze) applied to a concrete resource (parking lots with congestion/high waiting probability) with a clear criterion (weekday/weekend). Naming the three output fields (availability_summary, distance_summary, congestion_score) sharpens what the tool produces. It is distinguishable from sibling tools like search_destination and find_parking_lots, though its boundary with estimate_wait_time and recommend_parking is not explicitly drawn.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is given, and no alternatives are mentioned despite several overlapping siblings (recommend_parking, estimate_wait_time, find_parking_lots). The intended usage is only implied by the description's wording, leaving the agent to infer when congestion analysis is the right choice versus a single-lot wait estimate or a generic recommendation.

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

• find_parking_lotsB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does add some behavioral context: it reveals that the search can key off either a destination name or coordinates, and it specifies that answers must include availability_summary, distance_summary, and a KakaoMap link. However, it does not disclose data source, freshness, no-result behavior, or side effects — acceptable for a read-only lookup but not a thorough disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with zero filler; the core purpose is front-loaded and the answer-format instruction earns its place given there is no output schema to convey what the response should contain.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  A 7-parameter tool with 0 required params, no annotations, and no output schema needs far more guidance than this provides. The description covers the coordinate/name search basis and response components but omits the meaning of four parameters, when to prefer siblings, and what a result set looks like.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, but it only clarifies the destination and latitude/longitude parameters. address, radius_m, realtime_status, and parking_lot_code are left unexplained — including the default of radius_m (700) and the meaning of the realtime_status enum 0–3 — so an agent cannot confidently construct correct calls for all inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('finds nearby parking lots') and identifies the search basis (destination name or coordinates). This clearly separates it from get_parking_detail, estimate_wait_time, and analyze_parking_congestion, though it does not explicitly differentiate from the overlapping-sounding sibling recommend_parking.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus search_destination (for finding/validating a place) or recommend_parking (for choosing among lots). The response-format instruction ('show availability_summary, distance_summary, KakaoMap link') is about answer presentation, not tool selection, so an agent gets little help deciding between siblings.

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

• recommend_parkingB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description is the only source of behavioral disclosure. It usefully specifies that each recommendation must include availability_summary, distance_summary, expected wait time, and a KakaoMap link, but it does not mention data sources, freshness, real-time semantics, or that this is a read-only operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the purpose sentence comes first, followed by a concise output-format requirement. The example summaries are useful rather than redundant, though the response-formatting sentence could have been slightly tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has five parameters, no output schema, and no annotations, so the description alone must make the tool safely callable. It gives a good outline of the output but omits semantics for several inputs and fails to distinguish when to use this instead of find_parking_lots or estimate_wait_time.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the five parameters. It only maps the first sentence's criteria to possible priority choices and leaves radius_m, expected_parking_hours, and current_queue_count_by_lot unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: recommend parking lots around a destination using distance, wait time, fee, and beginner-friendliness criteria. It uses a specific verb and resource, and the 'recommend' framing broadly separates it from sibling tools like find_parking_lots, though it does not explicitly name the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied from 'recommends parking lots around the destination' — an agent can infer it should be called when a user wants a parking recommendation. However, there are no explicit when/when-not conditions or references to sibling tools such as find_parking_lots, estimate_wait_time, or analyze_parking_congestion.

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

• estimate_wait_timeB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions the inputs to the calculation but does not state whether the operation is read-only, what the return value looks like, how optional parameters affect the estimate, or how missing data is handled.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single efficient sentence with no filler. It is front-loaded with the purpose and calculation inputs. Slightly more structure or explanation could improve it, but it is appropriately concise for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no annotations, no output schema, and 0% parameter description coverage, the description is too sparse for an agent to call the tool correctly with confidence. It omits the meaning of optional parameters, the output format, and any prerequisites or limitations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate by explaining parameters. It references '실시간 가능대수' and '과거 출차 통계' as data sources, but it does not map these to parking_lot_id, target_datetime, or current_queue_count, nor does it clarify their roles in the calculation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb, '계산합니다' (calculates), with a clear resource, '예상 대기시간' (estimated waiting time), and even states the data basis: real-time available spaces and past departure statistics. This clearly distinguishes it from sibling tools that search, find, get, recommend, or analyze congestion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when an estimate of waiting time is needed, but it does not explicitly state when to prefer this tool over alternatives like analyze_parking_congestion. There is no exclusions or alternative guidance, so the usage context is only implicit.

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

• get_parking_detailA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. '조회합니다' clearly conveys a read-only query and the description enumerates the returned information (capacity, hours, fees). However, it does not disclose behavior for invalid IDs, data freshness, authentication needs, or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact sentence that front-loads the resource and then lists the specific data categories returned. Every word adds value and there is no redundant or vague filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter detail lookup, the description provides the main return categories and is mostly adequate. However, with no output schema, no annotations, and no parameter guidance, it leaves gaps around usage context, invalid ID behavior, and whether the data is real-time.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not mention parking_lot_id at all. The parameter name is self-explanatory, but the description does not compensate for the missing schema description by explaining where the ID comes from or how to use it, which is a clear gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The Korean description uses a specific verb '조회합니다' (retrieves) with a clear resource: detailed parking lot information including available capacity, operating hours, and fees. This clearly distinguishes it from sibling tools like find_parking_lots (discovery) or recommend_parking (recommendation), as it is explicitly a detail lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving details about a specific parking lot, but it never explicitly states when to use it versus alternatives. It does not mention that find_parking_lots should be used first to locate lots, nor does it state when not to use this tool.

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

• search_destinationA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It correctly communicates a read-like transformation, but does not mention how ambiguous or non-existent destinations are handled, whether partial names are accepted, or what the exact coordinate output format is. This is minimally transparent but not richly so.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single Korean sentence conveys the action, the input, and the output with no filler words. The core idea is front-loaded and immediately understandable, making it highly efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter geocoding tool, the essential happy-path context is present. However, since there is no output schema, the description should ideally state the coordinate format (e.g., lat/lng) and behavior for missing or ambiguous destinations. The lack of such details leaves a small but real completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only defines 'query' as a string with minLength 1, while the description clarifies that the query is the user-entered destination name. Since this is the only parameter, the description effectively provides the missing semantic meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action—converting a user-entered destination name into coordinates—which clearly distinguishes it from parking-focused siblings like find_parking_lots and recommend_parking. The verb '변환합니다' (converts) and resource '목적지명' (destination name) make 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: call this tool when a destination name needs to be geocoded. However, there is no explicit statement about when to avoid it, prerequisites, or how it fits into a workflow with the sibling parking tools. This is adequate but relies on inference.

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