Servidor MCP para Mockuuups Studio — busca entre ~5.300 maquetas de dispositivos e impresiones y luego renderiza una captura de pantalla o tu propia imagen en ellas.
Un único diseño — la guía de ciudad de Berlín WTDIB — renderizado en cuatro maquetas a partir de una sola sesión de fotos, de modo que la estancia permanece fija mientras cambia el dispositivo. Dos llamadas a herramientas, sin alojamiento de imágenes en ningún sitio.
|
|
|
|
|
|
|
|
Mockuuups ofrece su propio servidor MCP alojado en https://mcp.mockuuups.studio/mcp. Expone una única herramienta generate_mockup que necesita un identificador de maqueta que ya conozcas y una imagen que ya hayas alojado en algún lugar público.
Este servidor, en cambio, envuelve la API REST subyacente y cierra las dos carencias que hacían incómodo el servidor alojado en la práctica:
Puedes buscar. El endpoint del catálogo original no acepta ningún parámetro de búsqueda — q, type, family y tag se ignoran silenciosamente y cada solicitud devuelve la misma página sin filtrar. Todo el catálogo se obtiene una vez y se busca localmente, de modo que "una tableta sobre un escritorio" o "póster" realmente encuentra algo.
Puedes subir imágenes. Mockuuups solo renderiza desde una URL. Pasa a este servidor los bytes de imagen sin procesar y él los coloca en un enlace efímero e imposible de adivinar para que el renderizador los obtenga, de modo que un diseño local no necesita bucket, ni CDN, ni alojamiento.
Mockuuups solo renderiza desde una URL. Pasa image_base64 y este servidor coloca los bytes en un enlace efímero e imposible de adivinar, permite que el renderizador lo obtenga y deja que expire — sin bucket, sin CDN, sin cuenta de alojamiento.
El renderizado del iPad de arriba, subido desde el disco y renderizado en un póster A3 enmarcado.
Related MCP server: Store Screenshot Generator MCP
Herramienta | Qué responde |
| ¿Qué maqueta debo usar? Búsqueda de texto libre en todo el catálogo, con alias de palabras de dispositivos ("tablet", "poster", "laptop") y filtros por familia/tipo/etiqueta. |
| Pon este diseño en estas maquetas. Acepta |
| ¿Han terminado esas renderizaciones? Sondea cualquier cosa que haya superado el presupuesto de espera en línea. |
| ¿Cuántos créditos quedan y qué puede hacer realmente este plan? |
Las escenas fotografiadas juntas comparten una etiqueta, así que la forma de conseguir un aspecto coherente entre dispositivos es buscar una y luego filtrar por su etiqueta:
search_mockups(query="ipad", tag="update-august-2024-meeting-room")
create_mockups(
mockup_ids=["Zkn1GMTfiAFX5ZOn", "Zkn2DsTfiAFX5ZPD", "Zkn15MTfiAFX5ZO_"],
screenshot_url="https://wtdib.cdit-works.de/",
)Consulta .env.example. Las dos que importan son:
MOCKUUUPS_API_KEY — una clave de desarrollador de mockuuups.studio/developers.
PUBLIC_BASE_URL — el origen público de este servidor. Las subidas lo necesitan, porque el renderizador de Mockuuups recupera la imagen almacenada a través de internet público. Las renderizaciones por captura de pantalla y por URL de imagen funcionan sin él.
La API factura en créditos: una renderización = 1 crédito, +1 por captura de pantalla de sitio web, +1 por alta resolución. Solo se cobran las renderizaciones exitosas.
Dos comportamientos te van a afectar si no los conoces:
Omitir size implica alta resolución, lo que falla de forma rotunda con feature-not-available en cualquier plan que no la tenga. Este servidor siempre envía size explícitamente, limitado por MOCKUUUPS_MAX_SIZE (por defecto 1000, el límite del plan Trial). Auméntalo cuando la cuenta tenga la característica hires.
En los planes con cdn-temporary, los enlaces de entrega caducan después de ~24 horas. Descarga cualquier cosa que valga la pena conservar. account_status informa de ello.
uv sync
uv run pytest
uv run mcp-mockuuups # stdio
TRANSPORT=http uv run mcp-mockuuups # streamable-http on /mcpMIT
[mockuuups] How many credits are left, and what can this plan do? Reports the credit balance plus which features are actually available — hi-res, website screenshots, and whether CDN links expire. Worth checking before a batch: a plain render costs 1 credit and a screenshot costs 2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| status | Yes | |
| account | Yes | |
| summary | Yes | |
| features | Yes | |
| credits_left | Yes | |
| credits_used | Yes | |
| max_render_size | Yes | |
| cdn_links_expire | Yes | |
| hi_res_available | Yes | |
| uploads_configured | Yes | |
| screenshots_available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing credit costs (1 for a render, 2 for a screenshot) and feature-availability semantics that an agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the two core questions the tool answers, followed by detail. The rhetorical 'How many credits are left, and what can this plan do?' framing is slightly verbose but effectively communicates scope in a short block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value structure need not be repeated, and the description covers credits, feature gating, and cost implications. Complete for a zero-parameter status tool, though it omits any mention of how often status changes or caching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to document and the baseline is 4. The credit-cost detail, while not a parameter, further informs invocation decisions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Reports the credit balance plus which features are actually available') and enumerates the concrete facts returned (hi-res, screenshots, CDN expiry). This is clearly distinguishable from the sibling list/search/create/render tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use trigger: 'Worth checking before a batch,' reinforced by the per-operation credit costs. It does not name an alternative tool or an exclusion, but the intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[mockuuups] Put one design into one or more mockups and render them.
Give exactly one source:
screenshot_url — Mockuuups screenshots the live page itself. Best for
websites; costs one extra credit per render.
image_url — any publicly reachable image.
image_base64 — raw image bytes for a design that only exists locally.
Mockuuups can only render from a URL, so the image is staged on this
server under a short-lived unguessable link for the render to fetch.
Pass several mockup_ids to render the same design across devices in one
call; they run concurrently. Renders that outrun the wait budget come back
as pending with a render_id for get_renders — the CDN links are already
valid and will fill in once the render lands.
Each render costs a credit, +1 for a screenshot, so check account_status before a large batch.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| image_url | No | ||
| mockup_ids | Yes | ||
| image_base64 | No | ||
| wait_seconds | No | ||
| screenshot_url | No |
| Name | Required | Description |
|---|---|---|
| failed | Yes | |
| pending | Yes | |
| renders | Yes | |
| summary | Yes | |
| requested | Yes | |
| succeeded | Yes | |
| credits_spent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing credit costs per render and per screenshot, the concurrent execution of multiple mockup_ids, the base64 staging-to-short-lived-URL behavior, and the pending/render_id outcome when the wait budget is exceeded. This is exactly the operational context the annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then organized into a source-selection block and a cost/behavior block; every sentence carries information. It is somewhat long for a tool description, though the length is earned by the genuine complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with an output schema present, the description covers input selection rules, cost model, concurrency, base64 constraints, and the asynchronous pending path. Nothing an agent needs before invoking it correctly is missing, aside from the minor `size` omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply parameter meaning; it thoroughly explains the three mutually exclusive source parameters and mockup_ids, plus implies wait_seconds via the 'wait budget' remark. However, the `size` parameter is never mentioned, leaving one of six parameters undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, resource, and scope: 'Put one design into one or more mockups and render them.' Combined with the sibling set (search_mockups, get_renders, account_status), the agent can immediately tell this is the render-creation tool rather than a search or polling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly bounds the input choice ('Give exactly one source') and names the conditions selecting each option (websites vs. any public image vs. local-only files). It also routes the agent to account_status before large batches and to get_renders for pending results, covering when-not and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[mockuuups] Did those renders finish? Poll renders create_mockups
returned as pending. With wait_seconds it long-polls until they settle or
the budget runs out; with 0 it checks once and returns immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| render_ids | Yes | ||
| wait_seconds | No |
| Name | Required | Description |
|---|---|---|
| failed | Yes | |
| pending | Yes | |
| renders | Yes | |
| summary | Yes | |
| requested | Yes | |
| succeeded | Yes | |
| credits_spent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: long-polling until renders settle or a budget is exhausted. It omits auth requirements, rate limits, and failure behavior for unknown render_ids, keeping it at a solid 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core polling constraint, then the wait_seconds trade-off. No filler; every clause carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value description is unnecessary, and the description covers purpose, origin, and polling behavior. Minor gaps remain around behavior with invalid or unknown render_ids and whether results reflect all requested IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains wait_seconds semantics (default 0 = check once; positive = long-poll until settle or budget expiry), which is the non-obvious parameter. render_ids is left implicit, which the tool name and origin context mostly cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (poll/get renders) and ties it explicitly to create_mockups as the producer of the pending renders. An agent can distinguish it from siblings like create_mockups or search_mockups without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the trigger condition clearly (renders returned as pending from create_mockups) and the choice between wait_seconds > 0 for long-polling versus 0 for a single immediate check. It does not spell out when not to use it (e.g., fetching already-settled renders), so it falls just short of explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[mockuuups] Which mockup should I use? Searches all ~5300 Mockuuups scenes by device, scene and style.
query is free text and understands everyday device words — "tablet",
"laptop", "poster", "smartwatch" — as well as exact placement slugs like
"ipad-air". Combine it with family (iPhone, iPad, MacBook, TV, Paper,
Apple Watch, Samsung, Google, iMac, ...) or kind to narrow.
tag is the strongest way to get one consistent look across several
devices: scenes shot together share a tag, so filtering by a tag returned
on a mockup you like gives you the rest of that shoot. Pass the returned
id to create_mockups.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| kind | No | ||
| limit | No | ||
| query | No | ||
| family | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| types | No | |
| mockups | Yes | |
| summary | Yes | |
| families | No | |
| catalog_size | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context: the scale of the corpus (~5300 scenes), that scenes shot together share a tag, and that results feed create_mockups. It does not disclose result volume or how `limit`/pagination behaves, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose with a question, then elaborates per-parameter in scannable paragraphs, ending with the workflow handoff. Slightly verbose in places, but every section adds usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, and the description covers the search facets and downstream workflow well. The only material gap for correct invocation is the unexplained `limit` default and result-cap behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load, and it meaningfully documents query (understands everyday words and exact slugs like "ipad-air"), family (with example values), kind, and especially tag semantics. It omits any explanation of the `limit` parameter (default 12), so 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) and resource (~5300 Mockuuups scenes) along with the facets searched (device, scene, style). This clearly separates it from create_mockups and get_renders without needing to open a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains how to combine parameters (query with family or kind) and calls out that `tag` is the strongest lever for cross-device consistency, plus routing advice to pass the returned id to create_mockups. It lacks an explicit when-not-to-use or a named alternative tool for other cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.7account_statuscreate_mockupsget_renderssearch_mockupsScored across 4 tools
Each tool targets a clearly distinct stage of the workflow: account_status (billing/plan), search_mockups (discovery), create_mockups (rendering), get_renders (polling async results). No two tools overlap in purpose, and descriptions reinforce the boundaries.
Three of four tools use a consistent verb_noun pattern (search_mockups, create_mockups, get_renders). account_status breaks the pattern with a noun_noun form, but it is still readable and unambiguous.
Four tools cleanly cover the mockup rendering lifecycle without redundancy or padding. The count is well matched to the narrow purpose of the server.
The core loop (check credits, search scenes, render, poll results) is fully covered. Minor gaps exist, such as no way to list prior renders or browse available families/tags independently, but agents can work around these via search.
Create app-store screenshots, social graphics, promo videos, and animated device mockups.
Design mockups, device frames and launch graphics live in your open Brayer studio tab.
Turn product photos or PSD templates into photorealistic mockups: place artwork, edit text, render.
Generate images, videos and PDFs from templates. Manage templates, folders, uploads and fonts.
