MCP server for producing latitude/longitude coordinates for cities and areas using OpenStreetMap Nominatim API
The server exposes one tool, 'get_coordinates', with adequate but not excellent definition quality. The tool name follows verb-noun convention (get_*), and the input schema is properly structured with JSON Schema types, descriptions, and constraints. However, the tool lacks output schema documentation, critical error guidance, and tool annotations. The description is moderately detailed (111 chars) but could be more precise about when to use this tool vs. alternatives. Parameter descriptions are present and include ranges (limit: 1-10), which is good. No input validation guidance or recovery patterns are documented.
Get latitude and longitude coordinates for a city or location
Output schema not documented. Tool returns structured data from Nominatim API (latitude, longitude, display_name, etc.) but the response structure is never formally documented for the LLM. Without knowing what fields to expect, agents cannot reliably extract and chain results.
No error recovery guidance. When location is not found, the tool returns a generic error dict with 'suggestions' array. However, the LLM is never told what to do next, should it retry with a different query? Try the suggestions? Call a different tool? Error responses must tell the agent what action to take.
No tool annotations. The tool is read-only (does not modify state), but this is never declared via toolAnnotations (readOnlyHint: true in current MCP spec). Without this hint, agents may incorrectly reason about whether retry is safe or whether the call has side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 63 | - | v1 |
No timeout or rate-limit documentation. The tool calls an external API (Nominatim/OpenStreetMap) with no documented timeout, retry strategy, or rate limits. If the API is slow or unresponsive, agents may hang. No guidance on handling transient failures.
Description lacks specificity on use cases. The description says 'Get latitude and longitude coordinates for a city or location' but does not clarify when to use this tool instead of alternatives (e.g., if agents had a reverse-geocoding tool or IP-to-location tool). A production description would say: 'Use this to convert a place name (city, address, or landmark) to geographic coordinates. For reverse geocoding (coordinates to place name), use [other tool]. For IP-based location, use [IP tool].'