MapMap

list_style_layers

List everything a MapMap style theme can style: the first-party named bases a style can start from (pass one as create_style's base, or as the static-map API's style=), the named palette slots with their light/dark default colours, the skeleton layer ids (paint order) that set_layer_paint accepts, the OpenMapTiles source-layers extra layers may reference, the insertion slots (bottom, middle, top) an extra layer may name, and the rules for a theme's own sources (your data by https URL). Attribution is enforced on every compiled style and cannot be themed away. Local lookup, no network; always works.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`bases`	Yes	The first-party named bases a style can start from, in display order: pass one to `create_style`'s `base`, or to the static-map API's `style=`.
`slots`	No	The insertion slots an extra layer may name (`"slot"`), bottom of the stack first, with the layer each sits directly below. A layer without a slot goes in `middle`.
`sources`	No	The rules for a theme's own `sources` (customer data by URL).
`layer_ids`	Yes	The skeleton layer ids a theme's `layers` may override, in paint order (first = bottom).
`attribution`	Yes	The attribution contract: enforced on every compiled style, not themable.
`palette_slots`	Yes	The named palette slots a theme's `palette` may override, with their light/dark defaults, in presentation order.
`source_layers`	Yes	The OpenMapTiles source-layers the tiles emit; an extra layer on the `territory` source must reference one of these.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 12, 2026

addedOutput schema / $defs / StyleSlotInfo

Added value: +{
+  "description": "One insertion slot for extra layers (Mapbox Standard names).",
+  "properties": {
+    "before": {
+      "description": "The skeleton layer id the slot sits directly below.",
+      "type": "string"
+    },
+    "description": {
+      "description": "Where it sits, in words.",
+      "type": "string"
+    },
+    "slot": {
+      "description": "`bottom`, `middle` or `top`.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "slot",
+    "before",
+    "description"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / StyleSourcesInfo

Added value: +{
+  "description": "What a theme's `sources` block accepts.",
+  "properties": {
+    "max_geojson_sources": {
+      "description": "At most this many of them `geojson`.",
+      "format": "uint",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "max_sources": {
+      "description": "At most this many sources per theme.",
+      "format": "uint",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "types": {
+      "description": "Accepted source types.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "url_rules": {
+      "description": "The URL rules every source URL must pass.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "types",
+    "max_sources",
+    "max_geojson_sources",
+    "url_rules"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / slots

Added value: +{
+  "default": [],
+  "description": "The insertion slots an extra layer may name (`\"slot\"`), bottom of\nthe stack first, with the layer each sits directly below. A layer\nwithout a slot goes in `middle`.",
+  "items": {
+    "$ref": "#/$defs/StyleSlotInfo"
+  },
+  "type": "array"
+}

changedOutput schema / properties / source_layers / description

Previous value: -"The OpenMapTiles source-layers the tiles emit; `extra_layers` must\nreference one of these."New value: +"The OpenMapTiles source-layers the tiles emit; an extra layer on\nthe `territory` source must reference one of these."

addedOutput schema / properties / sources

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/StyleSourcesInfo"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The rules for a theme's own `sources` (customer data by URL)."
+}

Changed3 schema fields changedSep 18, 2026

addedOutput schema / $defs / StyleBaseInfo

Added value: +{
+  "description": "One entry in the named-base catalogue (`sn_style::list_bases`).",
+  "properties": {
+    "description": {
+      "description": "One line saying what the base is for. This is what to choose on.",
+      "type": "string"
+    },
+    "group": {
+      "description": "\"base\" for the two stock slates (`light`, `dark`), \"designed\" for a\ndrawn style.",
+      "type": "string"
+    },
+    "id": {
+      "description": "Base id: what `create_style`'s `base` and the static-map API's\n`style=` accept, e.g. \"navigator-night\".",
+      "type": "string"
+    },
+    "label": {
+      "description": "Short display label, e.g. \"Navigator Night\".",
+      "type": "string"
+    },
+    "restrictions": {
+      "description": "True when the base is drawn to sit under MapMap's\nvehicle-restriction overlay (only `fleet`). That overlay is a\nmapmap.ai runtime layer, not tile data and not part of any compiled\nstyle, so it draws in Studio and on /map and nowhere else. Asking\nfor this base anywhere else gets the palette alone; for a real\nrestriction answer use `check_clearance_on_route` or\n`check_adr_tunnel`, which answer for an actual vehicle.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "id",
+    "label",
+    "description",
+    "group",
+    "restrictions"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / bases

Added value: +{
+  "description": "The first-party named bases a style can start from, in display\norder: pass one to `create_style`'s `base`, or to the static-map\nAPI's `style=`.",
+  "items": {
+    "$ref": "#/$defs/StyleBaseInfo"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "palette_slots",
-  "layer_ids",
-  "source_layers",
-  "attribution"
-]New value: +[
+  "bases",
+  "palette_slots",
+  "layer_ids",
+  "source_layers",
+  "attribution"
+]

First observedSep 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and delivers real behavioral facts: local lookup, no network, always works, and the non-obvious invariant that attribution is enforced on every compiled style and cannot be themed away. Return shape is not described, but an output schema exists, so that omission is acceptable.

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 scope statement is front-loaded and each enumerated clause carries a distinct, useful vocabulary item rather than filler. It is a dense run-on sentence, but the density is information rather than padding.

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?

For a zero-parameter discovery tool with a full output schema and no annotations, the description covers what it enumerates, how to consume the results, and its operational guarantees. Nothing an agent needs before calling it is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The description nonetheless adds meaning to other tools' parameters by naming `base`, `style=`, insertion slots (bottom/middle/top), and set_layer_paint's accepted layer ids, which helps the agent chain calls correctly.

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

Purpose4/5

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

The description gives a concrete verb and resource ("List everything a MapMap style theme can style") and enumerates the exact vocabularies returned — bases, palette slots, skeleton layer ids, source-layers, insertion slots, sources rules. It implicitly distinguishes itself from get_style/set_layer_paint by naming those tools as consumers of the values, though it never states what those siblings do differently.

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?

It tells the agent what to do with the results (pass a base to create_style's `base` or the static-map API's `style=`; use skeleton layer ids with set_layer_paint), which is clear usage context. It stops short of an explicit when-to-use-this-vs-get_style statement or any exclusion.

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

All MapMap tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?