Skip to main content
Glama

Compose Preview Catalogs

by io.github.yschimke
OverviewDiscussionsAdmin

catalog_list_previews

List the Compose previews and published metadata of one hosted catalog. 'catalog' is required (ids from catalog_list_projects). Pass 'query' (a component name such as EdgeButton) to narrow by id or label; results are paged (100 by default, 'offset'/'limit' for more). This server holds published library catalogs only: previews of the project you are editing come from the local compose-preview-mcp server, not from here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoCase-insensitive substring of a preview id or label, such as a component name.
tokenNoA 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.
offsetNo
catalogYesA catalog id from catalog_list_projects.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Case-insensitive substring of a preview id or label, such as a component name.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "type": "object"
+}
  3. First observed

TDQS

A4.4/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 behavioral burden and does disclose meaningful traits: default page size (100), offset/limit for further pages, and the server's scope (published library catalogs only). It does not discuss permissions or whether access is gated, though the schema's 'token' parameter hints at a grant flow.

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?

Four sentences, front-loaded with the core action, and each sentence adds non-redundant information (required param source, filtering, paging, server boundary). No filler or restatement of the tool name.

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?

An output schema exists, so return values need not be described. Combined with the schema, the description supplies purpose, the required-parameter source, filtering, paging, and a clear server-scope exclusion — everything needed to invoke the tool correctly.

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 description coverage is 60%, and the description compensates for the undocumented parameters by explaining 'catalog' (required, sourced from catalog_list_projects), 'query' (component name narrowing by id or label), and 'offset'/'limit' paging semantics with the 100 default. Only 'token' is left to the schema, which documents it thoroughly.

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 description opens with a specific verb+resource: 'List the Compose previews and published metadata of one hosted catalog', scoping both the operation and the target. It does not explicitly name neighboring tools like catalog_get_preview_data, so sibling differentiation rests on the scope sentence rather than direct contrast. Clear and specific, but not maximally differentiated.

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?

It states where the required 'catalog' id comes from (catalog_list_projects), how to narrow results via 'query', and how pagination works. Critically, it gives an explicit when-not-to-use condition: previews of the project being edited come from the local compose-preview-mcp server, not this one.

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 toolsInspect
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.

Resources