Skip to main content
Glama

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, and the OpenMapTiles source-layers extra layers may reference. Attribution is enforced on every compiled style and cannot be themed away. Local lookup, no network; always works.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
basesYesThe 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=`.
layer_idsYesThe skeleton layer ids a theme's `layers` may override, in paint order (first = bottom).
attributionYesThe attribution contract: enforced on every compiled style, not themable.
palette_slotsYesThe named palette slots a theme's `palette` may override, with their light/dark defaults, in presentation order.
source_layersYesThe OpenMapTiles source-layers the tiles emit; `extra_layers` must reference one of these.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
      +]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description assumes the behavioral disclosure burden. It states that lookup is local, requires no network, and always works, and it discloses that attribution is enforced on compiled styles and cannot be themed away. It does not describe the output shape, but an output schema exists, so that is not required.

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?

It is one long, information-dense sentence, but every clause contributes either a content category, a consumer tool, or a behavioral caveat. It could be split into multiple sentences for readability, but there is no filler or repetition.

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 no-argument enumeration tool with an output schema, the description fully covers the returned categories, the downstream consumers of those categories, and the notable behavioral constraints. Nothing an agent needs to invoke it correctly 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 has zero parameters, making parameter-level explanation unnecessary. The description still adds semantic value by showing how the returned identifiers plug into create_style and set_layer_paint, which is more than the empty input schema can convey.

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?

Description opens with a concrete verb–resource pair ('List everything... can style') and enumerates four distinct content categories: named bases, palette slots, skeleton layer ids, and source-layers. It references sibling tools such as create_style, set_layer_paint, and the static-map API, making it easy to distinguish from the many nearby style/route tools.

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 explains what the listed values are for: pass a base to create_style or the static-map style= parameter, and pass skeleton layer ids to set_layer_paint. It does not explicitly frame when to use this tool over alternatives like get_style, but the usage context is clear and no exclusions are needed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources