Server Quality Checklist

Tool Scores

• maps_reverse_geocodeA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description does not need to re-state safety. It adds useful context about result ordering (most to least specific) and filter usage, but does not disclose pagination, error behavior, or output structure beyond that.

  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?

  Two sentences: first states the core function, second offers filter guidance. No wasted words, front-loaded with the primary action.

  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?

  Given no output schema, the description adequately communicates what is returned (addresses) and how to narrow results. It does not explain return formats, but for a reverse geocoding tool this level of detail is sufficient for an agent to invoke it correctly.

  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 each parameter already described. The description adds examples for result_type and location_type, but these are illustrative rather than additional semantic meaning. Baseline 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 converts coordinates into addresses, which is specific and action-oriented. It implicitly distinguishes from forward geocoding (maps_geocode) by emphasizing coordinates-to-address direction, though it does not explicitly name an alternative.

  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 when you have coordinates and need addresses, and explains when to use filters (result_type, location_type). However, it does not explicitly contrast with sibling tools like maps_geocode or provide when-not-to-use guidance.

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

• maps_directionsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the read-only safety profile is covered. The description adds behavioral context about live traffic being available for motorised modes, and notes that setting include_steps=false is 'cheaper'—useful cost/performance information beyond the annotations.

  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 three sentences long, front-loads the core purpose, and packs in essential capabilities without fluff. Every sentence earns its place, making it concise and well-structured for an 18-parameter 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?

  Given the high complexity (18 parameters, no output schema), the description partially covers what the tool returns—turn-by-turn steps or total time and distance—but does not describe the full response structure, alternative route behavior, or other return fields. While input semantics are well covered, the return value gap makes it incomplete.

  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 adds some clarification about accepted formats for origin/destination/waypoints and that include_steps=false gives totals, but much of this is already present in the schema. It does not provide significant additional meaning beyond structured definitions.

  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 computes a route with turn-by-turn steps, listing supported travel modes and key features like live traffic and avoidance options. This specific verb+resource distinguishes it from sibling tools such as maps_distance_matrix or maps_geocode.

  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 gives clear context for the tool's main use (route computation with optional waypoints and modes) but does not explicitly mention when to use it over alternatives like maps_distance_matrix. The note 'Set include_steps=false when only total time and distance matter' is a parameter-level hint, not a tool-level alternative.

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

• maps_elevationA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral details about the samples parameter creating an evenly spaced profile and the 100-pair limit, without contradicting the annotations.

  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?

  Two concise sentences convey the purpose, limits, and profile mode without any wasted words.

  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 read-only tool with two parameters and no output schema, the description sufficiently covers the unit, limits, and the optional profile mode. It could specify the response structure, but the current level is adequate.

  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?

  Both parameters are fully described in the schema (locations, samples). The description reinforces the profile behavior and limit but adds little new semantic meaning 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 returns elevation in metres for up to 100 coordinate pairs and describes the optional profile feature when samples are provided. It distinguishes itself from sibling tools by being the only elevation-related tool.

  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 explains both usage modes: direct elevation queries for coordinate pairs and profile generation when samples and at least two locations are supplied. It doesn't explicitly mention alternatives, but the context makes usage clear.

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

• maps_geocodeA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark this as readOnly and openWorld, so the description adds value by explaining the ZERO_RESULTS behavior and the output contents (normalised components, place ID, viewport). It does not contradict annotations and provides useful, non-obvious detail.

  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 three compact sentences, each earning its place: purpose, usage tip, and error-behavior note. It is front-loaded with the core function and contains no filler.

  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?

  Given the absence of an output schema, the description reasonably covers what the tool returns (coordinates, components, place ID, viewport) and a key edge case (empty array = ZERO_RESULTS). It could detail the output structure further, but it is sufficient for the tool's 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 baseline is 3. The description adds a brief usage tip for the components parameter, but most parameter meaning is already in the schema. It does not significantly deepen understanding beyond schema descriptions.

  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 converts an address into coordinates and lists additional outputs (normalised components, place ID, viewport). This distinguishes it from sibling tools like maps_reverse_geocode, which does the opposite.

  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 gives specific usage context, such as using components to narrow ambiguous addresses, e.g. 'country:CH'. It does not name alternative tools, but the core use case is clear. The 'ZERO_RESULTS' note also guides error interpretation.

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

