Mapbox MCP server providing tools for geospatial calculations and Mapbox API integrations
The server demonstrates solid tool definition quality with explicit schemas, descriptions, and parameter constraints. All 5 tools have documented input schemas with type definitions and helpful parameter descriptions. Tool names follow verb_noun conventions (area_tool, bearing_tool, bbox_tool, buffer_tool, category_list). Descriptions are substantive (80 - 150 characters) and explain purpose, offline capabilities, and units support. However, there are gaps: (1) output schemas are not documented in the provided source, critical for LLM planning; (2) category_list has a confusing pagination/limit parameter with a verbose warning note instead of clearer UX; (3) parameter descriptions could better explain when tools should be called relative to each other; (4) no error recovery guidance visible (what happens if geometry is invalid?). The offline geometric tools are well-designed for composition (each does one thing), but the category_list tool shows signs of API-leaking complexity (offset/limit pagination pattern is exposed rather than abstracted). The tool annotations flag (toolAnnotations=true) suggests READ_ONLY hints are present, which is good for agent safety.
Calculate the area of a polygon or multipolygon. Supports various units including square meters, kilometers, acres, and hectares. Works offline without API calls.
Calculate the bounding box (extent) of any geometry. Returns the minimum and maximum longitude and latitude that encompass the geometry. Works offline without API calls.
Calculate the bearing (compass direction) from one point to another. Returns bearing in degrees where 0° is North, 90° is East, 180° is South, and 270° is West. Works offline without API calls.
Create a buffer zone (polygon) around a point, line, or polygon at a specified distance. Useful for proximity analysis, service areas, or creating zones of influence. Works offline without API calls.
List categories available in the Mapbox Places API
Output schemas not documented. Tool descriptions state what input is accepted (geometry, units) but do not document the returned structure. LLMs cannot plan downstream tool calls or know what fields to extract without seeing the response schema. For example, area_tool returns an area value in the specified unit, but this is inferred, not explicit.
category_list tool exposes raw API pagination (offset/limit) instead of abstracting it. The limit parameter includes a verbose warning ('WARNING: Only use this parameter if you need to optimize token usage...') that signals the design was never intended for agents. This violates the chat-data-model principle, agents should not reason about pagination implementation details.
Parameter descriptions lack dependency guidance. For geometric tools (area_tool, buffer_tool, bbox_tool), the description does not explain when to call area_tool (after buffer_tool?) or how outputs chain. Agents must infer composition patterns rather than being guided.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
No error recovery guidance visible. Tool descriptions do not state what errors are possible (invalid geometry, unsupported units, API failures for category_list) or how the agent should respond. E.g., if buffer_tool receives distance=0, does it fail gracefully or error? The schema declares exclusiveMinimum=true but the error message is not documented.
naming: category_list should be list_categories (verb_noun convention). The name 'category_list' is a noun phrase that does not clearly signal the action to an LLM compared to 'list_categories'.