Compose Preview Catalogs

ui_builder_pick_branch

Ask the person which alternative (open branch) of a design to keep, and return their choice. In ChatGPT or Codex it is a thumbnail picker, one option per branch; with plain form elicitation it is a single-choice form; otherwise — and in chat tools like Slack — it returns a numbered list and one picture for YOU to post, and the person replies with a number. It never waits on a client that cannot answer. outcome is chosen (with branchId), declined, ask-in-chat or no-branches. Writes nothing: merge the chosen branch with ui_builder_merge_branch (dryRun first). 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.
`inline`	No	With a numbered list, also return its picture as an image block.
`message`	No	The question to put to the person. Defaults to asking which alternative to keep.
`designId`	Yes	The parent design.
`agentName`	No	Optional agent/client name shown to design viewers; self-reported.
`branchIds`	No	Only these open branches, 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
`via`	No
`image`	No
`schema`	Yes
`options`	No
`outcome`	Yes
`summary`	Yes
`branchId`	No
`designId`	Yes
`imageBase64`	No

Schema Changelog

Changes observed during successful MCP inspections.

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.3/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does so well: 'It never waits on a client that cannot answer' discloses graceful degradation, 'Writes nothing' plus 'Read access' declares the safety profile, and the four outcome values (chosen/declined/ask-in-chat/no-branches) tell the agent exactly what terminal states to handle.

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-loaded with the core action and its outcome, then the client-dependent rendering rules. The long middle clause packs several modalities into one sentence, which is dense but each clause carries distinct information; little is wasted.

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?

With an output schema present the description needn't explain return values, and it still enumerates the outcome states and the degradation behavior. Combined with 100% schema coverage this is nearly complete, though it could have noted prerequisites for branch availability (e.g., requiring open branches).

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 (token, branchIds, message, etc.), including the token-preference guidance. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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 ('Ask the person which alternative (open branch) of a design to keep, and return their choice'), plus the exact scope (open branches). An agent can distinguish it from siblings like ui_builder_merge_branch and ui_builder_await_decision without opening a schema.

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?

Explains the modality-dependent behavior (thumbnail picker in ChatGPT/Codex, single-choice form, numbered list elsewhere including Slack) and routes the agent to the follow-up step: 'merge the chosen branch with ui_builder_merge_branch (dryRun first)'. It gives clear context but doesn't explicitly state when to prefer this over ui_builder_await_decision or when this step is unnecessary.

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.