• maps_place_autocompleteA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint and openWorldHint. The description adds performance behavior ('cheaper and faster than a full search') and output content ('place suggestions with their place IDs'), going beyond the annotations without contradicting them.

  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 exactly two sentences, front-loaded with the core purpose, and every clause adds value. No wasted words.

  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?

  Given 7 well-documented parameters and no output schema, the description covers the primary purpose, use case, and return type. It could mention behavior for no results or exact response format, but it is complete enough for an autocomplete tool.

  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 covers 100% of parameters with detailed descriptions and examples. The description itself does not add parameter-level meaning beyond the schema, 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 ('Turn') and clearly identifies the resource: partially typed text into place suggestions with place IDs. It distinguishes from siblings by stating it is 'cheaper and faster than a full search' and by scoping to resolving ambiguous input.

  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 usage context: 'when the goal is only to resolve what the user meant' with examples like 'ambiguous street or city name.' It references 'full search' as an alternative but does not explicitly name sibling tools or state exclusions.

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

• maps_place_detailsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds valuable behavioral context about the include_reviews parameter raising the billing tier, and it enumerates the default fields returned. It does not contradict annotations, and while it does not detail error behavior or output structure, the added cost disclosure goes beyond the annotations.

  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 three tightly packed sentences. The first sentence front-loads the primary action and result fields, the second adds a key cost caveat, and the third explains the prerequisite source of place IDs. No filler or redundancy—every sentence earns its place.

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

  Completeness5/5

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

  For a read-only details tool with high schema coverage and informative annotations, the description is complete. It states the purpose, lists the default return fields, warns about the cost of include_reviews, and tells the user where to obtain the required place_id. No output schema exists, but the description enumerates the key returned content, and the schema covers parameters fully.

  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 every parameter (place_id, fields, region_code, language_code, include_reviews) already described in the input schema. The tool description adds no new parameter-level meaning; it merely repeats the include_reviews cost note already present in the schema. Baseline of 3 is appropriate since the schema fully documents the parameters.

  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 exactly what the tool does: 'Full detail for one place ID' followed by a concrete list of returned fields (address components, phone numbers, website, opening hours, rating, business status). It clearly distinguishes itself from sibling tools by noting the place ID must come from maps_search_places, maps_search_nearby, maps_geocode, or maps_place_autocomplete, making the purpose unambiguous.

  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 for when to use this tool: when you have a place ID from one of the listed search/geocode/autocomplete tools and need full details. It also gives usage guidance about include_reviews costing more, implying it should only be set when reviews are truly needed. However, it does not explicitly compare against the sibling maps_place_id_lookup, so exclusion of alternatives is not fully addressed.

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

• maps_place_id_lookupA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate read-only and open-world hints. The description adds meaningful behavioral context: it uses the Geocoding API, returns address/coordinates, and explicitly lists fields it does NOT return. No contradictions. It stops short of detailing rate limits or exact return structure, but the safety profile is already covered.

  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?

  Two succinct sentences, front-loaded with the core action, then a useful efficiency/caveat comparison. Every word earns its place.

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

  Completeness5/5

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

  For a simple 2-parameter tool with no output schema, the description covers purpose, usage context, limitations, and expected result (address and coordinates). It is fully sufficient for an agent to select and invoke the tool correctly.

  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 both place_id and language described in the schema. The description does not add parameter-level details 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 clearly states the tool resolves a place ID to address and coordinates via the Geocoding API, using a specific verb and resource. It also distinguishes itself from the sibling maps_place_details by noting it is cheaper but returns fewer fields.

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

  Usage Guidelines5/5

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

  Explicitly provides when-to-use guidance by comparing to maps_place_details: use when only location is needed, and avoid when opening hours, phone, rating, or website are required. This directly helps the agent choose between tools.

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

