Skip to main content
Glama
mapbox

Mapbox Developer MCP Server

Official
by mapbox

Build Mapbox Style JSON Tool

style_builder_tool
Read-onlyIdempotent

Generate and update Mapbox style JSON with automatic layer resolution using Streets v8 data. Control styling with layer actions, filters, and standard style config.

Instructions

Generate Mapbox style JSON for creating new styles or updating existing ones.

The tool intelligently resolves layer types and filter properties using Streets v8 data. You don't need exact layer names - the tool automatically finds the correct layer based on your filters.

BASE STYLES: • standard: ALWAYS THE DEFAULT - Modern Mapbox Standard with best performance • Classic styles: streets-v12/light-v11/dark-v11/satellite-v9/outdoors-v12/satellite-streets-v12/navigation-day-v1/navigation-night-v1 Only use Classic when user explicitly says "create a classic style" or working with existing Classic style

STANDARD STYLE CONFIG: Use standard_config to customize the basemap: • Theme: default/faded/monochrome • Light: day/night/dawn/dusk • Show/hide: labels, roads, 3D buildings • Colors: water, roads, parks, etc.

LAYER ORDERING: • Layers are rendered in order - last layer in the array appears visually on top • The 'slot' parameter is OPTIONAL - by default, layer order in the array determines visibility • For Standard style, you can optionally use 'slot' to control placement:

  • No slot (default): Above all existing layers in the style

  • 'top': Behind Place and Transit labels

  • 'middle': Between basemap and labels

  • 'bottom': Below most basemap features

LAYER RENDERING: • render_type controls HOW to visualize the layer (line, fill, symbol, etc.) • Most important: Use render_type:"line" for outlines/borders even on polygon features • Default "auto" picks based on geometry, but override for specific effects:

  • Building outlines → render_type:"line" (not fill!)

  • Solid buildings → render_type:"fill" or "fill-extrusion" (3D)

  • Road lines → render_type:"line" (auto works too)

  • POI dots → render_type:"circle"

  • Labels → render_type:"symbol"

LAYER ACTIONS: • color: Apply a specific color • highlight: Make prominent • hide: Remove from view • show: Display with defaults

AUTO-DETECTION: The tool automatically finds the correct layer from your filter_properties. Examples: • { class: 'park' } → finds 'landuse' layer • { type: 'wetland' } → finds 'landuse_overlay' layer • { maki: 'restaurant' } → finds 'poi_label' layer • { toll: true } → finds 'road' layer • { admin_level: 0 } → finds 'admin' layer (for country boundaries) • { admin_level: 1 } → finds 'admin' layer (for state/province boundaries)

IMPORTANT LAYER NAMES: • Use "admin" for all boundaries (countries, states, etc.) • Use "building" (singular, not "buildings") • Use "road" for all streets, highways, paths

If a layer type is not recognized, the tool will provide helpful suggestions showing: • All available source layers from Streets v8 • Which fields are available in each layer • Examples of how to properly specify layers and filters

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layersYesLayer configurations based on the mapbox-style-layers resource
base_styleNoBase style template. ALWAYS use "standard" as the default for all new styles. Standard style provides the best performance and modern features. Only use Classic styles (streets/light/dark/satellite/outdoors/navigation) when explicitly requested with "create a classic style" or when working with an existing Classic style.standard
style_nameNoName for the styleCustom Style
global_settingsNoGlobal style settings
standard_configNoConfiguration for the base Mapbox Standard style. These properties customize the underlying Standard style features - you can still add your own custom layers on top using the layers parameter. The Standard style provides a rich basemap that you can configure and enhance with additional layers.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context: auto-detection of layers, layer ordering, rendering types, and base style configuration. It does not contradict any annotations and provides transparency about tool behavior beyond what annotations offer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear sections (base styles, config, layer ordering, rendering, actions, auto-detection, important names). It is front-loaded with purpose and each section adds value. Some redundancy in examples could be trimmed, but overall it is efficient given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description thoroughly explains the tool's output: Mapbox style JSON. It covers all major aspects: base style selection, layer configuration, global settings, standard style customization, and auto-detection. The description is comprehensive for a complex tool, leaving no significant gaps for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning beyond schema descriptions. For example, it explains slot placement in layering, render_type choices with specific use cases, filter_properties with examples, and layer_type usage. This enhances the agent's understanding of how to use parameters effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates Mapbox style JSON for creating or updating styles. It specifies the tool resolves layer types and properties using Streets v8 data, and auto-detects layers. This effectively distinguishes it from sibling tools like create_style_tool or update_style_tool which handle other aspects of style management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive guidance: when to use standard vs classic styles, how layer ordering works, how to use render_type, and auto-detection examples. While it doesn't explicitly state when not to use the tool, it gives clear context and effectively differentiates from siblings. The description implies that classic styles should only be used on explicit request.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mapbox/mcp-devkit-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server