Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Browse, inspect and render Jetpack Compose Material 3 and Wear component catalogs.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
X-Compose-Preview-TokenLos valores marcados como secretos son llaves de tu cuenta. Nunca los compartas ni los pegues en un chat.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.
Ejecuta esto en tu terminal
claude mcp add --transport http compose-preview https://preview.coo.ee/mcp --header 'X-Compose-Preview-Token: your-value'Completa los valores vacíos antes de ejecutarlo.
Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"compose-preview": {
"url": "https://preview.coo.ee/mcp",
"headers": {
"X-Compose-Preview-Token": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"compose-preview": {
"type": "http",
"url": "https://preview.coo.ee/mcp",
"headers": {
"X-Compose-Preview-Token": "your-value"
}
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
X-Compose-Preview-Token secreto HTTP headerEsta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Nombres y descripciones de las herramientas tal como los informó el servidor el 6 nov 2026. Los escribió el creador, no nosotros; los mostramos como texto sin formato.
request_accessAsk a human for access to this server. Returns an approveUrl and a userCode: show BOTH to the person you are working with, ask them to open the link and check that the code on the page matches, then call poll_access. When the client supports URL elicitation, call poll_access with
poll_accessCollect the outcome of a request_access, proving possession of its deviceSecret. It HOLDS THE CALL OPEN and answers the moment the human decides — one call instead of a dozen, since each poll here costs a whole round trip through you. It waits 8 seconds by default; pass waitSecon
statusReport readiness, the aggregate catalog set, and which host this is: `origin`, the canonical origin designs here are homed at, and `originAliases`, other hostnames that reach this same server.
catalog_list_projectsList every remote catalog with its stable id and preview count. Call this first: catalog_list_previews and catalog_list_data_products take one of these ids as 'catalog'.
catalog_libraryOpen the hosted preview catalog browser app. With no arguments it lists every catalog with its preview count only; pass projectId to list one catalog's previews. To find previews without the app, call catalog_list_projects, then catalog_list_previews with a catalog id. Also opens
ui_builder_openOpen the UI Builder's design list: pick a design to see it as the editor draws it. Takes no arguments. Also opens from the ChatGPT/Codex sidebar, and a deep link to /design/ opens one design.
catalog_list_previewsList 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
catalog_render_previewRender 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 scrolla
catalog_render_matrixRender one preview across the cross-product of the given override axes in a single call, returning a hash/size observation per cell (observe=png adds the pixels). Prefer this over a catalog_render_preview per combination: the cells share one catalog lease and are reported togethe
catalog_list_devicesList the `@Preview(device = ...)` ids this server's render lane recognises, with each one's dp size and density. The `device` override takes one of these ids; an unrecognised name renders the default frame rather than failing, so check here instead of guessing.
catalog_diff_semanticsCompare two previews' semantics by testTag: which tags are only in one side, which moved, and which changed occupancy count. Identity is the authored testTag, not a positional ref, so a tag that stops resolving is reported rather than silently retargeted at different pixels. Requ
catalog_history_listThe render timeline for one preview: which versions of its rendered bytes exist, when each appeared, and whether the preview is unstable (re-renders differently on every publish) rather than genuinely changing. Where this server holds the timeline it is returned inline; where the
catalog_history_diffCompare two of a preview's recorded renders. Defaults to the two newest — did the last publish move this preview? A metadata comparison: the timeline's versions are already collapsed distinct renders, so whether the bytes changed is answered without fetching either image. Reports
catalog_history_readFetch one historical render's pixels through this server, by `commit` or `blob` (a prefix is enough). Use when an agent cannot reach the delivery branch itself, or wants the bytes rather than the timeline.
ui_builder_list_catalogsList the component catalogs a UI-builder design can pin to. Start here: a design's `catalogPin` must name a revision this server actually serves, and each catalog's `catalogPin` here is exactly that. By default a summary of what authoring needs, a few KB rather than the whole cap
ui_builder_search_componentsFind catalog components by id, display name, Compose symbol, role or trait, e.g. `TextField`, `text field`, `OutlinedTextField`, `Button`, `Card`. Case, spaces, hyphens, underscores, slashes and camelCase are ignored, and the components the query names come first: an exact name,
ui_builder_list_designsList the UI-builder designs on this server, newest first, with the cursor to continue.
ui_builder_get_designRead one design: its whole document — nodes, slots, properties, modifiers, state variables and catalog pin — plus the revision to quote as `baseRevision` when editing it. The catalog the design pins is left out unless `includeCatalog` is true: it is the same for every design on t
ui_builder_preview_catalog_recoveryDry-run recovery of a design whose stored catalog pin no longer resolves. The server selects the exact currently served pin for the same catalog system and returns a CatalogUpgradePreviewV1 with changes, issues and the hashes required by a later `upgradeCatalog` mutation through
ui_builder_await_designWait for somebody else to change a design and return what they changed, rather than asking again whether they have. Returns the moment a designer in the browser or another agent commits an edit, as the same update frame the browser's own live socket receives; returns a `timedOut`
ui_builder_create_designCreate a design, either from a whole `document` you supply or by copying an existing design named by `fromDesignId`. Copying is usually right: a document's `catalogPin` must match a catalog revision this server serves, and a copy carries one that does. A `document` whose `home` i
ui_builder_applyApply design mutations — insertNode, setProperty, deleteNode, moveNode and the rest of DesignMutationV1 — as one operation. `baseRevision` is the revision you read; the outcome reports conflicts or rejected edits. This is how an agent adds a scaffold, fills its slots and sets mod
ui_builder_move_design_homeMove a design's canonical home between this server and a repository checkout. This changes real authoritative state: quote the exact `baseRevision` and current `sourceHome` from ui_builder_get_design, provide a stable `operationId`, and name the new `targetHome`. The old server r
ui_builder_replace_design_documentReplace one stored design from a complete DesignDocumentV1 copy — the authoritative save-back and re-import operation. The document must name the same design and the same canonical home you read from ui_builder_get_design; `baseRevision` must still be current. The runtime validat
ui_builder_exportExport a design. `compose` returns the Kotlin the generator writes, or — when the design holds something it cannot express — diagnostics naming each reason. This is the same gate the browser's code pane shows, so an agent and a designer get the same answer about the same design.
ui_builder_validateCheck a design without saving it: a whole `document`, a stored design by `designId`, or `operations` against a stored design exactly as ui_builder_apply would apply them. Runs the same checks the real call does — document shape, catalog pin, the catalog's own validation, the muta
ui_builder_put_assetPut 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} in
ui_builder_design_accessRead who can open a design: its owner, and every actor it has been shared with, each with the role and the actions that grant carries. Only the owner may ask — this is the answer to "who else is in here" and to "what is the id I must name when sharing".
ui_builder_share_designShare a design with somebody else, or take that sharing back. `actorId` is the other party's actor id as this server spells it — `github: ` for a signed-in person, `operator` for the token holder, `agent: ` for another agent's grant; ui_builder_design_access lists the ones a desi
ui_builder_get_linksRead what a design is **for**: the `issue` it was drawn for, the `reference` frame in the design tool it reproduces, the `pr` that implemented it, the `thread` it is being discussed in, and the `previous` design it continues. Start a session on somebody else's design here — it is
ui_builder_set_linksSay what a design is for. **Replaces the whole record**: send every link you want kept, and omit one to clear it — so read ui_builder_get_links first if you are adding to what is already there. `issue`, `reference`, `pr` and `thread` are absolute http or https URLs, at most 2 KB
ui_builder_rename_designGive a design a new title. The title is the one thing about a design nothing else could change: it is set at creation, shown in every listing and the editor, and not part of any mutation. Anybody who may write the design may rename it. The revision does not move — a title is not
ui_builder_delete_designDelete a design: it moves to the trash with its history, access list, overlay and discussion, and is gone from every listing and tool until ui_builder_restore_design brings it back, which works until `restorableUntilEpochMillis` in the reply (a day). After that it is purged for g
ui_builder_list_trashThe designs in the trash that you could restore — ones you deleted, or ones you own — most recently deleted first, each with who deleted it and its `restorableUntilEpochMillis`. Use it to undo a ui_builder_delete_design you regret, or to check what a cleanup removed. Takes no arg
ui_builder_restore_designBring a deleted design back out of the trash exactly as it was: the same revision, history, access list, overlay and discussion. Allowed to whoever could have deleted it, until its `restorableUntilEpochMillis`; after that it is not found. The reply is the design's listing entry.
ui_builder_list_commentsRead the discussion on a design: every thread, where each is pinned — a markup stroke, a design node, or a point on the frame — whether it is resolved, and every reply under it. `sequence` rises on each change and is the cursor to quote to ui_builder_await_comments. Comments are
ui_builder_post_commentSay something on a design — a reply into `threadId`, or a new thread when it is omitted. Pin a new thread with `markId` (a stroke on the reference overlay), `nodeId` (a node in the design), or `x`/`y` in frame fractions, so the person reading it can see what you meant. The commen
ui_builder_resolve_comment_threadClose a comment thread once it is answered, or reopen one by passing `resolved: false`. The resolution is attributed to you and is reversible.
ui_builder_acknowledge_commentSay that you have read a comment thread — which is **not** the same as resolving it. Resolving claims the question is settled; acknowledging claims only that you have seen it, which is the honest thing to say while you are still working on what it asked for. Omit `threadId` to ac
ui_builder_react_to_commentReact to one comment with an emoji, or take the reaction back with `on: false`. The lightest thing you can say: 👀 on a comment you have just picked up, 👍 on a fix somebody made, where a reply would be noise in a thread a person has to read. `commentId` is the `id` of a comment
ui_builder_await_commentsWait for the discussion to move past `afterSequence` and return it, rather than polling for it. Returns as soon as anybody — a designer in the browser or another agent — posts, resolves or deletes; returns a `timedOut` reply if nothing happens within `waitSeconds`, which you answ
ui_builder_render_nativeCompile a design and render it with real Compose on this host, rather than in the browser's Wasm canvas — the way to see what a design looks like on Android. Returns the first frame, the token the live frame stream is opened with, and the design node ids the render is tagged with
ui_builder_viewSee a design the way a person in the editor sees it: a PNG of the canvas with the overlays drawn on — the `selection` outline, the `reference` picture when one is attached, the discussion's `comments` pins, and the layout `bounds` — and beside it JSON with the revision, each visi
ui_builder_check_designCheck a design before you show it to anybody — one call instead of validate, view and an accessibility pass. Runs `schema` (document shape), `catalog` (the pinned catalog's validation, the mutation reducer and the Compose export gate — what ui_builder_validate runs) and `a11y`: c
ui_builder_guidelines_promptRead 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
ui_builder_get_guidelinesRead a design's latest design-guidelines result, whoever ran it — a person in the editor on their own key, ui_builder_check_design on this host's key, or an agent that recorded verdicts with ui_builder_record_guidelines. Returns the record (model, revision, rules asked, verdicts,
ui_builder_record_guidelinesRecord your own model's verdicts on ui_builder_guidelines_prompt as the design's latest design-guidelines result, so the editor's Issues panel and other agents show them. Pass the `revision` and rule ids the prompt asked (`rules.asked[].id`), and one verdict per rule you answered
ui_builder_render_design_matrixSee one design on several devices in ONE picture: a contact sheet with a captioned cell per device × theme × font scale, plus each cell's device, size and box on the sheet. Nothing is saved — the design's environment is swapped on a scratch copy for each cell. Name `devices` by p
ui_builder_record_decisionRecord a review verdict — `approve` or `reject` — on one revision of a design, with an optional note. Kept beside the design, like comments: it never moves the revision. Recorded as an agent's decision, so a person waiting with ui_builder_await_decision's default `from: "human"`
ui_builder_await_decisionWait for somebody to approve or reject a design, rather than asking again whether they have. Returns as soon as a decision lands after `afterSequence` — by default only a person's (`from: "human"`), on any revision unless you name one — or a `timedOut` reply after `waitSeconds`.
ui_builder_set_implementationRecord the pull request that implements a design: its URL, its `status` (draft, open, merged, closed), the design `revision` it implements, and — once you have compared the PR's rendered previews with the design — `previewMatch` {status: match|mismatch|unknown, evidence: a URL to
ui_builder_implementation_statusEverything the code side needs to implement a design, in one call: the revision, its links (issue, reference, PR, thread), the implementation PR with its status and whether its previews were found to match, the latest verdict on this revision, and the Compose export with the gene
ui_builder_find_design_for_prFrom 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.
ui_builder_set_referenceAttach the picture a design is being built against — a Figma frame, a screenshot of a shipped screen, a mock — as its reference overlay, or `clear` it. The same overlay the browser editor's Frame, density and reference panel shows, so a person opening the design sees what you att
ui_builder_compare_referenceMeasure a design against its reference overlay (attach one with ui_builder_set_reference). Returns what the picture is against the frame and whether a pixel comparison means anything (`facts.pixelComparable` — a 328×56 dp crop stretched over a screen is not comparable until measu
ui_builder_list_revisionsA design's retained revisions, newest first: each one's number, who made it, when, the operation that produced it (`setProperty ×2, insertNode`, `undo`, `restored r3`) and its document digest. `retention` says how far back the history still reaches — older revisions are gone, and
ui_builder_diff_designsCompare two designs, or two retained revisions of one: nodes added, removed and moved, and properties, modifiers and other fields changed, each with its node id and path (`root/slot[index]/node`), plus changed document fields (title, environment, state). Works across a design and
ui_builder_restore_revisionMake a retained revision the design's current content again, **forward**: it is committed as a new revision and nothing after it is lost, so a restore is undone by restoring again. `baseRevision` must be the current revision (a restore that raced an edit is refused as stale). `dr
ui_builder_fork_designMake a new design from one revision of another — yours to edit, owned by you, with its parent recorded: the fork's `forkedFrom` (design, revision, document digest) and the parent's `forks` both show in ui_builder_get_links. A fork is not a branch: it never inherits the parent's c
ui_builder_branch_designFork a design at a revision into a **branch** to explore an alternative, or to change it without trampling somebody editing it live. A branch is a design with its own id: edit it with ui_builder_apply, look at it with ui_builder_view or ui_builder_get_design, compare it with ui_b
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub yschimke, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Respondió en 900 ms (HTTP 200)
No hace falta iniciar sesión
Leímos 60 descripciones de herramientas y no encontramos instrucciones ocultas para la IA
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 3 de 3 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
Debes completar: X-Compose-Preview-Token
Se ejecuta en la nube del creador. Te conectas por internet sin instalar nada, pero lo que envías pasa por los servidores del creador.
El repo de GitHub cambió por última vez –, y la última versión (3.156.0) llegó al registro hoy.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. Se conecta por URL, así que también funcionan las apps que aceptan servidores MCP remotos, como ChatGPT en modo desarrollador.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, yontu
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Türkçe yazı denetimi: TDK kuralları, yapay zekâ izleri, metin türüne göre üslup.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
The server behind compose-preview serve: catalog hosting, live render sessions, the playground, and the browser viewer surfaces. Its history was extracted from yschimke/compose-ai-tools; the CLI remains there and launches this repository's distribution.
Archives on each GitHub release, and nothing on Maven Central.
| Asset | What it is |
|---|---|
compose-preview-server- .tar.gz | the server: catalog hosting, the HTTP routes, the playground, the viewer surfaces. What compose-preview serve, browse and ui-builder launch |
compose-preview-viewer.html | the portable MCP App viewer; yschimke/compose-preview-mcp re-publishes it with the local MCP server |
compose-preview-mcp- .tar.gz | a bridge, not this repository's build: compose-preview-mcp's newest distribution re-attached under this release's name, for CLIs older than compose-ai-tools#5929 that still fetch it from here |
The Compose/Wasm frontend is not an asset of these releases. It is built and released by yschimke/compose-ui-builder as compose-preview-ui-builder-web- .zip on that repository's own releases, and this build resolves it from there — the server archive carries an unpacked copy either way, and the standalone zip is for serving the editor yourself or pointing an existing serve at with --ui-builder-dir.
Nothing here is a Maven coordinate. Six modules used to publish — compose-preview-serve, compose-preview-mcp, and four more that existed on Central only because the first one's POM named them — and the arrangement cost more than it bought. A project dependency reaches a published POM as a coordinate, so adding one to :server meant publishing the dependency too; getting that wrong shipped compose-preview-server:ui-builder-export-jvm:unspecified in 3.1.0 and an unresolvable compose-preview-serve from 3.3.0 through 3.8.0. Six releases nobody could resolve, for transitives nobody wanted.
The one library consumer was compose-ai-tools' :cli, which compiled two wire-drift tests against compose-preview-serve. Those tests launch the distribution now (compose-ai-tools#5436) — the artifact serve runs anyway, so they check the wire that actually ships. Released coordinates up to and including 3.24.0 stay resolvable on Central; there simply will not be new ones.
render-host exists because rendering a packed bundle and reading a preview timeline out of git open no sockets, and a caller doing only that should not link ktor-server-*, jmdns and kotlin-reflect to do it. It is published from [compose-ai-tools](https://github.com/yschimke/compose-ai-tools), not from here: that is where everything it depends on lives, and offline behaviour belongs in that layer (#180). It used to be this repository's :render-host module, publishing as compose-preview-render-host; that coordinate stays resolvable at its final 2.x for anyone pinned to it, and the new one is on compose-ai-tools' version line. The measured before/after and the transitives it deliberately cannot drop are recorded in its build file there, and checkRenderHostIsServerFree moved with it.
The UI builder is a second repository — yschimke/compose-ui-builder — and :server consumes it as releases. Its :ui-builder-runtime owns authoritative persistent design state, exact catalog validation and revision-pinned export orchestration there; :server supplies HTTP/authentication and adapts its narrow render request onto the render host. The runtime therefore has no Ktor, daemon/render-host, MCP or Compose UI dependency, while the offline render host has no UI-builder protocol or service edge. Three jars and a BOM come from Maven Central at composeai-ui-builder in gradle/libs.versions.toml, and the editor archive from that repository's GitHub release; -PcomposeUiBuilderDir swaps all four for a checkout when working on both at once.
The build is intentionally repository-independent. Compose Preview implementation artifacts resolve from Maven Central at the version in gradle/libs.versions.toml; wire contracts resolve separately from compose-preview-contracts. There is no mavenLocal() repository and no shared version catalog outside this repository. A composite build is opt-in only — -PlocalBuilds=tools,daemon,contracts for the upstreams, -PcomposeUiBuilderDir for the UI builder — and for unreleased contract or generator changes an explicit local dependency manifest selects artifacts compiled from local checkouts. Leaving those options unset retains the released dependency graph.
Run the distribution on Java 17 or newer. The UI builder's PNG/SVG export needs Java 21.
The two numbers are one difference, and it is worth stating plainly rather than leaving to be inferred from build files. The server itself, mcp serve, and every artifact this repository publishes target Java 17, because compose-ai-tools' CLI compiles against them on a 17 toolchain and its serve / mcp serve commands launch this distribution's start script as a separate process, resolving java from JAVA_HOME/PATH. Only the UI builder's renderer is above that floor: the design it rasterizes is drawn by a Compose preview compiled for Java 21, packaged into the render bundle, and unpacked into a daemon that runs on the server's own JVM.
On an older JVM the server still starts and everything else works; the UI builder loses PNG and SVG export and says so at startup, naming the version it found and the one it needs. Point JAVA_HOME at a Java 21 JDK to get it back, or pass --ui-builder-state-dir none to run without the UI builder at all. The published container image (deploy/image/Dockerfile) is built on Temurin 21 and clears both.
Both floors are declared once, as java-server and java-ui-builder in gradle/libs.versions.toml, which is also where the reasoning lives. :server:checkServerJvmFloor fails the build if anything above java-server reaches the distribution's classpath, and the render bundle carries java-ui-builder as data so the startup message cannot drift from the bytes it describes.
Renovate retains each Java 17/21 lane and the Temurin 21 image on its selected major while allowing maintenance updates. The rationale, evidence from the Java 25 proposal, and requirements for adopting a newer runtime are documented in Java version policy.
./gradlew check needs one JDK: 17. The UI builder's frontend lane compiles at 21 in its own repository, and the only lane here that still wants both JDKs is visual-harness, which builds that repository's Wasm distributions from a checkout. Gradle finds a 21 installed anywhere it already scans (/usr/lib/jvm, SDKMAN, asdf, jabba); if it cannot, the failure is No matching toolchains found for requested specification: {languageVersion=21} and the fix is to install one, not to lower the target.
./gradlew check ktfmtCheckAll
npm --prefix serve-web ci npm --prefix serve-web run verify
The independently installable visual harness lives in preview-harness/. The experimental Compose/Wasm frontend lives in wasm-ui/. The UI builder itself — editor, renderer, artwork and the Jetcaster fixtures — lives in yschimke/compose-ui-builder; this build resolves its editor archive, runtime and export from that repository's releases, and the harness builds the renderer and fixture distributions from a checkout of it. The server distribution packages the editor at /ui-builder/; the existing catalog-scoped /wasm/ / preview application remains a distinct feature and route. The editor route opens an interactive Wasm editor around the frozen Jetcaster design; clean benchmark modes remain available to the independent visual harness. The editor mounts an exact retained renderer runtime under /ui-builder/runtime/ / in a sandboxed iframe and receives measured node/slot geometry without placing editor overlays in the Compose tree. Catalog runtimes retain a small commit-pinned source descriptor after their catalog generation is swept, so an older design revision can recover its exact runtime after a restart. The compressed archive shares the bounded catalog blob pool; expanded historical trees are process-local leases with an inactivity timeout and a hard count ceiling rather than an unbounded second artifact store.
The Remote Compose authoring extension is behind the default-off compile-time option -PuiBuilderRemoteCompose=true. It spans two repositories — the MCP adapter's half is generated here, and the server's half is baked into the UI-builder export at *its* build time, so enabling the server half means building against a UI-builder checkout with the option (-PcomposeUiBuilderDir=…). See feature scope and verification.
After a restart, configured catalogs keep their home-page cards while they load. With --catalog-cache-dir on a persistent volume, each card can show its last successful hero thumbnail with a small “Loading catalog…” label. The thumbnail is scoped to the catalog's configured repository and branch. Opening a pending catalog promotes it ahead of the remaining startup fetches; the fetch already running finishes first. The loading page retries automatically until the catalog is available.
Start at https://preview.coo.ee/start/ (or https://ui.coo.ee/start to design a new screen). A coding agent installs one plugin, compose-preview from yschimke/compose-agent-plugins; it carries the compose-preview and compose-ui-builder skills, the local MCP server and this server's hosted catalog endpoint. In Claude Code:
/plugin marketplace add yschimke/compose-agent-plugins
/plugin install compose-preview@compose-agent-plugins
A host with no shell or Java (Claude chat, Cowork, ChatGPT) uses the compose-catalogs plugin or the hosted MCP URL https://preview.coo.ee/mcp instead, never both. Other hosts are in the host setup notes; moving from the old marketplace is migration from compose-ag-plugin.
The server can expose every hosted catalog through one aggregate Streamable HTTP MCP endpoint at /mcp. Enable it with --agent-grants --catalog-mcp; published resources require a short-lived preview grant, while made-to-order renders and structured data products require a live grant. The endpoint is separate from the stateful UI-builder authoring MCP surface, but both use the same authenticated user approval and revocation flow. See the catalog MCP design and setup guide.
The local stdio MCP server agents and editor plugins use, compose-preview-mcp, moved to yschimke/compose-preview-mcp with its history and releases there on its own version line. compose-preview mcp serve fetches it from that repository's releases. Its tools, the design_open editor app and the .rc viewer are documented there (docs/LOCAL_MCP.md). This repository keeps the MCP App pages the hosted /mcp serves (mcp-app/compose-preview-viewer.html, mcp-app/preview-library.html
Solo se muestra el principio; lee el resto en el repo