mcp-mockuuups
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Bind address | 127.0.0.1 |
| PORT | No | Bind port | 8000 |
| TRANSPORT | No | Transport mode: stdio or http (the Docker image sets http) | stdio |
| MCP_API_KEY | No | Bearer token for the MCP endpoint. Required when TRANSPORT=http; the server refuses to start without it. | |
| PUBLIC_BASE_URL | No | This server's public origin. Needed only for image_base64 uploads, because the Mockuuups renderer fetches the staged image back over the public internet. A private network address stages fine and then fails at render time. | |
| UPLOAD_MAX_BYTES | No | Size cap for one uploaded image (12 MiB) | 12582912 |
| MOCKUUUPS_API_KEY | Yes | Mockuuups Studio developer key | |
| MOCKUUUPS_MAX_SIZE | No | Largest render size sent upstream. Raise it when the plan has the hires feature. | 1000 |
| UPLOAD_TTL_SECONDS | No | How long a staged upload stays fetchable | 900 |
| CATALOG_TTL_SECONDS | No | How long the fetched catalog is cached | 86400 |
| RENDER_WAIT_SECONDS | No | Inline wait for renders before handing back render_ids | 25 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_mockupsA | [mockuuups] Which mockup should I use? Searches all ~5300 Mockuuups scenes by device, scene and style.
|
| create_mockupsA | [mockuuups] Put one design into one or more mockups and render them. Give exactly one source:
Pass several Each render costs a credit, +1 for a screenshot, so check account_status before a large batch. |
| get_rendersA | [mockuuups] Did those renders finish? Poll renders create_mockups
returned as pending. With |
| account_statusA | [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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.