Compose Preview Catalogs

ui_builder_put_asset

Put a picture behind an assetKey, so an asset/image node naming that key draws it instead of a placeholder. Send the PNG, JPEG, GIF or WebP bytes base64-encoded in imageBase64; the server stores them by content digest and pins {mediaType, contentDigest, source: uploaded} into the design's assets map under the key. This moves the design's revision, and the reply carries the new one to quote as baseRevision. Idempotent by content — the same bytes under the same key change nothing. Put the picture first, then insert the asset/image node with ui_builder_apply: the reducer refuses a key that is neither pinned in the design nor in the catalog's own registry. A pinned key whose bytes a lane cannot show renders as a visible placeholder, never as an error.

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.
`assetKey`	Yes	1 to 64 characters of letters, digits, '.', '_' or '-'; what the node's assetKey property names.
`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.
`imageBase64`	Yes	The image bytes, base64. At most 1 MiB decoded.

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.9/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 storage by content digest, the exact map entry pinned ({mediaType, contentDigest, source: uploaded}), that the design revision advances and the new one returns as baseRevision, idempotency by content, and the failure/placeholder semantics. This is unusually rich behavioral disclosure.

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

Conciseness5/5

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

Front-loaded with purpose and effect, then mechanism, then the sequencing requirement, then edge-case behavior. Every sentence carries distinct information with no filler, despite the density.

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 mutation tool with an output schema present, the description supplies everything an agent needs: input format, side effects on the revision, idempotency, and the coordination constraint with ui_builder_apply. Return values are covered by the output schema and only the salient baseRevision is restated.

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 baseline is 3, but the description adds meaning beyond it: accepted formats (PNG/JPEG/GIF/WebP), that bytes are base64-encoded, and how assetKey ties to the node's assetKey property. It stops short of documenting the optional token/agentName/agentModel parameters, which the schema already 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?

States a specific verb (put), resource (a picture behind an assetKey), and the downstream effect (an asset/image node draws it instead of a placeholder). It also names the sibling it cooperates with (ui_builder_apply), so an agent can place it in the workflow without opening other schemas.

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

Usage Guidelines5/5

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

Explicitly prescribes ordering ('Put the picture first, then insert the asset/image node with ui_builder_apply') and gives the precondition that makes the call succeed: the reducer refuses a key neither pinned in the design nor in the catalog registry. When-to-use is fully covered for this step.

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.