Compose Preview Catalogs

ui_builder_compare_branches

Put a design's alternatives side by side in one call: the parent's head and each open branch (or the branchIds named) rendered into ONE picture — a short-lived signed https link, numbered by caption — plus, per branch, what it changes against the parent at its fork (counts and a few lines, as ui_builder_diff_designs reports them). Show the person the picture and the numbered list, then ask with ui_builder_pick_branch; merge the choice with ui_builder_merge_branch. Writes nothing. Read access to the design.

Input Schema

TableJSON Schema

Name	Required	Description
`token`	No	A grant token from poll_access, when you cannot set the X-Compose-Preview-Token header yourself — an MCP client fixes its headers at connect time, so this is how a token approved during this session is used in it. Prefer the header where you control it.
`device`	No	Render every picture at this device instead of each design's own size: a preset id (phone_small, phone, phone_landscape, foldable_folded, foldable_unfolded, tablet_portrait, tablet_landscape, wear_small_round, wear_large_round, wear_square, tv_1080p, widget_small_round, widget_small_squircle, widget_small_rectangular, widget_large_round, widget_large_squircle, widget_large_rectangular) or {"widthDp","heightDp"}. Nothing is saved.
`inline`	No	Also return the picture as an image block. Defaults to false: the signed link.
`designId`	Yes	The parent design.
`agentName`	No	Optional agent/client name shown to design viewers; self-reported.
`branchIds`	No	Only these branches of the design, in this order. Defaults to every open branch, oldest first.
`agentModel`	No	Optional current model name shown to design viewers; self-reported. Omit when unknown.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	No
`image`	No
`device`	No
`parent`	No
`schema`	Yes
`columns`	No
`summary`	Yes
`branches`	No
`designId`	Yes
`imageBase64`	No
`parentRevision`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / device / description

Previous value: -"Render every picture at this device instead of each design's own size: a preset id (phone_small, phone, phone_landscape, foldable_folded, foldable_unfolded, tablet_portrait, tablet_landscape, wear_small_round, wear_large_round, wear_square, tv_1080p) or {\"widthDp\",\"heightDp\"}. Nothing is saved."New value: +"Render every picture at this device instead of each design's own size: a preset id (phone_small, phone, phone_landscape, foldable_folded, foldable_unfolded, tablet_portrait, tablet_landscape, wear_small_round, wear_large_round, wear_square, tv_1080p, widget_small_round, widget_small_squircle, widget_small_rectangular, widget_large_round, widget_large_squircle, widget_large_rectangular) or {\"widthDp\",\"heightDp\"}. Nothing is saved."

Changed2 schema fields changedOct 4, 2026

addedInput schema / properties / agentModel

Added value: +{
+  "description": "Optional current model name shown to design viewers; self-reported. Omit when unknown.",
+  "maxLength": 80,
+  "type": "string"
+}

addedInput schema / properties / agentName

Added value: +{
+  "description": "Optional agent/client name shown to design viewers; self-reported.",
+  "maxLength": 80,
+  "type": "string"
+}

AddedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it does disclose meaningful traits: 'Writes nothing. Read access to the design,' plus that the link is short-lived and signed, and that the render is 'nothing saved.' Missing only peripheral details like rate limits or expiry duration, but the safety and side-effect profile is clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core behavior and keeps the workflow guidance in a compact two-sentence tail. The dense em-dash phrasing packs a lot in, though the rendering/signed-link details are somewhat crowded, keeping it just short of maximally clean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete enough for a read-only comparison tool: the side effects, output form (link vs inline image), and post-comparison workflow are all covered, and an output schema exists so return values need not be restated. Only a little more on when to prefer this over the related diff/matrix tools would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all seven parameters in detail. The description echoes branchIds ('or the branchIds named') and the diff format, but adds no syntax or default nuance beyond the schema. Baseline 3 is appropriate when the structured fields do the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — putting a design's alternatives side by side in one call — and concretely describes the output: the parent's head plus each open branch (or named branchIds) rendered into one signed picture, with a per-branch diff. This is distinguishable from siblings like ui_builder_diff_designs, ui_builder_render_design_matrix, and ui_builder_list_branches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear workflow: show the picture and numbered list, then ask with ui_builder_pick_branch and merge with ui_builder_merge_branch, which tells the agent where this fits in a decision sequence. It does not, however, explicitly state when to use this versus ui_builder_diff_designs or ui_builder_render_design_matrix, so the routing is implied rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Compose Preview Catalogs tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.