Server Quality Checklist

Tool Scores

• google_maps_photosC
  2.9/5.0
  Behavior2/5

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

  The description is a single 'retrieve' statement and does not disclose behavioral traits such as identifier requirements, empty-result behavior, pagination, or read-only guarantees. Since no annotations are provided, the description carries the full burden of behavioral disclosure and falls short. It does not contradict any annotation, but it adds little beyond what the tool name already implies.

  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, front-loaded sentence with no filler, repetition, or redundant phrasing. It is efficient and readable, though it sacrifices some behavioral and usage context for brevity. Every word 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 read-only tool with a complete output schema and fully documented parameters, the one-sentence description is minimally viable: it names the resource and lets the schema handle invocation details. However, it lacks guidance for choosing among sibling photo/review/post tools and offers no behavioral caveats. An agent could likely call it correctly with placeId, but not optimally in all contexts.

  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?

  All five parameters are fully documented in the schema with 100% coverage, so the description does not need to repeat them. The description adds no extra meaning about how dataId, placeId, or categoryId interact, but the schema already provides that information. The baseline of 3 applies because the schema carries the parameter semantics.

  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 uses a specific verb ('Retrieve') and a concrete resource ('the photo feed for a place'), which clearly distinguishes it from sibling tools like google_maps_search, google_maps_reviews, and google_maps_posts. It does not explicitly state scope details like category filtering, but the schema covers that. Overall, an agent can tell what this tool does without opening the schema.

  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 such as google_maps_reviews, google_maps_posts, or google_maps_contributor_reviews. There are no exclusions, conditions, or hints about which sibling tool to choose for non-photo content. The only implied context is 'for a place,' which is too thin to route an agent reliably.

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

• google_maps_reviewsC
  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 conveys that the operation is a retrieval and mentions sorting and topic filtering capabilities, but it says nothing about identifier precedence among the three optional identifiers (dataId, placeId, query), fallback resolution, or read-safety guarantees, leaving important behavior undisclosed.

  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?

  A single 13-word sentence that is front-loaded with the verb and resource and wastes no words. It is efficient, but the brevity comes at the expense of usage guidance and behavioral depth, making it slightly under-sized for a 7-parameter tool with five siblings.

  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 output schema covers return values and the input schema covers parameters at 100%, so those gaps are closed by structured data. However, with no annotations and five siblings including a near-duplicate (google_maps_contributor_reviews), the 13-word description is too thin to let an agent confidently select and invoke the tool; it lacks usage differentiation and behavioral 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?

  Schema description coverage is 100%, so the input schema already documents all seven parameters with defaults and relationships (e.g., query as 'fallback if ID is not available'). The description adds no parameter-level detail beyond pointing at sorting and topic filtering, which map directly to sortBy and topicId, so the baseline 3 applies.

  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 ('Retrieve') and resource ('review feed for a place'), and adds capability modifiers (sorting, topic filtering) that tell the agent what the tool can do. The phrase 'for a place' implies a distinction from the google_maps_contributor_reviews sibling, but that differentiation is implicit rather than explicitly named, so it stops short of a 5.

  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?

  There is no guidance on when to use this tool versus alternatives, a notable gap given five siblings including the closely related google_maps_contributor_reviews and google_maps_place_details. No when-to-use, when-not-to-use, or alternative routing is provided; the agent must infer the use case from the single phrase 'for a place.'

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

