Repository navigation
fix: static_map_image_tool large images work on the hosted server (fast follow to #257) - #258
Open
mattpodwysocki wants to merge 4 commits into
Open
mattpodwysocki wants to merge 4 commits into
mattpodwysocki wants to merge 4 commits into
Conversation
…ching inline-image ref Same hosted multi-task bug as directions_tool/isochrone_tool (#257): static_map_image_tool stashed large images in temporaryResourceManager (an in-process Map, 30-min TTL) behind a mapbox://temp/static-map-{id} ref, which a follow-up resources/read landing on a different ECS task couldn't see. That fix's JSON-in-ref approach doesn't transfer to images: base64- encoding raw bytes into a URI blows past the MCP SDK's own 1,000,000- character resource-URI cap almost immediately (a 750KB image alone encodes to 1,024,055 characters), and images needing this fallback can run into multiple megabytes. Instead, the new mapbox://inline-image/static-map?data=... ref encodes only the original request params (center, zoom, style, overlays - a few hundred bytes), and resources/read re-issues the Static Images API request at read time using those params and the reader's own resolved access token. The API is a deterministic renderer, so this reproduces the exact same image on demand instead of storing it - no size ceiling, works from any task. Extracted buildStaticMapRequestUrl.ts so the tool and the resource share the same URL-building logic. Verified with a real two-process integration test (fetch in one spawned server, kill it, re-fetch identical bytes from a second, independent process), and confirmed it fails against the old mapbox://temp/ code path before the fix and passes after.
…-stateless-followup Moves the large-image ref onto #257's mapbox://response/ scheme instead of a separate mapbox://inline-image/ one: static-map is a third ResponseTool and ToolResponseResource renders the image again on read. Drops InlineImageResource and inlineImageRef.ts, and ports the tests to SDK v2. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mattpodwysocki
changed the title
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #257 for the one tool it deferred:
static_map_image_tool.Same bug: images over the 700 KB inline limit were stored in
temporaryResourceManager(one process's memory, 30-minute TTL) behind amapbox://temp/static-map-{id}ref. On the hosted deployment (several stateless tasks, no session stickiness), a follow-upresources/readthat landed on another task found nothing.Fix
Large images now get a
mapbox://response/static-map?data=...ref, the same scheme #257 uses for largedirections_toolandisochrone_toolresponses. The ref carries the request's inputs (center, zoom, size, style, overlays), not the image, andToolResponseResourcerenders the image again with the reader's token and returns it as a blob. The Static Images API returns the same image for the same parameters.buildStaticMapRequestUrl.ts(same{ input, accessToken, apiEndpoint }shape asbuildDirectionsRequestUrl), shared by the tool and the resource.Updated after #257 and #296 merged: this first added its own
mapbox://inline-image/scheme andInlineImageResource. #257 landed with a genericmapbox://response/scheme that does the same thing, so static map is now a third tool on it instead, and the separate resource andinlineImageRef.tsare gone. Tests are ported to SDK v2.Testing
test/integration/hostedMultiTaskFollowupStaticMap.test.ts: fetches a 750 KB image in one spawned server process, kills it, and reads the ref from a second independent process over real MCP, checking the bytes match exactly.ToolResponseResourcetests: the static map ref renders the same request URL and returns the exact bytes with the right MIME type; bad inputs come back as text without making a request, and API errors come back as text.🤖 Generated with Claude Code