Loading ToolBench
A Model Context Protocol (MCP) server for querying Google Maps and Places API for places, restaurants, tourist attractions, and more. Provides tools to find places near a location, sorted by rating or distance.
Single tool with moderate naming and description quality, but significant gaps in schema completeness and parameter detail. The tool name 'find_places_nearby' follows verb-noun convention (positive). Description is present (~280 chars) and reasonably informative. However, input schema lacks critical details: no enum constraints for place_type or sort_by (allowing arbitrary strings), no min/max bounds, no explicit required vs optional markers in the schema itself. Output schema is documented in the description but not in structured JSON Schema format. Error handling is absent, no guidance on API failures, invalid locations, or malformed input. The tool accepts API-driven input (location string) without validation or fallback guidance. Pagination and result limiting are not addressed despite Google Places API returning potentially large result sets. No output field mapping to downstream tool calls documented. Security: API key is injected server-side (good), but no input sanitization visible for location parameter (SQL injection risk if location is used in database queries, though unlikely here).
Find places near a given location using Google Maps Places API. Args: location (str): Address or area name to search near. Required. place_type (str, optional): Google Places type (e.g., 'restaurant', 'tourist_attraction', 'meal_takeaway'). Default is 'places_of_interest'. sort_by (str, optional): Sort results by 'rating' or 'distance'. Default is 'rating'. Returns: list: List of places, each as a dict with keys: name, rating, vicinity, place_id, types, user_ratings_total. Example: find_places_nearby(location='New York', place_type='restaurant', sort_by='distance')
Input schema lacks enum constraints for 'place_type' and 'sort_by' parameters. Currently accepts arbitrary strings, inviting hallucinated values like 'random_type' or 'alpha_sort'. Should declare allowed values as enums (e.g., place_type: ['restaurant', 'tourist_attraction', 'meal_takeaway', 'cafe', 'hotel', 'places_of_interest'], sort_by: ['rating', 'distance']).
No result pagination or limiting documented. Google Places API returns potentially large result sets; tool currently returns all results without cap. This risks exhausting context windows. Should cap at 20 - 50 results and offer offset/limit parameters or next_cursor for pagination.
No input validation or error handling. Missing guidance on: invalid location strings, geocoding failures, API rate limits, network timeouts. Error responses should tell the LLM what to do next (e.g., 'Location not found. Try a more specific address or city name.').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Output schema documented only in description text, not in structured JSON Schema. LLMs cannot parse narrative descriptions reliably. Should return structured response with typed fields and document in formal schema (e.g., Response: {type: 'array', items: {type: 'object', properties: {name, rating, vicinity, place_id, types, user_ratings_total}}}). Current response also returns raw 'types' array, consider flattening or summarizing for clarity.
Parameter 'location' lacks format guidance and validation rules. Description says 'Address or area name' but does not specify: What happens if the user passes a street address vs a city vs coordinates? Are all formats equally valid? Should validate input format and provide clear error messages (e.g., 'Invalid location format. Expected: city name, address, or known landmark.').
No indication of tool safety or idempotency. Description does not state: Is this read-only? Can it be retried safely? Does it have side effects? Add tool annotations (readOnlyHint=true, idempotentHint=true) to help agents reason about safe retry and caching strategies.
No rate-limit guidance. Google Places API enforces quotas; repeated calls can exhaust daily limits. Tool should document rate limits, suggest caching or batching, and provide clear errors when quota is exceeded so the agent can back off gracefully.