Compose Preview Catalogs

ui_builder_set_reference

Attach the picture a design is being built against — a Figma frame, a screenshot of a shipped screen, a mock — as its reference overlay, or clear it. The same overlay the browser editor's Frame, density and reference panel shows, so a person opening the design sees what you attached. Kept beside the design and never part of it: no node holds it, no export sees it, the revision does not move. Send PNG, JPEG, WebP or SVG bytes in imageBase64. For a Figma frame, fetch the picture with your Figma tools (a screenshot of the node) and pass the frame's URL as sourceUrl; this host fetches nothing itself. State the export scale as density (2 for a Figma 2x export) or in the name (card@2x.png): without it a screen-shaped picture is read across the frame's width and anything else at the design's own density. The reply says what the picture is against the frame — size in dp, density, whether it is a screen or a region — and whether pixel comparison means anything. Marks drawn in the editor are kept; the alignment is reset, as a new picture in the editor does. A user-supplied image is stored on this host: say so, and attach it only with their permission.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	What the editor calls it. An `@2x` suffix declares the density.
`clear`	No	Remove the reference, its marks and pieces instead.
`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.
`density`	No	The picture's pixels per dp, e.g. 2 for a 2x export, 2.625 for a Pixel screenshot.
`designId`	Yes
`agentName`	No	Optional agent/client name shown to design viewers; self-reported.
`sourceUrl`	No	Where it came from, such as the Figma frame URL. Provenance only; never fetched.
`agentModel`	No	Optional current model name shown to design viewers; self-reported. Omit when unknown.
`imageBase64`	No	The picture, base64. PNG, JPEG, WebP or SVG; at most the host's reference size limit.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`facts`	No
`notes`	No
`schema`	Yes
`attached`	Yes
`designId`	Yes
`reference`	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 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 richly: the overlay is kept beside the design, no node holds it, no export sees it, and the revision does not move. It also discloses that alignment is reset while marks are kept, that the image is stored on this host (with a permission caveat), and that the reply reports size/density/region and whether pixel comparison is meaningful.

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?

Purpose and the clear/attach duality are front-loaded, and most sentences carry distinct information (effects on revision, storage, density semantics). It is dense and sprawling with long em-dash clauses, so it is slightly heavier than strictly necessary, but little is pure waste.

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?

For a 9-parameter mutation tool with no annotations, the description covers what changes, what is preserved, storage/permission implications, density interpretation, and reply contents. An output schema exists, yet the return summary is still useful context rather than filler.

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 already 89%, so the baseline is 3, but the description adds genuine meaning: the behavioral effect of density (without it a screen-shaped picture is read across the frame width, others at design density), the @2x name-suffix convention, and that sourceUrl is provenance-only and never fetched. It doesn't cover agentName/agentModel/token, which the schema handles.

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?

The description opens with a specific verb+resource: attaching (or clearing) a reference picture/overlay against a design. It clearly distinguishes the operation from siblings like ui_builder_put_asset or ui_builder_compare_reference by describing the overlay as an out-of-band artifact 'never part of' the design.

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 clear context for when to use it — attaching the picture a design is being built against — and describes the Figma-frame workflow (fetch with your own Figma tools, pass the URL as sourceUrl). It also states the permission precondition for user-supplied images. It stops short of naming an explicit alternative tool or when-not-to-use condition.

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.