MapMap

create_style

Create a hosted map style. Provide a name, optionally a named base to start from (light, dark, streets, midnight, navigator-day, navigator-night, fleet, outdoor, dataviz, backdrop, print - call list_style_layers for what each one is for), and optionally a theme document ({base: "light"|"dark", palette: {slot: colour}, layers: {layer_id: overrides}}). The named base is laid down first and the theme document is merged over it, so "streets with darker water" is one call; with neither, the style starts from the default theme. A theme may also set worldview (ISO 3166-1 alpha-2, accepted: AE, KR, SA, US) to display that jurisdiction's official names for a small curated registry of renamed features; omitted, labels keep the OSM on-the-ground names. Returns the generated style_id (pass it to set_palette / set_layer_paint) and the compiled style URL for MapLibre.

Input Schema

TableJSON Schema

Name	Required	Description
`base`	No	Optional named base to start from, e.g. "streets", "midnight", "navigator-night", "fleet". Call `list_style_layers` for the catalogue, including which bases expect an overlay of their own. The base's whole document is laid down first and `theme` is merged over it, so a base plus two palette entries is a complete style. Omitted, the style starts from the default light theme as it always did.
`name`	Yes	Human-readable style name; its kebab-case slug seeds the style id.
`theme`	No	Optional theme document (palette/layer overrides). Merged over `base` when one is given; on its own, it replaces the default theme outright.

Output Schema

TableJSON Schema

Name	Required	Description
`theme`	Yes	The theme document that was stored.
`version`	Yes	The published version (always 1 on create).
`style_id`	Yes	The generated style id — pass it to `set_palette`, `set_layer_paint` and `get_style`.
`style_url`	Yes	Immutable URL of the compiled style at this version.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 18, 2026

addedInput schema / properties / base

Added value: +{
+  "description": "Optional named base to start from, e.g. \"streets\", \"midnight\",\n\"navigator-night\", \"fleet\". Call `list_style_layers` for the\ncatalogue, including which bases expect an overlay of their own. The\nbase's whole document is laid down first and `theme` is merged over\nit, so a base plus two palette entries is a complete style. Omitted,\nthe style starts from the default light theme as it always did.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedInput schema / properties / theme / description

Previous value: -"Optional theme document (palette/layer overrides). Omitted, the\nstyle starts from the default theme carrying `name`."New value: +"Optional theme document (palette/layer overrides). Merged over\n`base` when one is given; on its own, it replaces the default theme\noutright."

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

There are no annotations, so the description carries the full behavioral burden. It discloses the merge order (base first, theme merged over it), the default behavior when neither is provided, the special worldview behavior with accepted values and fallback behavior, and the return contract. This is rich, accurate behavioral context beyond the schema.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: creation intent, parameter choices, merge behavior, worldview behavior, and return value. It is front-loaded with the core purpose and organized so the reader learns the default case before the edge cases.

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 tool with three parameters, no annotations, and a nontrivial merge model, the description is complete. It explains how base, theme, and defaults interact, names the downstream tools for the returned style_id, and specifies the compiled style URL. Nothing essential is missing for an agent to invoke it correctly.

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?

The schema already provides 100% coverage for parameter names, but the description adds significant extra meaning: the exact list of base values, the theme document structure with base/palette/layers, the merge semantics, and the worldview field with allowed country codes. This materially helps an agent construct valid arguments.

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 opens with a specific verb and resource: 'Create a hosted map style.' It distinguishes itself from sibling tools like get_style, set_palette, set_layer_paint, and list_style_layers by focusing on creation and by stating the generated style_id is meant for the set_* tools. No ambiguity remains about what this tool does.

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 gives clear context for when to use create_style: to lay down a base, merge a theme, or start from the default theme. It also routes the agent to list_style_layers for base details and to set_palette/set_layer_paint for follow-up modifications. It does not explicitly state when not to use create_style versus get_style, but the creation-oriented guidance is strong.

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?