Mapbox MCP server providing tools for geocoding, directions, routing, and location-based services
The Mapbox MCP server demonstrates solid definition quality across 6 well-structured tools. All tools have proper input schemas with Zod validation, descriptions, and type safety. Naming is clear and action-oriented (forward_geocode, poi_search, etc.). Descriptions are comprehensive and context-aware, explaining when to use each tool and what it's optimized for. Parameter schemas are well-defined with proper constraints (enums, min/max bounds, coordinate validation). However, there are notable gaps in error handling guidance, output schema documentation, and some parameter descriptions lack actionable constraint detail. The server abstracts away the Mapbox API complexity well and properly handles secret injection via environment variables.
Search for points of interest by category using Mapbox Category Search API
Calculate directions and routes between multiple waypoints using Mapbox Directions API
Forward geocode addresses, cities, towns, neighborhoods, districts, postcodes, regions, and countries using Mapbox Geocoding API v6. Converts location name into geographic coordinates. Setting a proximity point helps to bias results towards a specific area for more relevant results. Do not use this tool for geocoding points of interest like businesses, landmarks, historic sites, museums, etc. Supports both JSON and text output formats.
Computes areas that are reachable within a specified amount of time from a location, and returns the reachable regions as contours of Polygons or LineStrings in GeoJSON format that you can display on a map. Common use cases: Show a user how far they can travel in X minutes from their current location, Determine whether a destination is within a certain travel time threshold, Compare travel ranges for different modes of transportation
Calculates travel times and distances between multiple points using Mapbox Matrix API.
Output schemas not explicitly documented in tool descriptions. While MapboxApiBasedTool.ts defines a standard OutputSchema with content array and isError flag, tool descriptions do not state what fields/structure clients should expect in responses (e.g., when format='json_string' vs 'formatted_text', what the content object contains).
Error handling and recovery guidance absent from tool descriptions. Tools provide no explicit error message to the LLM explaining what to do if the API call fails, timeouts, or returns no results. For example, if proximity='ip' fails, should the LLM retry with explicit coordinates, or call a different tool?
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Find one specific place or brand location by its proper name or unique brand. Use only when the user's query includes a distinct title (e.g., "The Met", "Starbucks Reserve Roastery") or a brand they want all nearby branches of (e.g., "Macy's stores near me"). Do not use for generic place types such as 'museums', 'coffee shops', 'tacos', etc. Setting a proximity point is strongly encouraged for more relevant results. Always try to use a limit of at least 3 in case the user's intended result is not the first result. Supports both JSON and text output formats.
category_search_tool description lacks actionable detail. The description states 'Supported categories include: services, shopping, food_and_drink...' but does not explain the full list or when to use this tool vs poi_search_tool. The description is vague about the distinction: when should an LLM pick 'category_search' vs 'poi_search'? The poi_search tool description explicitly says 'Find one specific place or brand', but category_search description does not state 'Find all places in a category'.
Parameter constraints not fully described in text. For example, 'contours_minutes' in isochrone_tool has constraints (maxItems: 4, must be in increasing order) in the schema but the description does not explicitly state 'up to 4 values' or 'must be in increasing order'. LLMs may not parse JSON Schema constraints reliably; rely on description text.
matrix_tool has vague parameter descriptions. 'approaches', 'bearings', 'destinations', 'sources' are described as semicolon-separated strings but do not explain what values are valid or why an LLM should use them. No examples or actionable constraints.
MAPBOX_ACCESS_TOKEN validation in MapboxApiBasedTool only checks JWT format, not token validity or permissions. If the token is valid JWT but lacks required scopes (e.g., geocoding not enabled), the error message will not guide the LLM or user to check token configuration. Error messages should be actionable.