Loading ToolBench
Enhanced Google Maps MCP Server with visual capabilities (Street View, Static Maps), weather, air quality, solar, pollen, and routing for comprehensive camping and outdoor research
The server provides 14 tools with explicit schemas and descriptions. However, there are systematic gaps in schema completeness, parameter descriptions, and output documentation. Tool naming follows verb_noun conventions appropriately (maps_geocode, maps_search_places, etc.), but several tools lack critical parameter details, validation constraints, and output schema documentation. The descriptions are generally 50-150 characters but lack actionable context for LLM selection and error recovery. No tool annotations (readOnlyHint, idempotentHint) are present despite all tools being read-only. Error handling guidance is absent, tools will fail with generic API errors rather than coaching the LLM on recovery steps.
Get air quality data for a location
Get directions between two points
Calculate travel distance and time for multiple origins and destinations
Get elevation data for locations on the earth
Convert an address into geographic coordinates
Get detailed information about a specific place
Get pollen forecast data for a location
No output schema documentation for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., place_id chains, coordinate extraction for multi-step workflows). Without documented return types, agents must infer structure from unnamed responses.
Missing parameter descriptions for optional parameters in maps_search_places (location, radius) and maps_routes (routing_preference). While main parameters are documented, optional parameters lack guidance on when to use them or their impact on results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-04-07 | F | 22 | - | v1 |
Convert coordinates into an address
Get enhanced route details using Google Routes API with traffic awareness and alternative routes
Search for places using Google Places API
Get solar radiation data for a location
Generate a static map image URL with optional markers and customization
Get Street View image URL for a location with viewing parameters
Get weather forecast data for a location
No validation constraints on numeric parameters. maps_search_places declares radius max 50000m in description but no minimum/maximum in schema. maps_weather forecast_days is '1-16' in description only, not as schema minItems/maxItems. maps_solar tilt/azimuth (0-90 and 0-360) lack bounds in schema. LLMs cannot self-validate and will pass out-of-range values.
No error handling guidance. Tools will fail with raw Google Maps API errors (ZERO_RESULTS, INVALID_REQUEST, etc.) without coaching LLMs on recovery. E.g., geocoding an invalid address returns ZERO_RESULTS with no suggestion to retry with a simplified query or call search_places instead.
No tool annotations. All 14 tools are read-only (GET/idempotent). JSON should include readOnlyHint=true for proper agent reasoning about retry safety and composition. Absence forces agents to assume all tools could have side effects.
Descriptions lack actionable context. E.g., 'Convert an address into geographic coordinates' does not explain when to use maps_geocode vs search_places, or what the output structure contains.
Parameter naming lacks type suffixes. maps_distance_matrix origins/destinations accept 'Array of origin addresses or coordinates' but the schema is just type:string[], no guidance on format. Should document: 'address string, or lat,lng comma-separated, or lat:lng colon-separated' and validate inside tool.
maps_routes and maps_directions accept 'Travel mode' but with different enum values: maps_directions uses [driving, walking, bicycling, transit] (lowercase), maps_routes uses [DRIVE, WALK, BICYCLE, TRANSIT] (uppercase). Inconsistent naming forces LLMs to remember which tool uses which case or causes silent failures.
maps_street_view and maps_static_map include download/downloadDir parameters, but no output field or response schema documenting what 'download' returns (local file path? success flag?). If download=true, what does the LLM receive to verify success or pass to another tool?