Server Quality Checklist

Tool Scores

• generate_markers_mapB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full disclosure burden, but it only states what the tool does ('generate a map') and not how it behaves: geocoding labels, auto-completing missing links via Places API, side effects, or output format. The example hints at optional link behavior, but behavioral traits are largely undisclosed.

  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?

  One leading purpose sentence followed by a compact example; no filler or repeated schema text. It is front-loaded and every element earns its place.

  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 3-param tool with full schema coverage, the description plus example is nearly sufficient to invoke, but it lacks any selection guidance against siblings and any behavioral detail such as geocoding/auto-completion. The absence of annotations and output schema raises the burden, leaving moderate gaps.

  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?

  Schema coverage is 100%, so the baseline is 3; the description adds a concrete invocation example showing the markers array with label and optional link, including a marker without a link. This demonstrates the expected JSON structure and mixed-optionality beyond the schema's formal definitions.

  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 names a specific action ('Generate a map') and the distinguishing feature ('multiple pinned locations'), so an agent can tell it apart from route/generic map tools. It does not explicitly name sibling tools or exclusion criteria, so it stops short of full differentiation.

  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 phrase 'multiple pinned locations' implies this is for multi-point map requests, but there is no explicit statement of when to choose it over generate_map, generate_route_map, or the download variants. No conditions, prerequisites, or alternatives are named, so the agent must infer usage from the name and single line.

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

• generate_mapA
  3.5/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 says 'styled map' and gives no details on output format, persistence, side effects, or return behavior. The schema notes server-side geocoding, but the description adds little behavioral context beyond the basic purpose.

  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?

  One purposeful sentence plus a concrete example, with no filler. The key constraint ('centered on a single place') is front-loaded before the example.

  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?

  The tool is simple, with two fully documented parameters and a good example, so the basics are covered. However, with no output schema, the description should clarify what a successful call returns or how the map is delivered, and that is missing.

  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 documents both parameters at 100% coverage, including the optional display name and server-side geocoding. The description's example showing place='Tokyo Station' is useful, but it does not add meaningful parameter semantics beyond what the schema already provides.

  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?

  States a specific action ('Generate') on a specific resource ('a styled map') with a clear scoping constraint ('centered on a single place'). This distinguishes it from sibling tools like generate_markers_map and generate_route_map, which imply multi-point or route maps.

  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 phrase 'centered on a single place' and the example imply when to use this tool, but there is no explicit guidance about when to prefer a sibling tool. The routing to alternatives is left to inference rather than stated.

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

• generate_route_mapA
  4/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 burden of behavioral disclosure. It honestly states that endpoints are pinned automatically and that calling generate_markers_map would be redundant. Still, it omits what the tool returns (e.g., a file path, image, or download URL) and possible side effects such as creating, overwriting, or storing a map.

  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 two short sentences plus a compact example. The core purpose is front-loaded, the anti-redundancy warning is useful, and the example is illustrative without bloat. Every sentence earns its place.

  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 tool with five parameters, no output schema, and no annotations, the description covers the key usage context: what it computes, how endpoints behave, and the warning about the sibling tool. It lacks return-format or error-behavior details, but the example helps fill practical gaps. Minor incompleteness, so 4 rather than 5.

  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 the baseline is 3. The description does not add meaning beyond the schema; the example demonstrates the from/to/mode combination but does not clarify edge cases, default behaviors, or how the optional name/place interact with route generation. Thus it meets the baseline but doesn't exceed 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?

  The description clearly states the specific verb+resource: compute a walking/driving route and generate a map with it overlaid. It also distinguishes itself from generate_markers_map by explicitly noting endpoints are pinned automatically, so the agent knows not to use that sibling.

  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?

  It provides explicit guidance on when to use this tool and notably includes a negative condition: 'do not also call generate_markers_map for them.' The example further clarifies invocation. However, it doesn't explicitly contrast with generate_map or explain when the generic map tool would be preferable, leaving some selection ambiguity.

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

• redownload_mapA
  4.2/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. It discloses that the operation is 'instant, no regeneration', which is useful behavioral context, but it does not mention return format, failure behavior for invalid data_key, or any side effects. Some value is added, but significant behavioral 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.

  Conciseness5/5

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

  The description is a single sentence plus an example, with no fluff. The key action and differentiator are front-loaded, and the example earns its place by demonstrating real usage.

  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 tool with three parameters and no output schema, the description covers purpose, behavior, and parameter usage adequately. It implies the prerequisite (a prior generate_* call's data_key) through the example and schema. Missing an explicit statement of what the tool returns, but this is minor given the straightforward 'download' intent.

  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?

  Schema description coverage is 100%, so the baseline is 3. The description adds value by linking the two optional parameters to the core purpose ('color theme or format') and providing a concrete example with data_key and color_set, which clarifies how they are used together.

  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 precise verb ('Re-download') and resource ('a prior map'), and specifies exactly what varies: 'color theme or format'. This clearly differentiates it from the sibling generate_* tools, which create new maps, and check_map_status, which inspects progress.

  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 phrase 'prior map' and the example using a data_key from a previous generate_* call make it clear this is for already-generated maps, not new generation. The 'no regeneration' note implies a lighter-weight alternative to regenerating. However, it does not explicitly say 'use this instead of generate_* when you have a data_key', leaving that inference to the agent.

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

• download_mapA
  4.6/5.0
  Behavior5/5

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

  Without annotations, the description carries the full behavioral burden and does this well: it explains that the tool waits internally, checks periodically, returns immediately if ready, and may return before readiness, requiring a subsequent call. This is valuable, non-obvious behavior that an agent must know to use the tool correctly.

  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 concise and well-structured: main purpose first, then conditional behavior, then retry instruction, then a concrete example. Every sentence earns its place without unnecessary detail or fluff.

  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 single-parameter tool with no output schema and no annotations, the description covers the essential invocation details: what to pass, what to expect, and how to handle retries. It doesn't describe response formats or error conditions, but those are not critical given the polling semantics and the presence of only one parameter.

  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 already documents data_key at 100% coverage, so the baseline is 3. The description adds meaningful value by providing a concrete example and emphasizing that the same dataKey must be reused on retry, which clarifies parameter semantics beyond 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's action: 'Check a pending generate_* job and download it once ready.' It specifies the resource (map) and the workflow stage (post-generation), distinguishing it from the generate_* siblings by focusing on downloading/checking rather than creating.

  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 provides strong usage context: use it after a generate_* call returns a dataKey, and if the job isn't ready, call it again with the same dataKey. It doesn't explicitly contrast with redownload_map, so no direct exclusions or alternative routing is provided, but the intended workflow is clear.

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