Compose Preview Catalogs

ui_builder_merge_branch

Replay a branch's edits onto its parent's current revision through the same reducer every edit goes through — all or nothing. The reply reports every command: applied with the revision it landed at and any STALE_* notice of what it overwrote, or refused with the rejection code that stopped the run (nothing is then written), plus skippedOperationIds and how many were never tried. Run dryRun: true first: it reports merged: false and wouldMerge (true when every command would land) and writes nothing. Resolve a refusal by passing that command's id in skipOperationIds (skip an undo with what it undoes), or branch again from the parent. On success the branch is merged and its open siblings — branches forked at the same revision — are archived. Needs write access to the parent.

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.
`dryRun`	No	Replay and report without writing anything: the reply's merged is then false and wouldMerge carries the verdict. Defaults to false.
`branchId`	Yes
`agentName`	No	Optional agent/client name shown to design viewers; self-reported.
`agentModel`	No	Optional current model name shown to design viewers; self-reported. Omit when unknown.
`skipOperationIds`	No	Logged commands to leave out of the replay.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`dryRun`	Yes
`merged`	Yes
`schema`	Yes
`summary`	Yes
`branchId`	Yes
`commands`	Yes
`remaining`	Yes
`wouldMerge`	Yes
`forkRevision`	Yes
`parentDesignId`	Yes
`archivedSiblingIds`	No
`parentRevisionAfter`	Yes
`skippedOperationIds`	No
`parentRevisionBefore`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

changedInput schema / properties / dryRun / description

Previous value: -"Replay and report without writing anything. Defaults to false."New value: +"Replay and report without writing anything: the reply's merged is then false and wouldMerge carries the verdict. Defaults to false."

addedOutput schema / properties / wouldMerge
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "schema",
-  "branchId",
-  "parentDesignId",
-  "dryRun",
-  "merged",
-  "forkRevision",
-  "parentRevisionBefore",
-  "parentRevisionAfter",
-  "commands",
-  "remaining",
-  "summary"
-]New value: +[
+  "schema",
+  "branchId",
+  "parentDesignId",
+  "dryRun",
+  "merged",
+  "wouldMerge",
+  "forkRevision",
+  "parentRevisionBefore",
+  "parentRevisionAfter",
+  "commands",
+  "remaining",
+  "summary"
+]

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 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the atomic all-or-nothing semantics, the per-command applied/refused reply shape, STALE_* overwrite notices, that a refusal writes nothing, skippedOperationIds semantics, dryRun writing nothing, sibling branches being archived on success, and the required write access to the parent.

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 action and atomicity, then layers reply format, dry-run guidance, and recovery. Dense but nearly every clause earns its place; slightly heavy for a single paragraph.

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

Completeness5/5

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

Even though an output schema exists, the description explains the reply contract (applied/refused, STALE_*, skippedOperationIds, wouldMerge), preconditions like write access to the parent, and recovery paths. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 83%, so the schema already documents most parameters. The description adds genuine meaning beyond it, notably how skipOperationIds is used to resolve refusals (skip an undo with what it undoes) and what dryRun changes in the reply, which the schema states more terse-ly.

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+resource: replaying a branch's edits onto its parent's current revision through the reducer, all-or-nothing. This is clearly distinguishable from siblings like ui_builder_apply, ui_builder_fork_design, and ui_builder_archive_branch, which do different things to branch state.

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 strong procedural guidance: run dryRun:true first, resolve a refusal by passing the command id in skipOperationIds (or branch again from the parent). These are effectively when-to-use and recovery instructions. It stops short of naming alternative sibling tools for the same goal, so it is not a full 5.

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.