Showoff.dev – AI Mockup Generator

Export the final image

export_image

Renders the finished mockup on the server with the real 3D renderer — models, materials, light, screens, background: exactly what the editor exports, no sketch lines. Returns the image to look at and a download URL (valid 7 days) you can hand on or process further. Takes 5–30 seconds. If the renderer is busy, it says so right away and nothing is charged; call it again after the time it names. Use render_preview for quick checks while building, this for the result. A store set (set_store_set) exports every image in every language as PNG in one ZIP, one folder per store and language (a few minutes; the whole set counts as one export). A set for phones exports both stores, App Store and Google Play. Width and format do not apply there.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`play`	No	Old name for `stores`: false leaves Google Play out.
`width`	No	Output width in pixels; default: the 720p size (longest edge 1280 px), which every plan exports without limit. Above that (longest edge over 1280 px) an export counts toward the organization's monthly full-quality exports (Free: 1, Pro: 15, then a small charge each). Only pass a larger width when the user wants full quality.
`format`	No	File type: "png" (default) or "jpeg" for a smaller file. Store sets are always PNG.	png
`stores`	No	Store sets for phones only (store "iphone" or "play"): which stores to export. Default both, App Store (1320×2868) and Google Play (1080×1920). The second store keeps the width of every image and shows a little less or more of its height, on the side away from the headline.
`folders`	No	Store sets only: how the ZIP is laid out. "plain": "App Store/<language>/01.png" and "Google Play/<language>/01.png", for uploading by hand. "fastlane": the folders fastlane deliver and supply upload from — only when the user uploads with fastlane.	plain
`languages`	No	Store sets only: export just these languages of the set (default all).
`project_id`	Yes	Project id (from create_project or list_projects).
`accept_charge`	No	Only after the user agreed to it: confirms the extra charge for a full-quality export beyond the monthly allowance (the tool names the amount first).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real behavioral load: render time of 5–30 seconds, a busy renderer that charges nothing and names a retry delay, a 7-day URL expiry, and metered full-quality exports with per-plan allowances. That is exactly the cost/retry context an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and result, then handles alternatives and cost. It is long but nearly every sentence carries distinct information; the store-set and width/format asides could arguably be compressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still describes the return (viewable image plus downloadable URL and its 7-day validity), the cost model, the busy path, and the store-set deviation. Nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so 3 is the floor, but the description adds cross-parameter semantics the schema does not: width and format 'do not apply' to store sets, play is an obsolete alias for stores, and the charge only follows rendered previews rather than upfront. Slightly short of 5 because individual formats/bounds are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('renders the finished mockup on the server with the real 3D renderer') plus what comes back (image to look at and a 7-day download URL). It explicitly separates itself from render_preview and set_store_set, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not: 'Use render_preview for quick checks while building, this for the result', names set_store_set as the tool for bulk store exports, and ties full-quality width to a user request. The busy-renderer retry path and accept_charge precondition are spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Showoff.dev – AI Mockup Generator tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?