Loading ToolBench
MCP server providing access to real world mapping data and routing via Mapy.com API
This server defines 3 tools for Mapy.com mapping operations. Tool names are action-oriented (maps_geocode, maps_reverse_geocode, maps_route) which is good. However, schemas are partially visible and descriptions, while present, lack depth and guidance. The maps_route tool has a grammatically awkward description ('route from start to end via waypoints (optional)\nbike_road type means...' reads more like notes than a polished description). All tools have input schemas with proper JSON Schema structure including type constraints and enums. No parameter descriptions are visible in the schema display, descriptions exist in names and enums but lack explanatory text in the actual schema object. Output schemas are not documented. Error handling is not visible. The server does not accept human-friendly identifiers (requires exact lon/lat or query strings); no name-based lookups are supported.
Geocode an address.
based-on-coordinates reverse geocode an address
route from start to end via waypoints (optional) bike_road type means bike route suitable for road bike bike_mountain type means bike route suitable for mountain bike car_fast_traffic type means car route with traffic :returns length: Length of the route in meters duration: Duration of the route in seconds
Descriptions lack actionable guidance. 'Geocode an address' is minimal (19 chars); does not explain WHEN to use this tool, WHAT it returns, or any prerequisites. 'based-on-coordinates reverse geocode an address' is grammatically awkward and unclear about expected input format or output structure.
Parameter descriptions missing in schema. The schema shows enums and constraints (e.g., lang enum, limit bounds) but NO per-parameter 'description' fields are visible. LLMs cannot infer what 'query' accepts (free text? address format? country code required?).
Output schemas not documented. None of the tools document their return types. LLMs cannot plan downstream calls without knowing what fields are returned. For maps_geocode, do results include coordinates? address components? confidence scores? Undocumented return structure violates pattern:tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
maps_route description is disorganized. The docstring mixes explanation ('route from start to end via waypoints') with inline route type documentation ('bike_road type means...') and return value format (':returns length: Length...') in a single unstructured block. Should be: 1) clear action sentence, 2) when to call it, 3) distinct return field docs.
No error handling guidance visible. The async client calls raise_for_status() on HTTP errors but does not document what happens on 404 (address not found), 401 (invalid API key), rate limits, or timeouts. LLMs need actionable recovery hints like 'If no results, try broadening the query or specifying a language.'
Parameter naming could be more explicit. 'query' in maps_geocode is vague, is it a street address? city name? ZIP code? 'lang' is clear but accepts ISO 639-1 codes without explanation. 'limit' defaults to 5 without documented rationale. Consider 'address_query', 'result_language', 'max_results' for clarity.