Capture, Compose, Publish: App Store Screenshot MCP Servers by Job

Nine MCP servers claim to do App Store screenshots. They do three different jobs, and most teams need two of them. Every capability below was read from the project's own source.

Install our MCP server Skip to the table

Renders come back inside the chatClaude Code, Cursor, Windsurf, CodexRenders at exact App Store sizes

App Store screenshot generated over MCP for a running app

App Store screenshot generated over MCP for a habit tracker

App Store screenshot generated over MCP for a budgeting app

App Store screenshot generated over MCP for a podcast app

App Store screenshot generated over MCP for a meditation app

The whole category

Three jobs, and almost nothing does all three

An MCP server with “screenshot” in the name might drive a simulator, lay out a marketing frame, or upload a finished file to Apple. Those are unrelated jobs. This is which servers do which.

Capture

Gets raw pixels out of a running simulator. These are built so an agent can see your app, which is not the same as building a file Apple will accept.

Compose

Turns raw screens into the marketing frames a product page actually shows: background, headline, device frame, exact store dimensions.

Publish

Pushes finished images to App Store Connect. Every server in this column uploads files it did not create and cannot design.

MCP servers for App Store screenshots, by which of capture, compose and publish each one does, where its design comes from, and what it runs on
Server	Design from	Runs on	Access
@appscreenshotstudio/mcpours	Prompt + your repo	Any OS	Growth or Pro plan
appshots-mcp	Typst templates	macOS	Apache-2.0 or MIT, free
ButterKit	Prompt	macOS	Free, $99 to unwatermark
AppLaunchFlow	Canvas you edit	Any OS	Free tier includes MCP
appscreen-mcp	Editor you script	Not stated	MIT, free
ios-simulator-mcp	n/a	macOS	Free
mcp-ios-simulator-screenshot	n/a	macOS	Free
app-publish-mcp	n/a	Any OS	MIT, free
appstore-connect-mcp	n/a	Any OS	MIT, free

Tool count is not a column, on purpose. It measures how a project split up its API, not what the server can do. The publish column settles it: app-publish-mcp exposes 91 tools while appstore-connect-mcp reaches 923 Apple endpoints through 2. Every tool’s schema also loads into your agent’s context on every turn, so a big number is a running cost as often as a capability. The verified counts are on each server’s card below.

Design from is the column that splits the compose tick, which otherwise hides the widest gap here: two of these servers build a layout from a description, three hand you a template or a canvas and expect you to drive it.

Verified against each project’s own README, docs or npm entry on 2026-08-13. “Not stated” means the project never publishes the fact, which is not the same as a no. StoreScreens was a candidate and is absent because its site returned an HTTP 403, so there was nothing to check.

The trap

The most literally named server produces a file Apple will not accept

mcp-ios-simulator-screenshot defaults to resize: true with a max_width of 640 pixels. App Store Connect will not accept an iPhone screenshot narrower than 1242.

That is not a bug. Capture servers downscale on purpose, because they exist to let an agent see your app cheaply, and a full-resolution frame burns tokens for no benefit. The default is right for the job it was built for and wrong for yours.

The deeper problem survives even at full resolution: a raw simulator frame has no headline, no background and no device frame. It is a picture of your app, not a marketing asset. Capturing and composing are different jobs, which is why the column you need is the second one.

Server by server

What each one is actually good at

Including the thing it does better than we do. A table where our column wins every row would not be worth reading.

@appscreenshotstudio/mcp

ComposeNode, any MCP client· 9 tools

Designs a full set from a prompt, takes your app UI into the frames, renders at exact store sizes.

What it will not do: It does not capture from a simulator and it does not upload to App Store Connect. Both ends of the pipeline are somebody else's server.

Setup guide

appshots-mcp

CaptureComposemacOS, Xcode, Typst· 24 tools

Rust server that captures clean simulator frames, then composes them with Typst. Aligns captions to ASO keywords.

Where it beats us: The only server here that both captures and composes, it is free and open source, and Typst gives it native RTL and CJK layout.

Check the source

ButterKit

ComposePublishButterKit.app v1.8+, macOS· 40 tools (their overview says 42)

Designs from a prompt, localizes, and pushes the result to App Store Connect without leaving the agent.

Where it beats us: The only server here that composes and publishes, so it is the shortest path from prompt to a live product page. It also covers all 50 App Store languages.

Check the source

AppLaunchFlow

ComposeRemote HTTP, no install· tool count not published

Hosted canvas driven over a remote MCP endpoint. Edit headlines, swap colours, translate, export.

Where it beats us: MCP access is on every plan including the free one, where ours needs a paid plan. It is also a remote endpoint, so there is nothing to install.

Check the source

appscreen-mcp

ComposeLocal app, Playwright, Chromium· tool count not published

Drives a local browser-based screenshot editor through a scripted API rather than by scraping the DOM.

Where it beats us: Runs entirely on your machine with no account and no upload, so your unreleased UI never leaves the laptop.

Check the source

ios-simulator-mcp

CapturemacOS, Xcode, Facebook IDB· 14 tools

Drives the simulator: tap, type, swipe, inspect the accessibility tree, screenshot, record video.

