用于 Mockuuups Studio 的 MCP 服务器 — 搜索约 5,300 个设备和印刷品样机，然后将截图或你自己的图片渲染到其中。
一个设计 — WTDIB 柏林城市指南 — 从一次拍摄中渲染到四个样机里，这样场景保持不变，只有设备在变化。两次工具调用，无需任何图片托管。
|
|
|
|
|
|
|
|
Mockuuups 在 https://mcp.mockuuups.studio/mcp 提供他们自己托管的 MCP 服务器。它只暴露一个 generate_mockup 工具，需要你已经知道的样机 ID 和一个你已经托管在公开位置的图片。
这个服务器改为包装底层 REST API，并弥补了托管版在实际使用中令人尴尬的两个缺口：
你可以搜索。 上游目录端点完全不接受搜索参数 — q、type、family 和 tag 会被静默忽略，每个请求都返回相同的未过滤页面。整个目录只获取一次并在本地搜索，所以"桌上的平板"或"海报"真的能找到东西。
你可以上传。 Mockuuups 只从 URL 渲染。把原始图片字节交给这个服务器，它会将字节暂存到一个短时不可猜测的链接下供渲染器获取，因此本地设计不需要存储桶、不需要 CDN、也不需要托管。
Mockuuups 只从 URL 渲染。传入 image_base64，这个服务器会将字节暂存到一个短时不可猜测的链接下，让渲染器获取，然后让它过期 — 不需要存储桶、不需要 CDN、不需要托管账户。
上面的 iPad 渲染图，从磁盘上传并渲染到带框的 A3 海报中。
Related MCP server: Store Screenshot Generator MCP
工具 | 它回答什么 |
| 我应该用哪个样机？对整个目录进行自由文本搜索，支持设备词别名（"tablet"、"poster"、"laptop"）以及 family/type/tag 过滤器。 |
| 把这个设计放进这些样机里。接受 |
| 那些渲染完成了吗？轮询任何超出内联等待预算的任务。 |
| 还剩多少积分，这个套餐实际能做什么？ |
一起拍摄的场景共享一个 tag，所以要在多个设备上获得一致外观的方法是先搜索一个，然后按它的 tag 过滤：
search_mockups(query="ipad", tag="update-august-2024-meeting-room")
create_mockups(
mockup_ids=["Zkn1GMTfiAFX5ZOn", "Zkn2DsTfiAFX5ZPD", "Zkn15MTfiAFX5ZO_"],
screenshot_url="https://wtdib.cdit-works.de/",
)参见 .env.example。两个重要的：
MOCKUUUPS_API_KEY — 来自 mockuuups.studio/developers 的开发者密钥。
PUBLIC_BASE_URL — 这个服务器的公开源。上传需要它，因为 Mockuuups 的渲染器会通过公共互联网取回暂存的图片。截图和图片 URL 渲染不需要它也能工作。
API 按积分计费：一次渲染 = 1 积分，网站截图 +1，高清 +1。只有成功的渲染才收费。
有两个行为如果你不知道会踩坑：
省略 size 意味着高清，在任何没有该功能的套餐上都会以 feature-not-available 硬失败。这个服务器总是显式发送 size，上限由 MOCKUUUPS_MAX_SIZE（默认 1000，即 Trial 上限）控制。当账户拥有 hires 功能时可以提高它。
在带有 cdn-temporary 的套餐上，交付链接约 24 小时后过期。 下载任何值得保留的内容。account_status 会报告这一点。
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.
