Server Quality Checklist

Tool Scores

• naver_directionsC
  2.9/5.0
  Behavior2/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 of behavioral disclosure. It states the tool 'provides route-finding information,' which implies a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or what the output format looks like (e.g., JSON with distance, duration, steps). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

  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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance. Every word earns its place.

  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?

  Given the complexity of a directions tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., rate limits, auth), output format, and usage context relative to siblings. For a tool that likely returns structured route data, more completeness is needed to guide effective use.

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

  Parameters3/5

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

  The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the meaning of 'trafast' vs. 'tracomfort' in more detail). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.

  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 purpose: 'provides route-finding information between two points using Naver Map API.' It specifies the verb ('provides') and resource ('route-finding information'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like geocoding or place search, which are related but distinct functions.

  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?

  The description offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (naver_geocode, naver_reverse_geocode, naver_search_places) or explain scenarios where directions are needed over geocoding or place search. There's no context about prerequisites or exclusions.

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

• naver_geocodeC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It only states the conversion function without mentioning error handling, rate limits, authentication requirements, or what happens with invalid addresses. For a geocoding tool with zero annotation coverage, this leaves significant behavioral gaps.

  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, efficient sentence in Korean that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core purpose.

  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?

  For a geocoding tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the coordinates are returned in, error conditions, or how it differs from sibling tools. The description should provide more context given the lack of structured metadata.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the parameter 'address' is already documented in the schema. The description adds no additional semantic context about address formats, language requirements, or regional considerations beyond what the schema provides. Baseline 3 is appropriate when schema does the documentation work.

  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 purpose: converting addresses to latitude/longitude coordinates. It uses specific verbs ('변환합니다' - converts) and identifies the resource ('주소' - address). However, it doesn't differentiate from sibling tools like 'naver_reverse_geocode' which performs the inverse operation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'naver_reverse_geocode' (for reverse conversion) or 'naver_search_places' (for place searches), nor does it specify any prerequisites or contextual constraints for usage.

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

• naver_reverse_geocodeC
  2.9/5.0
  Behavior2/5

  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. While it states the conversion function, it doesn't describe important behavioral aspects: what format the address is returned in, whether there are rate limits, what happens with invalid coordinates, whether authentication is required, or what service provider is used (Naver). For a tool with no annotation coverage, this is insufficient.

  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 extremely concise - a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. However, it could benefit from being slightly more informative while maintaining efficiency.

  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?

  Given the tool has no annotations and no output schema, the description is incomplete. It doesn't explain what format the address is returned in, what happens with invalid coordinates, whether there are limitations or prerequisites, or how this differs from sibling tools. For a coordinate-to-address conversion tool with no structured output documentation, the description should provide more context.

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

  Parameters3/5

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

  The schema description coverage is 100%, with both parameters (lat, lng) clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.

  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 purpose: converting latitude/longitude coordinates to an address. It uses specific verbs ('변환합니다' - converts) and resources ('위도/경도 좌표' - latitude/longitude coordinates, '주소' - address). However, it doesn't explicitly distinguish this reverse geocoding function from its sibling 'naver_geocode' (which likely does forward geocoding).

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tools (naver_directions, naver_geocode, naver_search_places) or explain when reverse geocoding is appropriate versus forward geocoding or place search. There's no context about prerequisites or limitations.

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

• naver_search_placesC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states it searches for places but doesn't describe what information is returned, whether results are paginated, rate limits, authentication requirements, or error conditions. The description is too minimal for a tool that presumably returns structured data.

  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, efficient sentence in Korean that directly states the tool's function. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a basic search 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?

  For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of place information is returned (names, addresses, coordinates, ratings, etc.), how results are structured, or any limitations. Users would need to guess about the output format and capabilities.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters (query and display). The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

  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 action ('검색합니다' - searches) and resource ('네이버 지도에서 장소' - places on Naver Maps). It distinguishes itself from siblings by specifying it searches for 'places' rather than providing directions or geocoding. However, it doesn't specify what kind of place information is returned.

  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?

  The description provides no guidance on when to use this tool versus its siblings (naver_directions, naver_geocode, naver_reverse_geocode). There's no mention of alternatives, prerequisites, or typical use cases for place search versus other mapping functions.

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