Server Quality Checklist

Tool Scores

• search_nearbyC
  2.6/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 only states the action ('搜尋附近的地點') without mentioning permissions, rate limits, pagination, or what the search returns (e.g., list of places with details). For a search tool with 5 parameters and no output schema, this is a significant gap in transparency.

  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 ('搜尋附近的地點') that is front-loaded and wastes no words. However, it's overly concise to the point of under-specification, missing context that would help the agent. It earns a 4 for brevity but loses points for not being sufficiently informative.

  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 (5 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how results are filtered or sorted, or error conditions. For a search tool with rich input options, more context 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?

  Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how 'center' interacts with 'radius' or typical use cases for 'keyword'). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose3/5

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

  The description '搜尋附近的地點' (Search for nearby places) states the general purpose but lacks specificity. It mentions the verb '搜尋' (search) and resource '地點' (places), but doesn't distinguish from siblings like 'maps_geocode' or 'get_place_details' which also involve location-related operations. The purpose is clear but not differentiated.

  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 provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions. Given siblings like 'maps_geocode' (for address conversion) and 'get_place_details' (for specific place info), the lack of usage guidelines leaves the agent uncertain about selection.

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

• get_place_detailsC
  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. While '獲取' implies a read-only operation, the description doesn't specify authentication requirements, rate limits, error conditions, or what constitutes '詳細資訊' (detailed information) in the response. This leaves significant gaps for a tool that likely interacts with external APIs.

  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 Chinese that directly states the tool's purpose without any redundant information. It's appropriately front-loaded with the core functionality and wastes no words.

  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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what '詳細資訊' includes (e.g., address, coordinates, ratings), potential authentication needs, or error handling. Given the likely complexity of interacting with Google Maps APIs and the lack of structured output documentation, more context is needed.

  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 input schema has 100% description coverage, with the single parameter 'placeId' clearly documented as 'Google Maps 地點 ID'. The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

  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 ('獲取' meaning 'get/fetch') and the resource ('特定地點的詳細資訊' meaning 'specific place's detailed information'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling tools like 'search_nearby' or 'maps_geocode', which might also provide place information in different contexts.

  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. With sibling tools like 'search_nearby' and 'maps_geocode' available, there's no indication of whether this tool is for looking up known place IDs versus searching by name or coordinates, nor any prerequisites or exclusions mentioned.

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

• maps_directionsC
  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 what the tool does but doesn't describe how it behaves: no information about rate limits, authentication needs, response format, error conditions, or whether this is a read-only operation. The description is minimal and lacks operational context.

  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 extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language, and it's front-loaded with the core functionality. Every word earns its place in this minimal description.

  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 route planning tool with 3 parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (route steps, duration, distance, etc.), doesn't mention common use cases or limitations, and provides no behavioral context. With no annotations and no output schema, users must guess about the tool's behavior and results.

  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 documents all three parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain format expectations, coordinate systems, or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 as '獲取兩點之間的路線指引' (get route directions between two points), which specifies the verb (get) and resource (route directions). It distinguishes from siblings like maps_distance_matrix (distance calculations) and maps_geocode (address conversion), but doesn't explicitly differentiate from potential route-planning alternatives.

  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 like maps_distance_matrix (for distance/time only) or search_nearby (for points of interest). It doesn't mention prerequisites, limitations, or typical use cases beyond the basic functionality.

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

• maps_distance_matrixC
  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 but only states what the tool does without behavioral details. It doesn't disclose rate limits, authentication requirements, cost implications, error conditions, or output format. For a tool that likely calls an external API with potential usage constraints, this is inadequate.

  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 extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it easy to parse and understand at a glance.

  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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like (matrix format? units?), doesn't mention API limitations or costs, and doesn't provide context about when this tool is preferable to sibling tools. The 100% schema coverage helps, but the description should do more heavy lifting.

  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 documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it just restates the core functionality without explaining parameter interactions or constraints.

  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 as calculating distances and times between multiple origins and destinations, which is specific (verb+resource). However, it doesn't distinguish this from sibling tools like maps_directions, which might provide similar routing functionality but with different output formats or use cases.

  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 like maps_directions or search_nearby. It doesn't mention prerequisites, typical use cases, or limitations, leaving the agent to infer usage from the tool name and parameters alone.

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

• maps_elevationC
  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. While '獲取' (get/retrieve) implies a read operation, the description doesn't address important behavioral aspects like rate limits, authentication requirements, data freshness, accuracy, or what happens with invalid coordinates. For a tool with zero annotation coverage, this represents significant gaps in behavioral context.

  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 extremely concise - a single phrase that directly states the tool's purpose without any unnecessary words. It's front-loaded with the essential information and contains zero wasted content. Every word earns its place in communicating the core functionality.

  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 absence of annotations and output schema, the description is insufficiently complete. For a tool that presumably returns elevation data, the description doesn't indicate what format the elevation data comes in (meters/feet, precision), whether it returns single values or arrays, or what happens with multiple locations. The lack of behavioral context combined with no output information creates significant gaps for agent understanding.

  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 the single parameter 'locations' well-documented in the schema as an array of latitude/longitude objects. The description mentions '位置' (locations) which aligns with the parameter name but adds no additional semantic context beyond what the schema already provides. This meets the baseline expectation when schema coverage is complete.

  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: retrieving elevation data for locations. It uses a specific verb ('獲取' - get/retrieve) and identifies the resource ('海拔數據' - elevation data). However, it doesn't differentiate from sibling tools like 'maps_geocode' or 'maps_reverse_geocode' which handle different geographic data types.

  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. There are multiple sibling mapping tools (geocode, reverse geocode, directions, etc.), but the description doesn't indicate that this tool specifically handles elevation data rather than other geographic information. No explicit when/when-not instructions or alternative suggestions are provided.

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

• maps_geocodeC
  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 only states the basic function without mentioning any behavioral traits such as rate limits, accuracy considerations, error handling, authentication needs, or output format. For a geocoding tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

  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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to understand at a glance.

  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 lack of annotations and output schema, the description is incomplete for a geocoding tool. It doesn't explain what the coordinates output looks like (e.g., latitude/longitude format), potential limitations, or how it integrates with sibling tools. The minimal description fails to provide sufficient context for 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%, with the single parameter 'address' fully documented in the schema as '要轉換的地址或地標名稱' (address or landmark name to convert). The description adds no additional semantic information beyond what the schema provides, such as examples or formatting tips. With high schema coverage, the baseline score of 3 is appropriate.

  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 coordinates. It specifies the verb '轉換為' (convert to) and the resource '地址' (address), making the function unambiguous. However, it doesn't explicitly differentiate from its sibling 'maps_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 the sibling tools like 'maps_reverse_geocode' for the opposite conversion, 'search_nearby' for location-based searches, or other mapping tools. There's no context about appropriate use cases or exclusions.

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

• maps_reverse_geocodeC
  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. While '將座標轉換為地址' implies a read-only lookup operation, it doesn't disclose any behavioral traits such as rate limits, authentication requirements, error conditions, or what happens with invalid coordinates. For a tool with zero annotation coverage, this is a significant gap.

  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 extremely concise and front-loaded with a single sentence that directly states the tool's function. There is zero wasted language, and every word earns its place by conveying essential 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?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., address format, possible fields), error handling, or any behavioral context. For a tool with 2 parameters and no structured output documentation, the description should provide more contextual information.

  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%, with both parameters ('latitude' and 'longitude') clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides (e.g., coordinate formats, valid ranges, or examples). Baseline 3 is appropriate when the schema does the heavy lifting.

  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 coordinates to an address. It uses a specific verb ('轉換為' meaning 'convert to') and identifies the resource (coordinates to address). However, it doesn't differentiate from sibling tools like 'maps_geocode' which likely 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 'maps_geocode' (likely address to coordinates), 'get_place_details', or 'search_nearby', nor does it specify any prerequisites, constraints, or appropriate contexts for use.

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