Compose Preview Catalogs

catalog_render_preview

Render one preview. Like local compose-ai-tools, the default semantics observation is token-frugal; request observe=png for pixels, observe=svg for the compose/figma-svg vector export as SVG source, or observe=scroll-png / observe=scroll-svg for the full-page capture of a scrollable screen rather than the viewport crop. Overrides, other observations and fresh renders require live grant scope; without it, a call with no overrides returns the published snapshot (as resources/read does).

Input Schema

TableJSON Schema

Name	Required	Description
`uri`	No
`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.
`catalog`	No
`observe`	No
`overrides`	No
`previewId`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`imageUrl`	No	Short-lived signed https URL of the rendered PNG, on a host with a public origin.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "imageUrl": {
+      "description": "Short-lived signed https URL of the rendered PNG, on a host with a public origin.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 30, 2026

TDQS

A3.7/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 does disclose key behaviors: the default is a token-frugal semantics observation, overrides/other observations/fresh renders require live grant scope, and without scope a no-override call returns the published snapshot. Auth/permission gating is surfaced, which is valuable, though other traits (rate limits, side effects) are unstated.

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, but the middle passage is dense and awkwardly phrased with unexplained jargon ('Like local compose-ai-tools'), which costs clarity. It is reasonably sized but not tightly written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 described. For a 6-parameter tool with 17% schema coverage and no annotations, the description covers observation modes and grant-scope behavior but leaves the token parameter and the uri/previewId selection logic unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17%, so the description must compensate. It explains the observe enum values (png, svg, scroll-png, scroll-svg, and semantics as default) and that overrides require grant scope, but omits 'hash', the token parameter, and the uri-vs-catalog+previewId selection. Partial compensation only.

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 opening 'Render one preview' gives a clear verb+resource, and the description distinguishes observation modes (semantics default vs png/svg/scroll variants). However, the purpose is muddied by jargon like 'compose-ai-tools' and 'live grant scope' that an agent without prior context must infer.

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?

Explicit conditional guidance is given for observe values ('request observe=png for pixels, observe=svg for ... SVG source, or observe=scroll-png/scroll-svg for full-page capture'). It also states the grant-scope precondition. It lacks routing against siblings like catalog_get_preview_data or catalog_render_matrix, keeping it below 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.