Loading ToolBench
The Mapbox MCP server defines 5 tools with complete JSON Schema input definitions and reasonable descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and parameter descriptions lack crucial constraint details. Tool naming follows verb_noun conventions well (mapbox_directions, mapbox_geocoding), and all tools have descriptions between 34-194 chars, meeting the 10-1024 char baseline. The main issues are: (1) output schemas are not documented in the provided code, forcing LLMs to infer response structure; (2) many parameter descriptions lack actionable constraint details (e.g., 'Longitude' should state the [-180,180] range in the description text, not just JSON Schema); (3) no error recovery guidance in descriptions; (4) coordinate parameters use nested objects without explaining the multi-point semantics clearly.
Get navigation route between two points
Get navigation route between multiple places using their names
Search and geocode locations by text
Calculate travel time and distance matrices between coordinates
Calculate travel time and distance matrices between places using their names
Output schemas are not documented. Tool descriptions do not specify what fields the API returns, forcing LLMs to infer response structure. This increases hallucination risk and breaks downstream tool composition.
Parameter descriptions lack actionable constraint details. E.g., 'Longitude' appears in the description but does not state the [-180,180] range; 'Departure time' does not explain the ISO 8601 format requirement in the description text (only in the regex pattern, which LLMs cannot reliably parse). Users/LLMs need constraints in natural language within the description.
No error recovery guidance in tool descriptions. Descriptions do not mention what happens if coordinates are invalid, if a route does not exist, or if the API rate limit is exceeded. Error messages returned at runtime will not be documented for the LLM to plan recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-04-07 | F | 23 | - | v1 |
Coordinate parameter semantics are ambiguous. 'Array of coordinates' does not explain whether this is a route through all points in sequence, a round-trip, or source/destination pairs. LLMs may construct requests that do not match the API intent.
No idempotency or retry semantics documented. These are HTTP GET-equivalent read-only tools, but the descriptions do not explicitly state 'This tool is idempotent and safe to retry.' This is critical for agent error recovery.
No pagination or result limit documented. Tools like mapbox_geocoding accept a 'limit' parameter (1-10), but the description does not explain what the default is (5) or when to use limits. matrix tools cap at 25 places but do not document this maximum clearly in the description.
Parameter 'profile' in mapbox_directions accepts 'driving-traffic' (with hyphen) but the same parameter in mapbox_directions_by_places and matrix tools does NOT list 'driving-traffic', only 'driving'. This inconsistency will confuse LLMs and cause wrong tool selection.
Approach, bearing, and source/destination indices are advanced parameters poorly described. E.g., 'Approaches to coordinates' does not explain what 'unrestricted' vs 'curb' mean in plain language, or when to use them. LLMs cannot reason about parameters they do not understand.