Loading ToolBench
Geoapify MCP — wraps the Geoapify Location Platform (geoapify.com)
Four tools with complete input schemas and descriptions. Naming follows verb_noun convention (geocode, reverse_geocode, places, routing). Descriptions are detailed (150-250 chars) and include examples. However, output schemas are NOT documented, the code shows feature mapping but LLMs cannot see what fields to expect. Parameters lack enums for constrained values (e.g., 'mode' in routing accepts 'drive|walk|bicycle|transit' but is declared as free-form string). The _apiKey parameter violates secret-injection pattern by exposing it as a tool parameter, though the description attempts to mitigate by suggesting omission. Error handling is minimal, only status/body returned, no recovery guidance. No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only.
Forward geocoding: convert an address, place name, or freeform location text into geographic coordinates (latitude/longitude). Returns matched candidates with formatted address, lat, lon, country, city, and postcode. Example: geocode({ text: "1600 Amphitheatre Parkway, Mountain View, CA" })
Search for places and points of interest (POI) near a location, filtered by Geoapify category. Returns name, formatted address, categories, lat, lon, and distance from the center point. Example: places({ categories: "catering.restaurant", lat: 48.8584, lon: 2.2945, radius: 1000 })
Reverse geocoding: convert latitude/longitude coordinates into the nearest street address. Returns formatted address, country, city, street, house number, and postcode. Example: reverse_geocode({ lat: 48.8584, lon: 2.2945 })
Routing / directions: compute the distance and travel time between two points for a given travel mode (drive, walk, bicycle, transit). Returns distance in meters and time in seconds. Example: routing({ from_lat: 48.8584, from_lon: 2.2945, to_lat: 48.8606, to_lon: 2.3376, mode: "drive" })
Output schemas not documented. Code maps GeoJSON features to flat objects but LLMs cannot see the response structure. This forces agents to guess what fields are returned and breaks downstream tool chaining.
_apiKey exposed as tool parameter violates secret-injection pattern. Credentials should never appear in tool parameters, they end up in logs and traces. Use server-side environment variable injection instead.
Constrained parameters declared as free-form strings. 'mode' in routing accepts only 'drive|walk|bicycle|transit' but is typed as string with no enum. LLMs will hallucinate invalid values like 'car' or 'public_transit'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
No tool annotations despite all tools being read-only. Missing readOnlyHint prevents agents from understanding that these tools have no side effects and are safe to call speculatively.
Error handling returns raw HTTP status and body. No recovery guidance. 'Invalid API key' should suggest 'Provide a valid Geoapify key via _apiKey parameter or contact Pipeworx support.'