Context
Feedback from @jussi-salminen during QA of #199. Filing as a separate issue because it's a larger architectural change that shouldn't block the initial render_map_tool landing.
Problem
The current render_map_tool implementation manually implements the MCP Apps protocol inside a string of HTML — sending ui/initialize and other lifecycle events ourselves, with the protocol details baked into the HTML template.
Proposal
Adopt the App class from the ext-apps SDK so the protocol implementation lives in the SDK, not in our HTML string.
Benefits
- Protocol updates land via SDK version bumps; we get new features without hand-patching
- Less correctness risk — a single canonical implementation maintained by the ext-apps owners
- Reduces drift between our render output and other Mapbox apps using the same SDK
Cost
- Requires adding a Vite build step to the repo
- One-time refactor of the HTML template into an
App-based component
@jussi-salminen's read: the build-step cost is worth paying to avoid implementing the MCP Apps protocol ourselves.
Out of scope
The description prepend (#218) and the single-result rendering bug (#219) are filed separately.
Context
Feedback from @jussi-salminen during QA of #199. Filing as a separate issue because it's a larger architectural change that shouldn't block the initial
render_map_toollanding.Problem
The current
render_map_toolimplementation manually implements the MCP Apps protocol inside a string of HTML — sendingui/initializeand other lifecycle events ourselves, with the protocol details baked into the HTML template.Proposal
Adopt the
Appclass from theext-appsSDK so the protocol implementation lives in the SDK, not in our HTML string.Benefits
Cost
App-based component@jussi-salminen's read: the build-step cost is worth paying to avoid implementing the MCP Apps protocol ourselves.
Out of scope
The description prepend (#218) and the single-result rendering bug (#219) are filed separately.