Loading ToolBench
A hybrid MCP server and client that integrates Google Maps and Airbnb services, providing tools for geocoding, place search, directions, distance matrix, elevation data, and accommodation search through a Flask API
Server has 7 tools with basic schemas and descriptions, but significant gaps prevent higher scores. All tools have descriptions (10-200 chars, baseline 194), but most are generic and lack actionable context for LLM selection. Input schemas are present and typed, but lack parameter descriptions, critical for LLM reasoning. No output schemas documented. Error handling is minimal (basic status checks, no recovery guidance). Tool names follow verb_noun convention (maps_*) but are somewhat generic. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is reasonable, each tool has one responsibility, but chaining metadata (IDs needed for follow-up calls) is not consistently returned.
Calculates directions and route information between an origin and destination using Google Maps Directions API
Calculates distances and travel times between multiple origins and destinations using Google Maps Distance Matrix API
Retrieves elevation data for specified geographic locations using Google Maps Elevation API
Converts an address to geographic coordinates (latitude/longitude) using Google Maps Geocoding API
Retrieves detailed information about a specific place including name, address, phone, website, rating, reviews, opening hours, and photos using Google Maps Places API
Converts geographic coordinates (latitude/longitude) to an address using Google Maps Reverse Geocoding API
Parameter descriptions missing. Input schemas define types (string, number, array, object) but lack descriptions explaining what each parameter controls, expected format, or constraints. LLMs cannot infer parameter meaning from names alone (e.g., 'mode' could mean HTTP method, travel mode, or operational mode).
Output schemas not documented. Tools return structured objects (location, formatted_address, place_id, etc.) but no schema is provided to LLMs. Without documented return types, agents cannot plan downstream calls or extract the right fields reliably.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
Searches for places by query text, optionally filtered by location and radius using Google Maps Places API
Error handling lacks recovery guidance. Tools throw generic errors ('Geocoding failed: ZERO_RESULTS') without actionable next steps. LLMs receive no guidance on whether to retry, ask the user, or try an alternative tool.
Tool descriptions are generic and lack context for LLM selection. Descriptions state WHAT the tool does but not WHEN to use it or how it differs from similar tools. E.g., 'maps_search_places' vs 'maps_place_details', when should an LLM call each? Descriptions do not clarify.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only (safe to retry), but this is not declared in the schema. Agents cannot infer idempotency or safety without explicit hints.