Where it beats us: Far more than a screenshot tool. If you want an agent that can actually operate your app to reach the screen worth capturing, this is the one.

Check the source

mcp-ios-simulator-screenshot

CapturemacOS, Node 18+· 1 tool (get_screenshot)

Captures the booted simulator screen to a directory. One tool, no configuration to speak of.

Where it beats us: Does exactly one thing with the simplest install on this page. As a way to let an agent see the running app, nothing here beats it.

Check the source

app-publish-mcp

PublishApp Store Connect API key and .p8· 91 tools

Uploads finished images to App Store Connect and manages listings, releases, reviews and submissions.

Where it beats us: Covers Google Play Console as well as App Store Connect, so a cross-platform release runs through one server.

Check the source

appstore-connect-mcp

PublishApp Store Connect API key and .p8· 2 tools (923 endpoints behind them)

Exposes Apple's whole API through a search-and-execute pair instead of one tool per endpoint.

Where it beats us: Because it reads Apple's OpenAPI spec at runtime, it picks up new endpoints without waiting for a release.

Check the source

Ours, concretely

Four calls from your repo to store-ready PNGs

Add this to your MCP client config. Claude Code, Cursor, Windsurf and Codex all read the same shape.

{
  "mcpServers": {
    "appscreenshotstudio": {
      "command": "npx",
      "args": ["-y", "@appscreenshotstudio/mcp"],
      "env": { "APPSCREENSHOTSTUDIO_API_KEY": "ass_live_..." }
    }
  }
}

prepare-screenshot-brief

Returns a category playbook and the exact list of things to dig out of this repo. Free, and it runs before anything gets designed.

generate-screenshots

Designs the set from that brief and returns a project with empty device frames.

upload-screenshots

Drops your real app UI into those frames from local file paths.

render-screenshots

Exports PNGs at store dimensions. Free, so iterate as much as you want.

The constraint, stated plainly. We compose. We do not capture from a simulator and we do not upload to App Store Connect, so a fully hands-off pipeline pairs this with a publish-stage server from the table above. MCP access also needs a Growth or Pro plan, because it runs on the same API keys as the REST API.

Output

What comes back from render-screenshots

Real frames from a set designed over MCP, at the dimensions App Store Connect accepts. No mockup, no illustration.

Rendered App Store screenshot, frame 1 of a fitness app set

Rendered App Store screenshot, frame 2 of a fitness app set

Rendered App Store screenshot, frame 3 of a fitness app set

Rendered App Store screenshot, frame 4 of a fitness app set

Seven device sizes ship in the server, from iPhone 16 Pro Max at 1260 x 2736 down to Apple Watch Ultra 2 at 410 x 502. Browse more in the builder.

Questions about MCP screenshots

Does Screen Studio have an MCP server?

No. Screen Studio is a macOS screen recorder for demo videos and tutorials, and as of August 2026 its site documents no MCP server or Model Context Protocol integration. It is a common search because the name sounds adjacent, but it does not produce App Store screenshots at all.

Which MCP server should I install first?

Start from the job you cannot do by hand. If dragging screens into a design tool is the slow part, install a compose server. If your app needs to be driven through several states to reach the screen worth showing, install a capture server. Most teams end up with one from each column, because almost nothing spans both.

Can one MCP server do the whole pipeline?

Close to it, but not quite. ButterKit composes and publishes, and appshots-mcp captures and composes. Nothing verified here does all three of capture, compose and publish, so a fully hands-off pipeline currently means two servers wired into the same agent.

Why can I not just use an iOS simulator screenshot MCP?

You can capture with one, but the output is not submittable. Simulator capture servers are built to feed an agent vision, so they downscale by default: mcp-ios-simulator-screenshot ships with a 640 pixel maximum width. App Store Connect will not accept an iPhone screenshot below 1242 pixels wide, and a raw simulator frame carries no headline, background or device frame either.

Is fastlane an MCP server?

No. Fastlane is a Ruby toolchain, and Snapshot and Deliver run as lanes from a Fastfile rather than as tools an agent discovers. It solves a similar problem from the CI side rather than the agent side, and the two combine well: capture with Snapshot, compose over MCP, upload with Deliver.

Do these work in Cursor and Codex, or only Claude Code?

Any client that speaks the Model Context Protocol, which includes Claude Code, Cursor, Windsurf, Codex and Zed. The capture servers are the exception to portability, since they need macOS with Xcode installed no matter which client is calling them.

What does the AppScreenshotStudio MCP server cost?

It needs a Growth or Pro plan, because MCP calls run through the same API keys the REST API uses and the Starter plan does not include API access. Rendering never costs credits once a design exists, so iterating on layout is cheaper than the first generation.

How current is this comparison?

Every tool count and capability on this page was read from the project's own README, docs or npm entry on 2026-08-13. Where a project does not publish a tool count, this page says so instead of estimating one. MCP servers move quickly, so check the linked source before making a decision that matters.

Point your agent at it

Install the MCP server, then ask Claude Code or Cursor for a set. It reads your repo for the brief, seven device sizes, rendering always free.

Install the MCP server Read the REST docs