feat: add Mapbox Tiling Service (MTS) tools

[mattpodwysocki]

Summary

Add MTS tools so agents can take raw data (GeoJSON, CSV, etc.) all the way through to a published tileset that can be referenced in a style layer — entirely within the devkit.

Why DevKit

MTS is a data-pipeline / developer workflow operation, not a runtime geospatial computation. It belongs alongside the existing style and token management tools rather than in the mainline geo-computation MCP server.

Proposed Tools

Tool	MTS / Uploads API endpoint	Description
upload_tileset_source_tool	POST /tilesets/v1/sources/{username}/{id}	Upload a GeoJSON or CSV file as a tileset source
create_tileset_tool	POST /tilesets/v1/{tileset_id}	Create a tileset with a recipe
publish_tileset_tool	POST /tilesets/v1/{tileset_id}/publish	Kick off the tiling job
get_tileset_status_tool	GET /tilesets/v1/{tileset_id}/jobs/{job_id}	Poll job status (queued / processing / success / failed)
list_tilesets_tool	GET /tilesets/v1/{username}	List tilesets for the authenticated user

Agent Workflow This Enables

1. upload_tileset_source_tool  — POST GeoJSON/CSV → get source_id
2. create_tileset_tool         — define tileset + recipe referencing source_id
3. publish_tileset_tool        — kick off tiling job → get job_id
4. get_tileset_status_tool     — poll until status === "success"
5. update_style_tool (exists)  — add a layer referencing the new tileset

This gives an agent a complete "I have data, build me a map" loop without leaving the devkit.

Token Scopes Required

• tilesets:write — create, update, publish tilesets
• tilesets:read — list, status
• tilesets:list — list tilesets

References

• Mapbox Tiling Service API docs
• Uploads API docs

[mattpodwysocki]

Adding context from a follow-up discussion: the new MCP tasks extension (SEP-1686, now an official extension in the 2026-07-28 release candidate) is a near-perfect fit for the long-running operations in this list:

• publish_tileset_tool — tiling jobs are minutes to hours. Server returns a task handle from tools/call, the server's task implementation polls MTS internally, and the client/agent retrieves status via tasks/get / tasks/update / tasks/cancel instead of having to bake polling logic into the prompt.
• upload_tileset_source_tool — large uploads benefit from the same shape.

For clients that don't advertise the tasks extension, the tools can fall back to the current "return job ID, let the agent poll get_tileset_status_tool" pattern. So tasks support is purely additive.

This pairs with the parallel issue at mapbox/mcp-server#197 which proposes tasks for a lighter use case (streaming results from ground_location_tool). That one's a good pilot — gentle failure mode — and once the pattern's proven there, MTS is the bigger payoff.

[mattpodwysocki]

Updated Phase 2 plan (reflecting the original MTS MCP design doc)

After re-reading the prior-art design doc, the Phase 2 plan I sketched earlier needed three corrections:

1. Drop `upload_tileset_source_tool`. The original doc explicitly excludes this from MCP — source files can be up to 50 GB, and the hosted MCP server shouldn't be in that traffic path. Instead, the agent should guide the user to upload locally (e.g. via the Tilesets CLI or a direct `POST` to the sources endpoint from their own machine). The MCP server takes over once a `source_id` exists.

2. Add a recipe-generation tool (the harder one). The original doc treats recipe authoring — not just validation — as the core unlock for "I have GeoJSON, build me a tileset" being a one-prompt workflow. References mts-recipe-generator for the inference logic. This is the most ambitious tool in Phase 2 and probably worth its own PR even within Phase 2.

3. Combine create + publish into one tool. The original doc lists them as one ("Create tileset tool: accepts tile source id, validated recipe → generates the tileset"). Splitting them adds steps without giving the agent meaningful control.

Revised Phase 2 tool list

Tool	API(s)	Sync or task?
`validate_recipe_tool`	`PUT /tilesets/v1/validateRecipe`	sync
`generate_tileset_recipe_tool`	(server-side inference, no MTS call)	sync
`create_and_publish_tileset_tool`	`POST /tilesets/v1/{tileset_id}` + `POST /publish`	task (publish is minutes–hours)
`delete_tileset_tool`	`DELETE /tilesets/v1/{tileset_id}`	sync

Tasks-extension impact on the original design

The original doc's "Tileset job monitor" tool was designed because publish is async — the agent has to poll. With the MCP tasks extension (official as of 2026-07-28 RC), the monitor pattern is partially redundant for jobs kicked off via MCP — the task handle is the monitor. `get_tileset_status_tool` (already in Phase 1 #117) remains useful for inspecting jobs the agent didn't start (dashboard, CLI, prior session).

Open question on Phase 1

get_tileset_tool (in #117) hits GET /tilesets/v1/{tileset_id} which is from the legacy Tilesets API, not MTS proper, and isn't in the original doc's tool list. I included it because it's a useful smoke-test for "does this tileset exist + what are its bounds," but reviewers might prefer to drop it to stay strictly within the MTS surface. Flagged on the PR.

Dependencies

• tilesets:write scope on devkit's OAuth (hosted-mcp-server CFN PR) — required for create/publish/delete tools
• Tasks extension support in @modelcontextprotocol/sdk (currently experimental) — required for the long-running publish to be a proper task; can fall back to "return job_id, poll with get_tileset_status_tool" if the SDK isn't ready