Server Quality Checklist

Tool Scores

• around_searchB
  3.3/5.0
  Behavior2/5

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

  Without annotations, the description must fully disclose behavior, but it only states the basic search operation. It does not mention important traits like rate limits, authentication requirements, or result ordering. The example adds some context but lacks depth.

  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 with a single sentence and an example, no redundant words. It front-loades the core functionality efficiently.

  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?

  Given the tool's simplicity, the description covers the basic purpose but lacks details about output format, error conditions, and behavioral limits. The absence of an output schema means the agent must assume the response structure. It is minimally complete for basic 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 descriptions cover all parameters, so the baseline is 3. The description reinforces parameter usage through an example (keywords '餐厅', radius 1km) but does not add new semantic constraints beyond the schema. The integration of parameters into the action is slightly enhanced.

  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 clearly states the tool searches for nearby POIs (point of interest) given a coordinate and radius, with an illustrative example. This unambiguous action separates it from sibling tools like geocode and regeocode which handle coordinate conversions. The purpose is specific and easy to understand.

  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 over alternatives like text_search. The description only explains what the tool does without mentioning prerequisites, limitations, or use cases. An agent would need to infer from context when to choose this tool.

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

• regeocodeA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so description must bear full burden. It only states the conversion and precision level, but omits important behavioral traits like coverage area, error handling, rate limits, or response format. Minimal disclosure.

  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?

  Very concise: one sentence plus example. No fluff, but could be better structured with bullet points for readability. Still efficient.

  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?

  Given no output schema, description should hint at return value (e.g., address components). It doesn't. Schema covers params well, but overall completeness is adequate but not thorough.

  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 coverage is 100%, so baseline accuracy. Description reinforces the location format with an example but adds no new meaning beyond the schema's descriptions. Radius is explained in schema; description doesn't enhance it.

  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?

  Description clearly states the tool converts coordinates to administrative address with street-level precision, and provides a concrete example. It distinguishes from sibling tools (geocode, text_search, around_search) by its reverse-geocoding nature.

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

  Usage Guidelines4/5

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

  The description implies the tool is for reverse geocoding, and sibling names suggest different functionalities. However, no explicit guidance on when to use versus when not to, or alternatives.

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

• text_searchA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses the result limit (top 10) but does not mention other behaviors such as ordering, error handling, or auth requirements. This partial disclosure earns a 3.

  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, concise sentence that communicates the essential purpose and result limit with no extraneous words. It is well-structured and front-loaded.

  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?

  Given the absence of an output schema and annotations, the description is adequate but not complete. It explains the basic functionality and result limit but lacks details on response structure, error behavior, or interaction between parameters. With three siblings, more comparative context would help.

  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 coverage is 100% with descriptions for each parameter. The description reiterates the purpose of city and keywords but adds no new semantics beyond the schema. The types parameter is already explained in the 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 clearly states the tool searches for POIs (hotels, restaurants, attractions, landmarks) by keyword within a specified city and returns the top 10 results. This distinguishes it from siblings like geocode (address to coordinates) and around_search (location-based search).

  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 for keyword-based POI search within a city but does not explicitly state when to use this tool over alternatives like around_search. No guidance on prerequisites or exclusions is provided.

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

• geocodeA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It discloses core behavior (parsing address to lng,lat coordinate string) and output format via example. However, it does not address edge cases (e.g., unresolved address, multiple matches) or any limitations.

  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?

  Single sentence with an example, no redundant words. Information is front-loaded and efficiently communicated.

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

  Completeness4/5

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

  For a simple geocoding tool with no output schema, the description adequately explains input and output. It lacks details on error handling or result format variations, but the example compensates partially. Given no annotations, it is reasonably complete.

  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 coverage is 100% with descriptions for both parameters. The tool description adds no additional parameter meaning beyond what the schema already provides (e.g., city is optional, address is structured). Baseline 3 is appropriate.

  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?

  Description clearly states the verb ('解析', parse/resolve) and resource ('结构化地址' to '经纬度坐标'), with a concrete example. It distinguishes from sibling tools: 'regeocode' (reverse), 'text_search', 'around_search' by being specifically address-to-coordinates.

  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?

  Description implies usage context (structured address to coordinates) but does not explicitly state when to use this vs. alternatives like 'regeocode' or 'text_search'. No exclusions or comparison given.

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