Compose Preview Catalogs

ui_builder_guidelines_prompt

Read the exact prompt a design-guidelines model is given for a design, before anybody spends a key on it: the rules for the design's platform (Android design guidance from developer.android.com, each with its source), the fixed system prompt, the user message with the design tree and Compose source, the JSON schema the verdicts must follow, a sentence on where each part comes from, and the pictures as image blocks — a Wear screen on its device (and unrolled when it scrolls), a Wear widget in the Samsung and Pixel Watch containers, a phone or tablet design at phone and tablet size. It spends no key. Judge it with your own model, then record the verdicts with ui_builder_record_guidelines so the editor and other agents see them. rendered: false leaves out the pictures and source (and the visual rules), and needs only read access; otherwise it needs the ui-builder-export capability.

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.
`designId`	Yes
`rendered`	No	Attach native renders and the Compose source. Defaults to true.
`revision`	No	A past revision. Omit for the current one.
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rules`	Yes
`schema`	Yes
`designId`	No
`pictures`	No
`platform`	Yes
`revision`	Yes
`userText`	Yes
`provenance`	No
`systemPrompt`	Yes
`responseSchema`	Yes
`sourceAttached`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 10, 2026
- addedOutput schema / properties / pictures / items / properties / coversWholeContent
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
```
- addedOutput schema / properties / rules / properties / asked / items / properties / aliases
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

Changed2 schema fields changedOct 9, 2026

addedOutput schema / properties / rules / properties / asked / items / properties / profiles
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

changedOutput schema / properties / rules / properties / asked / items / required

Previous value: -[
-  "id",
-  "platforms",
-  "kind",
-  "severity",
-  "guidance",
-  "check",
-  "source"
-]New value: +[
+  "id",
+  "kind",
+  "severity",
+  "guidance",
+  "check",
+  "source"
+]

Changed1 schema field changedOct 8, 2026
- addedOutput schema / properties / rules / properties / asked / items / properties / surfaces
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
AddedOct 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and mostly delivers: it states the call spends no key (cost), spells out access levels ('needs only read access' vs the 'ui-builder-export capability'), and discloses what is returned. It omits rate limits and any failure modes, keeping it out of the top band.

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

Conciseness3/5

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

The purpose is front-loaded, which is good, but the body is a single dense run-on with heavy em-dash nesting and a long parenthetical enumerating every render variant. Much of that enumeration is useful, yet the block is oversized for the task and would benefit from structure.

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?

For a read tool with an output schema (so return shape need not be re-explained), it covers cost, permissions, the rendered/no-rendered branch, and the follow-up recording step. The main gap is that the non-`rendered` parameters (token, revision, agentName, agentModel) get no narrative treatment, but the schema handles them.

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 83%, so baseline is 3. The description adds real meaning the schema lacks by explaining the consequence of `rendered: false` — it drops the pictures and Compose source (and the visual rules) and lowers the permission requirement. It says nothing extra about token, revision, or the self-reported agent fields, which the schema already documents.

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 precise verb and resource: 'Read the exact prompt a design-guidelines model is given for a design', and enumerates the payload (platform rules, system prompt, user message, JSON schema, images). It explicitly distinguishes itself from the sibling that consumes its output, ui_builder_record_guidelines, so an agent can route between inspecting and recording without opening either 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?

Gives clear workflow context: use it to inspect the prompt 'before anybody spends a key on it', judge it with your own model, then persist verdicts via ui_builder_record_guidelines. It also branches on the `rendered: false` case. It stops short of an explicit when-not / alternative-tool exclusion, so it is strong but not exhaustive.

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.