Provides tools for creating App Store-ready mockups from screenshots, including framing in iPhone 16 Pro, adding titles and subtitles, and batch processing for App Store Connect submission.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@appstore-mockup-mcp Create beautiful App Store mockups from my screenshots"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that wraps app screenshots in an iPhone 16 Pro frame with marketing text above, producing App Store-ready preview images (1284×2778, accepted for the 6.5" slot in App Store Connect).
Wraps any screenshot in a realistic iPhone 16 Pro frame (dark or silver)
Adds bold headline + optional subtitle above the phone
Vertical gradient or solid background
Batch mode — process all screenshots in one call
Theme suggestions derived from the app's own colors, with a custom-color override
Warns if a source image is already a mockup (prevents phone-in-phone)
Related MCP server: MCP Icon Generator
uvx appstore-mockup-mcpAdd to your .mcp.json:
{
"mcpServers": {
"appstore-mockup": {
"command": "uvx",
"args": ["appstore-mockup-mcp"]
}
}
}Then in Claude Code, just share your screenshots and ask:
"Create App Store mockups for these screenshots"
Claude will ask you to pick a theme, propose captions, get your approval, then render everything.
create_iphone_mockupSingle screenshot → mockup.
Param | Default | Description |
| required | Absolute path to source PNG/JPG |
| required | Headline above the phone |
| required | Output path |
|
|
|
|
| Hex or |
|
| Hex |
|
| Smaller line under headline |
|
| Output dimensions |
|
| Phone bleeds off bottom edge |
|
| Set |
create_iphone_mockups_batchSame params, plus jobs list and output_dir. Each job can override any batch-level default.
suggest_themesTakes a list of screenshot paths and returns theme suggestions derived from
the app's own colors (JSON list of {name, bg_color, text_color, frame, why}).
Themes are derived from the app's own colors instead of fixed presets. The
suggest_themes tool analyzes the screenshots' dominant background and accent
colors and proposes:
Name | Built from | Look |
App Match | the app's dominant background, nudged for phone contrast | native, cohesive |
Brand Gradient | the app's accent color, light → dark | bold, brand-forward |
Soft Tint | the accent color washed toward white | clean, minimal |
Text color and frame are picked automatically for contrast. Claude presents
the suggestions and always offers a custom option — supply your own bg_color
(single hex or #hex1,#hex2 gradient), text_color, and frame if you don't
like any of them.
MIT
Wrap an app screenshot in an iPhone 16 Pro frame with marketing text above it, producing an App Store-ready preview image.
If the user did not dictate the title text, draft one (3-7 words, benefit-led) and get the user's approval or edits before calling this.
Args: screenshot: Absolute path to the source screenshot (any size; it is cover-fitted to the phone screen). title: Headline text rendered above the phone. out: Absolute path for the output PNG. frame: iPhone body color, "black" or "silver". bg_color: Background color as hex (e.g. "#f5f1ea"). Pass two hex colors separated by a comma for a vertical gradient. text_color: Title/subtitle color as hex. subtitle: Optional smaller line under the headline. size: Output dimensions as WxH. App Store accepts 1284x2778, 1242x2688 (portrait) or 2778x1284, 2688x1242 (landscape). bleed: If true, the phone bleeds off the bottom edge instead of fitting fully inside the canvas. add_frame: If False, the screenshot is placed directly on the background without adding a phone frame. Use this when the source image already contains a device frame (e.g. a previous mockup output) to avoid phone-inside-phone.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| size | No | 1284x2778 | |
| bleed | No | ||
| frame | No | silver | |
| title | Yes | ||
| bg_color | No | #f5f1ea | |
| subtitle | No | ||
| add_frame | No | ||
| screenshot | Yes | ||
| text_color | No | #111111 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explains cover-fitting of screenshots, the effect of 'bleed' (phone bleeds off bottom), and using 'add_frame' to avoid phone-inside-phone. However, it does not mention whether the tool overwrites output, error handling, or file size limits. The disclosure is adequate but not exhaustive.
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?
The description is well-structured with a brief introductory sentence followed by a bullet-like Args list. It is concise (about 150 words) and front-loaded with the tool's purpose. Every sentence adds value. Minor inefficiency: the Args section could be more compact, but overall it's clear and readable.
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?
Given the tool has 10 parameters (5 optional) and an output schema exists, the description is fairly complete. It covers parameter usage, includes a usage guideline for title drafting, and explains key behaviors. It does not discuss return format or error scenarios, but the output schema likely covers that. The description addresses the main purpose and common edge cases.
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 input schema has 10 parameters with 0% description coverage, so the description must compensate. It does so excellently by describing each parameter in the Args section, including examples for 'size' (valid dimensions), explanation of 'bleed' and 'add_frame' behaviors, and details for 'bg_color' (hex, gradient with comma). This adds significant value beyond the bare schema.
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?
The description clearly states the tool wraps an app screenshot in an iPhone 16 Pro frame with marketing text to produce an App Store-ready preview. It distinguishes from siblings 'create_iphone_mockups_batch' (batch) and 'suggest_themes' (themes) by being a single-image mockup. However, it does not explicitly state when to use this vs the batch variant.
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?
The description provides explicit guidance: if the user hasn't dictated the title, the agent should draft one (3-7 words, benefit-led) and get approval before calling. This is a clear usage guideline. It does not specify when not to use the tool or compare to alternatives, but the guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create App Store preview mockups for many screenshots in one call.
If the user did not dictate the titles, draft one per screenshot (3-7 words, benefit-led), show the user the full list, and get approval or edits before calling this.
Each job needs a screenshot path and a title; everything else is optional
and falls back to the batch-level defaults. Jobs without an explicit
out path are written to output_dir as NN_.png,
numbered in job order.
Args:
jobs: List of jobs, each {screenshot, title, subtitle?, out?,
frame?, bg_color?, text_color?}.
output_dir: Directory for outputs when a job has no out
(default: alongside each screenshot).
frame: Default iPhone body color, "black" or "silver".
bg_color: Default background hex ("#hex1,#hex2" for a gradient).
text_color: Default text color hex.
size: Output dimensions as WxH for all jobs.
bleed: If true, phones bleed off the bottom edge.
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | Yes | ||
| size | No | 1284x2778 | |
| bleed | No | ||
| frame | No | silver | |
| bg_color | No | #f5f1ea | |
| add_frame | No | ||
| output_dir | No | ||
| text_color | No | #111111 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that jobs without explicit out path are written to output_dir as NN_<screenshot-name>.png, and lists all parameters and defaults. It does not mention error handling, potential file overwrites, or permissions, but for a file-creating tool, the behavior is reasonably transparent.
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?
The description is well-structured: a one-sentence purpose, followed by workflow guidance, then an Args list. It is concise with no unnecessary words, making it easy for an agent to parse quickly.
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?
Given that an output schema exists (not shown), the description does not need to explain return values. It covers the main purpose, workflow, parameter defaults, and output behavior. The only minor gap is the undocumented add_frame parameter, but overall it is complete for an agent to use effectively.
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 add meaning. It explains most parameters in the Args section, but the 'add_frame' parameter from the schema is missing from the description. The description adds value over the schema but is not exhaustive.
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?
The description clearly states 'Create App Store preview mockups for many screenshots in one call.' It specifies the verb (Create), the resource (App Store preview mockups), and distinguishes itself from siblings by emphasizing batch processing, differentiating from create_iphone_mockup and suggest_themes.
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?
Explicit guidance is provided: 'If the user did not dictate the titles, draft one per screenshot... show the user the full list, and get approval or edits before calling this.' This tells the agent when to use and when to seek approval, and implies that for a single mockup, the sibling tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive background theme suggestions from the app's own colors.
Call this FIRST, before rendering any mockups, with all of the user's screenshots. It extracts the app's dominant background and accent colors and returns a JSON list of themes ({name, bg_color, text_color, frame, why}), ordered by recommendation strength, with text color and frame already chosen for contrast. Present the list to the user with the hex values, recommend the first entry, and always offer a final Custom option where the user supplies their own bg_color, text_color, and frame instead.
Args: screenshots: Absolute paths of the app screenshots to analyze.
| Name | Required | Description | Default |
|---|---|---|---|
| screenshots | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the process: extracts dominant colors, returns a JSON list with specific fields, orders by recommendation, and chooses text color and frame for contrast. No annotations exist, so the burden is fully on the description, which sufficiently covers the tool's behavior.
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?
The description is concise (6 sentences), front-loaded with purpose, and each sentence serves a clear role: purpose, usage, outputs, presentation, and argument definition. No unnecessary words.
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?
Given the tool has a simple input and an output schema (not shown but referenced), the description covers the essential aspects: input format, output structure, and user guidance. It could mention error handling or missing screenshots, but overall it's adequate.
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 single parameter 'screenshots' is described as 'Absolute paths of the app screenshots to analyze,' which adds meaningful context beyond the schema's bare type definition. Schema coverage is 0%, so this description is essential and effective.
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?
The description clearly states the tool derives background theme suggestions from the app's own colors and distinguishes from sibling tools (create_iphone_mockup, create_iphone_mockups_batch) by emphasizing it should be called first before rendering mockups.
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 instructs to call this tool first before any mockups, provides a clear workflow: extract colors, return themes, present list, recommend first entry, offer custom option. This is comprehensive guidance.
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.0create_iphone_mockupcreate_iphone_mockups_batchsuggest_themesScored across 3 tools
Each tool has a clearly distinct role: suggest_themes analyzes colors, create_iphone_mockup handles single screenshots, and create_iphone_mockups_batch handles multiple. There is no overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case. The batch variant appends '_batch', maintaining a clear and predictable naming scheme.
Three tools is ideal for this domain: one for color analysis, one for single renders, and one for batch processing. No tool is missing or redundant.
The tool set covers the full mockup creation workflow: theme suggestion, single image generation, and batch processing. No obvious gaps exist for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create app-store screenshots, social graphics, promo videos, and animated device mockups.
Design and export App Store / Play Store screenshots, localized across all 48 App Store locales.
Generate exact-size App Store and Google Play screenshots, feature graphics, and listing copy.
Generate designed, localized App Store screenshot sets from your raw app captures.
