Compose Preview Catalogs

ui_builder_apply

Apply design mutations — insertNode, setProperty, deleteNode, moveNode and the rest of DesignMutationV1 — as one operation. baseRevision is the revision you read; the outcome reports conflicts or rejected edits. This is how an agent adds a scaffold, fills its slots and sets modifiers. Use setStateVariable with name and declaration to add or edit state, removeStateVariable with name to remove unused state, and setEventBinding with nodeId, event and an ordered actions array to edit behavior. An empty actions array removes the event handler. removeNodeProperty (or a setProperty whose value is {"type":"null"}) unsets the property — the way back after trying one — and is refused, naming the node and the field, when the catalog requires it. When somebody has commented on the design and you have not acknowledged it, the outcome carries a comments block naming the threads waiting on you; read it, because it is somebody talking about what you are editing.

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.
`clientId`	No
`designId`	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.
`operations`	Yes	DesignMutationV1 objects. State example: {"type":"setStateVariable","name":"expanded","declaration":{"type":"value","valueType":"bool","initialValue":false,"nullable":false,"persistence":"preview"}}. Event example: {"type":"setEventBinding","nodeId":"button","event":"click","actions":[{"type":"toggle","variable":"expanded"}]}. Declare state before binding it in the batch.
`operationId`	Yes	Your id for this operation; makes a retry idempotent.
`baseRevision`	Yes	The revision these mutations were written against.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

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"
+}

Changed1 schema field changedSep 30, 2026
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "type": "object"
+}
```
First observedSep 30, 2026

TDQS

A4.3/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 behavioral burden and does so richly: it discloses conflict/rejection reporting against baseRevision, the refusal semantics of removeNodeProperty (refused, naming node and field, when the catalog requires it), that an empty actions array removes a handler, and that a comments block surfaces unacknowledged threads. These are exactly the mutation-safety and concurrency facts an agent needs and cannot get from structured fields.

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?

It is a long description, but the tool is genuinely complex and the length is mostly earned, with the core purpose front-loaded in the first sentence. A few sentences are verbose or editorial ('read it, because it is somebody talking about what you are editing'), which keeps it from a 5.

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?

An output schema exists, so return values need not be explained, and the description covers the behavioral gaps that matter: conflicts, rejected edits, unset/refusal rules, and the comments block. For an 8-parameter batched-mutation tool with no annotations, this is complete enough to call correctly.

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?

At 75% schema coverage the schema already documents most parameters, but the description adds real meaning beyond it: baseRevision as 'the revision you read', the shape of setStateVariable's name/declaration, and setEventBinding's nodeId/event/ordered actions. It clarifies the ordering constraint (declare state before binding it), which the schema does not state. Slightly short of 5 because several operation variants are only gestured at.

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

Purpose4/5

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

The description states a specific verb and resource: it applies DesignMutationV1 mutations (insertNode, setProperty, deleteNode, moveNode) as one batched operation. That is unambiguous about what the tool does. It does not, however, explicitly differentiate itself from sibling mutators like ui_builder_replace_design_document or the branch/merge tools, so it lands at 4 rather than 5.

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?

It gives concrete usage context — 'This is how an agent adds a scaffold, fills its slots and sets modifiers' — and routes specific intents to specific mutation types (setStateVariable for state, setEventBinding for behavior, removeNodeProperty to unset). This is strong when-to-use guidance, but there is no explicit when-not-to-use or named alternative tool, so it stops short of 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.