A client application that finds a meeting point between two addresses using Google Maps APIs
Scoring was not performed
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract nested fields (e.g., latitude/longitude from geocode response, places array structure, route geometry). Code shows unpacking .content[0].text and navigating JSON structures like geo_json['location']['lat'], but tool definitions do not expose this contract.
Parameter descriptions are too brief and lack constraint information. 'The address to geocode' does not specify format (street address, zip code, partial match), whether it accepts multiple addresses, or what happens if ambiguous. 'Search radius in meters' lacks min/max bounds, does it accept 0.5m? 10000m? Travel mode in maps_directions mentions '(e.g., 'driving')' in description but should use enum constraint (driving, walking, transit, bicycling).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Location parameter in maps_search_places is typed as object but lacks full JSON Schema definition. The schema shows properties with latitude/longitude as numbers but no minItems, required array, additionalProperties, or description of each sub-property. This is incomplete schema design, LLMs cannot reliably construct the nested object without explicit field documentation.
No error handling or recovery guidance in tool definitions. Code shows exception handling (extract_json_from_result, get_lat_lng) but tool descriptions do not explain failure modes: What if geocoding returns zero results? What if the address is ambiguous? What if API rate limit is hit? LLMs have no guidance on next steps.
Tool descriptions are minimal (40 - 50 characters each). 'Geocode an address to get its latitude and longitude coordinates' lacks WHEN to use, dependencies (e.g., call this first if you only have an address), and what the coordinates enable. Should explain: 'Use when you have a user address and need geographic coordinates for proximity searches or route planning.'
No pagination or result limiting documented for maps_search_places. If a search returns thousands of places near the midpoint, the tool returns all of them, risking context window exhaustion. Code shows max() selection logic but tool definition does not mention result count limits or pagination parameters. Pattern requires result caps (20 - 50 items) with pagination support.
No output field naming guidance. Code unpacks nested structures like geo_json['location']['lat'], routes[0]['distance']['text'], geometry['location'], but LLMs do not see this in the tool definition. Output schema should document field names, types, and nesting so LLMs can compose chained calls.