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, official extension in the 2026-07-28 release candidate) to model the long-running operations cleanly.

This belongs in mcp-devkit-server rather than mcp-server because MTS is developer-tooling-shaped: tileset authoring, source uploads, recipe management, etc. — same category as the existing style management and token tools here. (Originally filed at mapbox/mcp-server#196, moved here.)

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 for devkit currently includes tilesets:read but not tilesets:write. Adding the publish/upload tools would need:

• A CFN change in hosted-mcp-server to add tilesets:write to the devkit's OAUTH_SCOPES_SUPPORTED
• Subject to the same kind of approval workflow as the existing tokens:write discussion (see adapter.ts comments about the conditions auth team has approved write scopes under)

Visual integration

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 established by the directions/isochrone/optimization app tools in mcp-server (mapbox/mcp-server#189-#195).

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; lives in mcp-server)
• 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)

[mattpodwysocki]

Duplicate of #115, which already covers the MTS tool surface. Added the MCP tasks framing as a comment on #115.