Feature request: Mapbox Tiling Service (MTS) tools, leveraging the new MCP tasks extension

[mattpodwysocki]

Summary

Add tools for the Mapbox Tiling Service (MTS) — uploading source data, creating tileset recipes, publishing tileset jobs, and inspecting tileset/job status. Use the newly-blessed MCP tasks extension (SEP-1686, now an official extension in the 2026-07-28 release candidate) to model the long-running operations cleanly.

Why now

MTS has historically been an awkward fit for sync MCP tools. Publishing a tileset is a real async job — minutes to hours — that an agent currently can't represent without either:

1. Returning an unfinished job_id and putting all the polling logic in the prompt, or
2. Blocking the tool call for the duration (not viable on most MCP transports)

The new tasks extension fixes this directly: the server returns a task handle from tools/call, internally polls MTS, and the client/agent retrieves status via tasks/get / tasks/update / tasks/cancel. This is the canonical use case the extension was designed for.

Proposed tool surface (first pass)

Tool	Purpose	Sync or task?
list_tilesets_tool	List the user's tilesets	sync
get_tileset_tool	Get metadata for one tileset	sync
get_recipe_tool	Read the recipe for a tileset	sync
validate_recipe_tool	Validate an MTS recipe JSON	sync
upload_tileset_source_tool	Upload line-delimited GeoJSON to an MTS source	task (large uploads)
create_tileset_tool	Create a tileset with a recipe (no publish)	sync
publish_tileset_tool	Kick off a publish job	task (minutes–hours)
get_tileset_job_tool	Check job status by id	sync (useful even with tasks for legacy clients)
delete_tileset_tool	Delete a tileset	sync

The task-based ones return a task handle; the server's task implementation polls the underlying MTS job and resolves the task when MTS reports success or failed. For clients that don't advertise the tasks extension, the tool can fall back to returning the job ID directly with a note to use get_tileset_job_tool to poll manually.

Auth + scopes

MTS operations need tilesets:read and tilesets:write (plus tilesets:list for listing) on the access token. The hosted-mcp-server OAuth flow currently grants neither for the regular mcp-server deployment — the devkit deployment has tilesets:read but not write. Adding MTS support would likely need:

• A CFN change to expand OAUTH_SCOPES_SUPPORTED for whichever deployment(s) we ship the tools in
• Or: scope MTS tools to a separate deployment / require a self-provided sk.* token with the right scopes

Visual integration

Once tools exist, a natural follow-on is tileset_preview_app_tool — given a published tileset id, render an MCP App with the tileset loaded as a Mapbox GL JS layer with a sensible default style. Reuses the public-token resolver + MCP App resource pattern already in place for the existing *_app_tool family.

Out of scope (for an initial PR)

• Recipe authoring helpers / linting (lots of MTS-specific knowledge — would be its own follow-on)
• Real-time / Tilequery-against-tileset (different API surface)
• Bulk source upload via TUS (the MTS docs cover a simple POST path that's enough to start)

Open questions

• Should publish_tileset_tool always be a task, or only when the client advertises the extension? (Probably: task when supported, otherwise return job ID + note)
• For task progress, MTS reports a numeric progress field on jobs — worth surfacing through tasks/update if the tasks spec defines a progress hook (still being clarified in the experimental repo)

---

Filed after the discussion in our directions/isochrone/optimization MCP App PR series (#189–#195) — see those for the established app/task pattern this would extend.

[mattpodwysocki]

Moving this to mcp-devkit-server — MTS is developer-tooling-shaped (tileset authoring, source uploads, recipe management) and fits the same category as the style management and token tools already there. Tracking at mapbox/mcp-devkit-server#116.