Loading ToolBench
A FastMCP server for Google Maps Platform operations, providing tools for directions, distance calculations, geocoding, and place search/details.
This FastMCP server provides 6 Google Maps tools with reasonable structure and descriptions. All tools are READ_ONLY and have action-verb names (get_*, find_*, place_*). Descriptions range from 61-251 characters, within the 10-1024 baseline but some are quite brief. Input schemas are visible and typed, but lack enums for constrained values (e.g., 'mode' accepts strings like 'driving' but is not declared as enum). Output schemas are not documented in the code. Error handling is basic, tools return error dictionaries or string messages inconsistently, without guidance on recovery. No tool annotations (readOnlyHint/destructiveHint/idempotentHint). The composition is clean: each tool does one thing. Parameter descriptions are present but terse (22-67 chars average), some missing context on valid ranges or formats.
Find/query a place with the provided name
Gives step-by-step instructions to get from origin to destination using a particular mode of transport
Finds the distance and travel time between two locations for a mode of transportation
Gets the geocode (latitude & longitude) of an address
Gets details of a provided place including name, address, phone number, website, establishment type, average rating, and total rating count
Find types of places within a radius of a location (latitude, longitude)
Constrained parameters declared as free-form strings, not enums. 'mode' parameter in get_directions, get_distance, and place_nearby accepts only 'driving', 'walking', 'bicycling', 'transit' but is typed as string with no enum constraint. Similarly, 'input_type' in find_place must be 'textquery' or 'phonenumber' but is not an enum. This invites LLMs to hallucinate invalid values; enums are self-documenting and prevent this.
Output schemas are not documented in the code or docstrings. Tools like get_directions return a dict with 'summary', 'total_distance', 'total_duration', 'steps' array, but the LLM cannot see this structure in advance. Documentation of return types is baseline 100% for A+ tools; this server provides none explicitly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling is inconsistent and lacks recovery guidance. Some tools return {"error": str(e)} (e.g., get_directions), others return plain strings (e.g., 'Address not found', 'No distance information found...'). None include actionable next steps like 'Try search_places() with a different input' or 'Ensure the API key is valid'. Errors do not classify as retryable, user-fixable, or fatal.
Parameter 'location' in place_nearby is typed as dict with description 'dictionary with lat and lng keys' but no schema for the dict structure. LLMs cannot infer that {'lat': <float>, 'lng': <float>} is required. Should be typed as object with properties lat (number) and lng (number).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are READ_ONLY and idempotent, but the schema lacks these hints. Explicit annotations help agents reason about side effects and retry safety.
Parameter descriptions are brief (22 - 67 chars) and lack format/constraint details. E.g., 'radius' in place_nearby is described as 'search area radius in meters (i.e. 2500 = 2.5km)' but does not specify min/max bounds. What is the max radius? Google's API may have limits. LLMs benefit from explicit min/max to avoid invalid requests.
No pagination or result limiting documented. Tools like find_place and place_nearby may return many results, but descriptions do not mention limits or how to iterate. If a user searches for 'restaurants', do they get 1 result, 20, or 100? LLMs need to know result cardinality to plan downstream logic.