Mockuuups Studio용 MCP 서버 — 약 5,300개의 기기 및 인쇄 목업을 검색한 다음 스크린샷이나 자신의 이미지를 렌더링할 수 있습니다.
하나의 디자인 — WTDIB 베를린 도시 가이드 — 단일 포토슛에서 네 개의 목업으로 렌더링되어, 기기가 바뀌어도 배경은 그대로 유지됩니다. 두 번의 도구 호출, 이미지 호스팅은 필요 없습니다.
|
|
|
|
|
|
|
|
Mockuuups는 자체 호스팅 MCP 서버를 https://mcp.mockuuups.studio/mcp 에서 제공합니다. 이 서버는 이미 알고 있는 목업 ID와 공개적으로 호스팅된 이미지가 필요한 단일 generate_mockup 도구를 노출합니다.
이 서버는 대신 기본 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 필터를 지원합니다. |
| 이 디자인을 이 목업들에 넣습니다. |
| 렌더링이 완료되었나요? 인라인 대기 예산을 초과한 항목을 폴링합니다. |
| 남은 크레딧은 얼마이고, 이 플랜으로 실제로 무엇을 할 수 있나요? |
함께 촬영된 장면은 태그를 공유하므로, 여러 기기에서 일관된 모습을 얻는 방법은 하나를 검색한 다음 해당 태그로 필터링하는 것입니다:
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, 고해상도 +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.