• google_maps_postsB
  3.3/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 burden for behavioral disclosure. It only states 'Retrieve', implying a read operation, but provides no details about pagination, limits, authorization, or what distinguishes posts from other content. There is no contradiction, but the information is minimal.

  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 with no filler. The key verb and object are front-loaded, and it earns its place by clarifying the exact scope of the tool.

  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 output schema covers return values, but the description leaves a meaningful gap: there are two optional identifier parameters (dataId and placeId) yet no guidance on whether at least one is required or how they interact. For a tool with this simplicity, the minimal description is adequate but not fully 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 description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level meaning, but the schema already documents each parameter (hl, limit, dataId, placeId) adequately.

  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 ('Retrieve') and a particular resource ('the business's own posts, announcements, and updates'). The qualifier 'own' clearly separates this from sibling tools like reviews and photos, so an agent can identify the right tool without opening the schema.

  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 gives no guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. It does not mention that dataId or placeId must be provided, nor when to prefer this over google_maps_reviews or google_maps_photos.

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

• google_maps_contributor_reviewsA
  3.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 basic read operation and scope; there is no mention of pagination, ordering, error cases, or whether contributorId can be a profile link rather than an ID. It is a minimal functional statement with no extra 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 a single clear sentence that front-loads the action and object. There is no redundant phrasing, and every word contributes to understanding the tool's purpose.

  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?

  The tool is simple: one required parameter, no enums, no nested objects, and an output schema is available. The concise scope statement is largely sufficient for invoking the tool correctly. It lacks usage-alternative guidance and deeper behavioral caveats, but those are not critical given the schema and low complexity.

  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 including defaults for hl and num. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 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?

  The description uses a specific verb ('retrieve'), names the resource ('reviews written by a specific reviewer'), and defines the scope ('across all places they rated'). This clearly distinguishes it from sibling tools like google_maps_reviews, which presumably returns reviews for a specific place.

  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 the use case: use this tool when you need a reviewer's reviews across multiple places. However, it does not explicitly state when to use this tool versus alternatives like google_maps_reviews, nor does it mention any exclusions or trade-offs.

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

• google_maps_place_detailsA
  3.9/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the behavioral disclosure burden. 'Get' implies a read-only fetch and 'in full' suggests comprehensive detail, but the description does not explain what happens when multiple identifiers are supplied, whether query performs a lookup and picks the top result, or what 'full' excludes (e.g., reviews/photos are separate tools). This is a notable gap but the core read behavior is communicated.

  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 tight sentence that front-loads the verb and resource, followed by a compact list of input options. Every word earns its place with zero redundancy or 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?

  The tool has four optional parameters and no required fields, yet the description does not tell the agent that at least one lookup key must be provided, nor how to prioritize between placeId, dataId, and query. The output schema covers return values, but the description alone leaves the invocation rules underspecified.

  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 parameters are fully documented in the schema. The description reinforces the three lookup keys but adds no syntax, format, or precedence information beyond what the schema already provides. Baseline 3 applies.

  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 verb ('Get'), a clear resource ('one place in full'), and the three lookup methods (placeId, dataId, search query). This sharply distinguishes it from sibling tools like google_maps_search (which returns multiple results) and google_maps_reviews/photos/posts (which return sub-resources).

  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 clear context: use this when you need full details for a single place and already have a placeId, dataId, or can supply a search query. It does not explicitly name alternatives or exclusions, but the sibling list and tool name make the use case obvious.

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

• google_maps_searchA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the behavioral burden. It discloses the useful ranking behavior ('Ranked as Google Maps ranks them') and 'Search' implies a read-only lookup, but it does not address potential limitations, result scope, or any external API constraints. Still, it provides some meaningful behavioral context beyond the bare schema.

  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 with no wasted words. The core action is front-loaded, and the second sentence adds a distinct behavioral detail rather than repeating the tool name or schema.

  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?

  With an output schema present and full parameter documentation in the input schema, the description is sufficient for a basic search tool. It could optionally mention how to proceed to details or reviews, but the sibling tool names supply that 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 input schema already describes all five parameters with 100% coverage, including defaults for gl, hl, ll, and start. The description adds no parameter-level detail, which is acceptable because the schema carries the semantic weight.

  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 ('Search Google Maps') and its object ('places matching a query'), distinguishing it from sibling tools that fetch details, reviews, photos, or posts. The added note about ranking as Google Maps ranks them further clarifies the expected result ordering.

  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 makes the primary use case clear: find places by query. It does not explicitly mention when not to use it or point to alternatives like place_details, but the search-specific wording and sibling tool names imply the appropriate context without ambiguity.

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