Screenshots → mockups
Turn a screenshot your coding agent just captured into a finished product mockup, without the image ever entering the model's context.
The most common reason to connect Brand Stack to a coding agent: you’re building a feature, the agent takes a screenshot to check its work, and you want that screenshot on a device, in a scene, ready for the landing page.
Take a screenshot of the dashboard we just built, then turn it into a
MacBook Pro mockup with Brand Stack and save it to ./marketing/hero.png.
No shell? Still works
The upload command needs a shell, and not every client has one. Two tools cover chat-only clients (Claude.ai, Claude Cowork, mobile):
- A pasted URL → the agent calls
capture_screenshot, and Brand Stack’s own server renders the page and stores the capture (desktop 1440×900 or mobile 390×844 viewport, matched to the device frame you want). Paste a link in Cowork, ask for a mockup, done. No browser, no upload step. Public pages only: a local dev server is only reachable from your machine, so that stays the CLI’s job. - A pasted image → the agent calls
create_upload_linkand hands you a 30-minute link. Drop the same image there from your browser, no login needed, tell the agent it’s up, and it picks the file out of your Screens timeline.
Every screenshot that arrives this way lands on the workspace’s
Screens page: a chronological timeline, labeled with the brand and
product it belongs to, its device shape, and (for captures) the page
URL. Agents browse it with list_screenshots, and can attribute a
screenshot to a specific brand with the brand parameter on
capture_screenshot, the x-brand header on uploads, or --brand on
the CLI — omitted, the workspace’s default brand applies.
What the agent works out on its own
You shouldn’t have to configure a mockup from inside a chat. The tools tell the agent to infer everything the context already answers, and to ask at most one short question:
- Device, from the screenshot’s shape.
brandstack uploadprints the image’s width×height alongside the URL. A portrait capture is a phone: the agent picks the iPhone frame without asking. A landscape capture is a desktop app, which is the one question worth asking: MacBook Pro or Apple Studio Display. - Persona, from your coding session. The agent knows which product it’s working on. It matches that against your workspace’s products and offers the matching personas by name, or leaves the persona out, since it’s optional.
- Everything else defaults. Aspect ratio 16 unless the image is for a feed post (1) or a story (9); camera and lighting left to the image model.
Say “just make it a mockup” and the agent skips the question too.
The exception is your first mockup. When the workspace has never generated one, the agent slows down and offers real choices in a single message: the camera angle (straight on, over the shoulder, a macro close-up, or a high angle shot), the aspect ratio, and the image size, with each size tier’s actual credit cost and your balance. One guided pass shows you what you can ask for; every mockup after that goes back to inference.
Credits stay visible
Generation costs credits, and the agent is instructed to keep that
visible rather than silently spending: it checks get_credits before a
session’s first generation, quotes the cost of the tier you picked
(higher resolutions cost more, and the prices come from your workspace,
not a guess), and every generation returns the remaining balance. When
it runs low, the agent tells you and links your subscription page,
where you upgrade or buy a credit pack in the browser. Every finished
image also comes back with a viewUrl link that opens it in your
workspace, so nothing gets lost in the chat scrollback.
Your first 10 mockups are free
A newly connected workspace gets credits for 10 free mockups on its
first tool call, so you can feel the flow out before anything costs
money. The grant lands in your normal credit balance: get_credits
shows it, and the studio at brandstack.dev
can spend it too.
Why the upload step exists
Every image parameter on create_mockup and create_scene is a URL
that Brand Stack’s server fetches. That’s deliberate: it’s how the
image model receives reference imagery. It also means a file on your
machine is not something the tool can read: file:// URLs, localhost,
and private network addresses are all refused, since a server that
fetches arbitrary caller-supplied addresses is an SSRF hole.
Carrying the bytes through the MCP call itself is possible but expensive: tool arguments are JSON inside the model’s context window, and a base64-encoded screenshot there costs roughly 35K tokens per 100KB, for an image the model never needs to look at.
So the bytes take the short path by default: your agent’s shell posts
them straight to your workspace, and only the URL comes back. The
inline route (upload_screenshot) exists for the one situation where
the short path is closed — see
sandboxed environments below.
The flow
No setup beyond the connector. The agent captures the screenshot however it already does, then moves the file through an upload link it mints itself:
# 1. The agent captures a screenshot however it already does
npx playwright screenshot http://localhost:3000/dashboard ./shot.png
# 2. The agent calls the create_upload_link tool, which returns an
# uploadEndpoint, and posts the file to it. No API key, no credits.
# The response carries the hosted url plus width and height.
curl -X POST -H "content-type: image/png" \
--data-binary @shot.png "$UPLOAD_ENDPOINT"
# {"url":"https://…/shot.png","width":1440,"height":900,…}
# 3. The agent generates, with the screenshot on a device
# (the create_mockup tool, passing the url as screenshot_url)
With an API key: the same flow, one command shorter
If you keep an API key in the agent’s environment
(npx @brandstack/cli login once, or BRANDSTACK_API_KEY), the CLI
collapses the upload and can even generate from the terminal directly.
Optional, and mostly interesting for CI and scripting:
npx @brandstack/cli upload ./shot.png
# https://…public.blob.vercel-storage.com/…/shot.png
npx @brandstack/cli create-mockup \
--screenshot-url "https://…/shot.png" \
--device-type macbook_pro \
--atmosphere "Studio Lighting" \
--out ./marketing/hero.png
Step 2 is optional, because create-mockup and create-scene accept a
local path in any --*-url flag and upload it for you:
npx @brandstack/cli create-mockup \
--screenshot-url ./shot.png \
--device-type macbook_pro \
--out ./marketing/hero.png
The CLI uploads ./shot.png first, tells you what it did on stderr, and
passes the resulting URL to the tool.
Sandboxed environments: when the POST is blocked
Some agent runtimes route MCP traffic and general HTTP through
different proxies. Claude Code on the web is the common case: MCP
tool calls go through a dedicated channel that always works, while
curl and fetch go through an egress proxy that only allows
allowlisted domains. If brandstack.dev is not on that allowlist, the
POST to uploadEndpoint fails with a 403 policy error even though
every Brand Stack tool call succeeds.
Two ways out:
- Allowlist brandstack.dev in the environment’s network settings (the lasting fix, when you control the environment).
- Fall back to
upload_screenshot, which carries the bytes base64-encoded inside the tool call itself:
# Compress first: every kilobyte of base64 costs context tokens.
# A 1440x900 UI screenshot re-encoded as an ~80-quality JPEG is
# typically well under 200KB.
base64 -w0 shot.jpg # the string to pass as data_base64
The tool detects the image type from the bytes, stores the screenshot
in the Screens timeline like every other route, and returns the hosted
url plus width and height. Decoded limit: 3MB (the POST route
takes 5MB). Agents are told about the fallback in the tool
descriptions, so in practice they recover from the 403 on their own.
Using the MCP connector instead
If you’re driving generation through the MCP connector rather than the
CLI, the upload still happens through the CLI, since it’s the only half of
the pair with access to your filesystem. Agents are told this in the
tool descriptions, so in practice the agent runs npx @brandstack/cli upload ./shot.png in its shell and passes the URL to create_mockup
over MCP without being asked.
Any public https URL works just as well, so an image already hosted somewhere (your CDN, a public bucket) needs no upload at all.
Uploading directly
upload is a thin wrapper over one endpoint, if you’d rather call it
yourself:
curl -X POST https://www.brandstack.dev/api/uploads \
-H "Authorization: Bearer $BRANDSTACK_API_KEY" \
-H "Content-Type: image/png" \
-H "X-Filename: shot.png" \
--data-binary @shot.png
{
"url": "https://…/shot.png",
"assetId": "…",
"filename": "shot.png",
"bytes": 184320
}
| Auth | Same bearer credentials as /api/mcp (an API key or an OAuth token), with the mcp:write scope. |
| Types | PNG, JPEG, WebP, GIF. |
| Size | 5MB, matching what the generator will fetch. A larger file is refused here rather than accepted and silently dropped later. |
| Credits | None. Uploading is free; only generation costs credits. |
| Result | The image lands in your Screens timeline — the Screens page in the workspace sidebar — labeled with its brand, device, and page URL, so list_screenshots and the timeline both show it. Attach metadata with optional headers: x-brand (a brand stack UUID, or none), x-device (mobile, laptop, desktop), x-source-url (the page the screenshot shows). |
Troubleshooting
“must be a public http(s) URL that this server can fetch”: a local
path, file:// URL, or data: URI reached a generation tool. Upload it
first and pass the URL.
413 or “the limit is 5MB”: re-capture at a lower device scale factor, or crop to the region you actually want on screen. Full-page screenshots at 2× cross 5MB easily.
403: the key is read-scope. Uploading writes to your workspace, so
it needs mcp:write. Issue a new key in Settings → Developer.