MCP Apps 2.0.4 trims approval-card sprawl and repairs example state and dependencies
Released October 27, MCP Apps 2.0.4 leaves the library API unchanged while making the PDF example expose one interact tool by default, restoring the saved page when a conversation reopens, and refreshing dependencies with known audit findings.
Why it matters
An unchanged protocol can still produce a different host experience. Tool granularity controls approval-card volume, model choice space and batch failure semantics, while restored view state and dependency resolution affect whether an embedded generative interface works reliably after reopening and deployment.
A closer look
The PDF example folds thirteen action-specific app tools such as navigate, search and add_annotations into an interact tool aligned with the server contract: an action enum and flat parameters for one step, or a commands batch. Batch content[i] maps to commands[i], a failed slot starts with ERROR, and the batch carries no isError; split tools remain available through --split-app-tools. The map example adds get-screenshot with an optional 64–2048 pixel maximum dimension, defaulting to 1024. The PDF viewer now keeps the page stored in localStorage even when structuredContent no longer carries pageCount. Dependency updates cover solid-js/seroval, sharp/librsvg and other flagged transitives.
Who this is for
Host and server teams using MCP Apps PDF, map or other embedded app tools and designing approvals, batch results and session restoration
Original sources
Revisions & corrections (1)
— Official signed v2.0.4 release confirms example-tool consolidation, saved-page restoration and dependency remediation, while explicitly stating the library API is unchanged. Published as an implementation-boundary event with that limitation preserved.