Compose Preview Catalogs

ui_builder_find_design_for_pr

From a pull request back to the design(s) it implements: every design you can read whose implementation record or links name pr, with the implementation status and revision. Then call ui_builder_implementation_status for what the design expects.

Input Schema

TableJSON Schema

Name	Required	Description
`pr`	Yes	The pull request URL, exactly as recorded.
`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.
`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
`pr`	Yes
`schema`	Yes
`designs`	Yes
`summary`	Yes

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.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: results are scoped to designs the caller 'can read' (implying permission-filtered, read-only access) and each result carries implementation status and revision. It omits pagination/rate-limit behavior and does not state the read-only guarantee as plainly as an annotation would.

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?

Two sentences, zero filler, front-loaded with the reverse-lookup purpose followed immediately by the routing hint. Every clause earns its place.

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?

An output schema exists, so return values need not be explained, and the description still summarizes the payload (status and revision). For a read-only lookup tool this is nearly complete, though auth/permission nuances around the token are only implied.

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 100%, so the baseline is 3, but the description adds genuine meaning about `pr`: it is matched against the design's implementation record or links, not treated as an opaque id. The token/agentName parameters are left to the schema, which documents them thoroughly.

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 reverse-lookup verb and resource: 'From a pull request back to the design(s) it implements.' It names the exact match criterion (implementation record or links naming `pr`) and explicitly contrasts itself with the sibling ui_builder_implementation_status, so an agent can distinguish it without opening any 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 context — use this to go from PR to design, then follow with ui_builder_implementation_status for what the design expects. It names the follow-up sibling and its condition, but offers no explicit when-not guidance or alternative reverse-lookup paths.

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.