• maps_search_nearbyA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description focuses on the key behavior that the radius is a hard restriction, not a suggestion. It also mentions optional type filtering, adding context beyond annotations, though it doesn't disclose response format or potential billing implications (the latter is covered in the 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 sentences: the first states function, the second gives a contrast and a concrete usage example. No fluff or redundancy.

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

  Completeness5/5

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

  Despite having 10 parameters and no output schema, the description communicates the essential function, the key behavioral constraint (hard radius), and the intended use case. The schema handles parameter details, so the description is sufficient for an agent to select and invoke the tool correctly.

  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% for all 10 parameters, including `included_types` and `radius_meters`. The description's mention of type filtering and circle radius maps to these but adds no new syntax or constraints, so the baseline of 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 opens with 'List places inside a circle around a coordinate,' which is a specific verb+resource+scope. It also explicitly differentiates from the sibling tool maps_search_places by noting the radius is a hard restriction, making the purpose unmistakable.

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

  Usage Guidelines5/5

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

  The description explicitly names the alternative tool (maps_search_places) and provides a concrete use-case scenario ('what is within 500 m of here'), making it clear when to choose this tool over alternatives.

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

• maps_timezoneA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds behavioral nuance: the result includes the daylight saving offset and is time-dependent. This goes beyond the annotation by explaining the DST nuance, though it doesn't detail edge cases like invalid coordinates.

  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?

  Two focused sentences. The first states the core purpose and output, the second gives crucial usage guidance. No fluff or repetition.

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

  Completeness5/5

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

  Despite lacking an output schema, the description tells the user exactly what information will be returned and explains the time-dependence. For a simple lookup tool, this is complete and self-contained.

  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 baseline is 3. The description adds value by clarifying the output (time zone name, UTC offset) and emphasizing the timestamp's role in determining DST, which is not fully apparent from the schema alone.

  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 returns 'Time zone ID, name and UTC offset for a coordinate' with a specific verb implied ('returns'). This distinguishes it from sibling tools like geocoding or place search, which serve different purposes.

  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?

  Provides clear usage guidance about passing a timestamp for past/future dates due to DST dependency. Does not explicitly mention when not to use or name alternatives, but the tool's unique function among siblings makes the context clear.

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

• maps_distance_matrixA
  4.6/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable non-obvious behavior: results are not necessarily in order, they carry originIndex/destinationIndex, and there are explicit element limits (625 general, 100 for transit/traffic-aware-optimal). These details go well beyond the annotation hints.

  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?

  Three sentences, each carrying distinct information: purpose, result structure/ordering, and limits. No filler or redundancy.

  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 description covers purpose, an example, key output characteristics, and hard limits. It doesn't fully expand the result fields (e.g., duration and distance), but the first sentence implies those, and the output schema absence is mitigated by the clear 'travel time and distance' phrasing.

  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?

  With 100% schema description coverage, the baseline is 3, but the description adds meaningful constraint: the product of origins and destinations is limited (625 max, 100 for certain modes). This gives practical semantics to the array parameters beyond what the schema states.

  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 opens with 'Travel time and distance for every origin-destination pair,' which is a specific verb+resource statement and clearly differentiates this from single-route tools like maps_directions. The depot example reinforces the pairwise use case.

  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 example 'which of five depots is closest to a customer' provides clear contextual guidance for when to use this tool. It doesn't explicitly name alternatives or exclusions, but the context is strong enough to convey the typical use case.

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

• maps_search_placesA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds behavioral nuance: results are 'biased' toward the area, not strictly confined, and mentions pagination via nextPageToken. It doesn't cover rate limits or auth, but given the annotations, this is sufficient.

  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 three sentences with front-loaded purpose, examples, return info, and usage guidance. No wasted words; every sentence contributes.

  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 description covers the core return fields, bias behavior, pagination, and differentiates from the sibling tool. While it doesn't enumerate all filters (e.g., open_now, price_levels), the schema provides those details. Given the tool's complexity and no output schema, this is a strong description.

  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 baseline is 3. The description adds value by explaining that latitude/longitude/radius_meters are a 'bias' and that nextPageToken enables paging, clarifying semantics that go beyond the schema's field descriptions.

  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 and resource: 'Search places by free-form text' with concrete examples like 'vegan restaurant in Bern'. It clearly distinguishes from maps_search_nearby by contrasting bias vs. strict radius, and mentions the return fields, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool and when to use the alternative: 'Use maps_search_nearby instead when the search must stay strictly inside a radius.' It also explains how to bias results and paginate, providing actionable usage context.

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