This server lets an AI agent create, configure, and manage Ultramock.io mockup projects programmatically via HTTP APIs using your authenticated session.
Project Management
List projects – Retrieve all projects (id, name, version, editor URL)
Get project – Fetch a project's full configuration, dial values, screen image status, and editor URL
Create project – Create a new project, optionally seeded from a template
Duplicate project – Copy a project including its configuration and screen image
Rename project – Change a project's name
Delete project – Permanently delete a project
Templates
List templates – Browse available system and user-created templates
Apply template – Apply a template's device, camera, lighting, and effects to an existing project
Configuration
Update dials – Merge dial values into a project to adjust camera (tilt, roll, FOV, zoom, pan), scene (background, dark mode, device model), border, effects (depth, sharpen, vignette, grain, bloom, reflection, lighting, etc.), and blur settings
Asset Management
Set screen image – Upload a local PNG, JPG, or WebP file as the on-device screen content
Get editor URL – Retrieve the browser-based editor URL for live preview and final export
Limitations: Final image/video rendering requires a browser (WebGL/canvas). The server cannot perform final export headlessly.
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., "@ultramock-mcp Create a new project from the 'Realistic iPhone' template and set background to dark."
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 lets an AI agent (Claude Code, Claude Desktop, etc.) create and configure ultramock.io product mockups using your own logged-in subscription.
Ultramock currently renders the final image/video in the browser with WebGL, canvas and video encoder APIs. The public app does not expose a server-side "render and download" endpoint. This MCP covers the operations that can be done headlessly through Ultramock's HTTP APIs: projects, templates, full project payload/config editing, source asset uploads, and authenticated source asset downloads.
Use get_capabilities from an agent to see the current boundary in machine-readable
form. A final rendered image/video export still requires either Ultramock to add a
server render API or a headless browser automation layer.
Tool | What it does |
| Report which operations work without a browser and why final rendered export does not. |
| Fetch the authenticated editor status/account payload exposed by Ultramock. |
| List your projects (id, name, version, editor URL). |
| Full config of one project: dial values, full payload, asset keys/URLs, editor URL. |
| New project, optionally seeded from a template. |
| Copy a project including its config and screen image. |
| Rename a project. |
| Delete a project (permanent). |
| System + your templates (use with create/apply). |
| Apply a template's device/angle/lighting to a project. |
| Merge dial values (camera, scene, effects, device, border) into a project. |
| Deep-merge arbitrary JSON into the full project payload, including viewport/timeline/editor settings. |
| Upload a local PNG/JPG/WebP as the on-device screen content. |
| Upload a local PNG/JPG/WebP and assign it to a specific timeline scene. |
| Upload a local PNG/JPG/WebP as the project background image. |
| Download source assets (screen image, background, scene screenshot) to a local file. |
| The URL to open only when you need visual preview or final rendered export. |
update_configPass a dials object of key -> value. Only the keys you pass change.
camera: Viewport.camera.tiltX, .tiltY, .roll, .fov, .zoom, .panX, .panY, .flap, .flapX
scene: Viewport.scene.bgMode, .darkMode, .bgColor (hex), .bgImage, .bgBlur, .transparentBg, .envId, .lightHeight, .lightPos, .lift, Viewport.devices.mockupModel
device: Viewport.devices.mockupBgMode, .mockupBg, .mockupBgImage, .mockupPadding, .iphoneFinish, .statusBar, .hdrYaw, .contactShadow, .iblIntensity, .keyLight, .keyLightHeight, .keyLightRotation
border: Viewport.border.borderRadius, .borderStyle, .glassWidth
effects: Viewport.effects.depth, .sharpen, .vignette, .grain, .pixelGrid, .caStrength, .bloom, .bloomStrength, .bloomThreshold, .bloomRadius, .lighting, .lightingAngle, .lightingIntensity, .lightingSoftness, .reflection, .strength
blur: Viewport.blur.mode, .strength, .falloff, .bokeh, .focusX, .focusY, .focusSize, .angle, .position
Use update_payload for settings stored outside payload.dialValues, such as
editorSettings, viewport, timeline.scenes, text/logo scene data and export
metadata. Object patches are merged recursively; arrays and scalar values are
replaced.
Related MCP server: OpenPrints MCP
npm install
npm run buildAuth uses your ultramock login cookie (no separate API key exists).
Open https://www.ultramock.io and sign in.
DevTools → Application → Cookies → https://www.ultramock.io.
Copy the value of __Secure-authjs.session-token (a UUID).
That value is ULTRAMOCK_SESSION_TOKEN. It rotates when you sign out / the session
expires (~30 days); refresh it if calls start returning auth errors.
claude mcp add ultramock \
--env ULTRAMOCK_SESSION_TOKEN=<your-token> \
-- node /path/to/ultramock-mcp/dist/index.jsOr add it to your MCP config (~/.claude.json / Claude Desktop
claude_desktop_config.json):
{
"mcpServers": {
"ultramock": {
"command": "node",
"args": ["/path/to/ultramock-mcp/dist/index.js"],
"env": { "ULTRAMOCK_SESSION_TOKEN": "your-token-here" }
}
}
}Optional env: ULTRAMOCK_BASE_URL (defaults to https://www.ultramock.io).
get_capabilities -> confirm what can be done without a browser.
list_templates -> pick a look (e.g. "Realistic iPhone").
create_project with fromTemplateId -> get a project id.
set_screenshot, set_scene_screenshot or set_background_image -> upload source assets.
update_config or update_payload -> tweak camera, background, effects, viewport or timeline data.
download_asset -> retrieve source assets again if needed.
get_editor_url -> only for visual preview or final rendered image/video export.
Writes use Ultramock's lease + optimistic-version model; this server acquires and releases the edit lease for you on each write. If another session holds the lease (e.g. the project is open in a browser tab), the server takes it over and that tab drops to read-only.
download_asset downloads the source images stored on the project. It does not
render the composed mockup.
Image upload tools accept PNG, JPG/JPEG and WebP files up to Ultramock's 1 MB upload limit.
I verified the current app behavior against Ultramock's public client bundle:
/api/capture and /api/video-authorize authorize exports, while the final
image/video bytes are generated in the browser and downloaded from a local blob URL.
Apply a template's look (device, camera, lighting, effects) to an existing project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| templateId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral info (applies look to existing project) but does not disclose whether changes are reversible, merging behavior, or required permissions. It adds some context but lacks depth.
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?
Single sentence, 14 words, no redundancy. The core action and scope are front-loaded.
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 simple tool (2 params, no output schema), the description is adequate but missing usage guidelines and parameter details. It does not leverage sibling context to clarify when to use.
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 has 0% parameter description coverage; the description does not explain the IDs or how to obtain them. It only implicitly identifies projectId and templateId through the tool purpose, which is minimal.
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 uses a specific verb ('apply') and resource ('template's look to an existing project'), clearly distinguishing it from siblings like list_templates or create_project. It explains what aspects are affected (device, camera, lighting, effects).
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?
No guidance on when to use this tool versus alternatives (e.g., duplicate_project). No context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new mockup project. Optionally seed it from a template (see list_templates) so it starts with a device, camera angle and lighting already configured.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name. | |
| fromTemplateId | No | Optional template id to seed the project from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the tool creates a new project and optionally seeds from a template, but lacks details on side effects, permissions required, or whether names must be unique. This is adequate for a creation tool but not comprehensive.
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?
Two sentences with no unnecessary words. First sentence states the core action, second adds an optional feature with a reference to a sibling tool. Highly efficient.
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?
For a simple tool with two parameters and no output schema, the description covers the main functionality and optional enhancement. It references a sibling for more details. It could mention the return value, but that is not critical.
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 schema covers both parameters with descriptions. The description adds value by explaining that 'fromTemplateId' allows seeding with preconfigured device, camera angle, and lighting, which goes beyond the schema's brief description.
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 verb 'Create' and the resource 'mockup project', and distinguishes from siblings like 'duplicate_project' by specifying it creates a new project. It also adds the unique optional feature of seeding from a template.
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 tells when to use this tool (to create a new project) and references 'list_templates' for the seeding option, providing implicit guidance. However, it does not explicitly contrast with siblings like 'duplicate_project' or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a project. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly states the key behavioral trait of irreversibility but omits other aspects like permissions or side effects.
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?
Two short sentences with no fluff, essential information (permanence) front-loaded.
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?
For a simple delete action, the description is adequate but lacks details on return values or error cases, which would be helpful given no output schema.
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%, and the description adds no detail about the 'projectId' parameter beyond its name, leaving the format or source unclear.
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 action (permanently delete) and the resource (project), and differentiates from siblings like create_project or rename_project by emphasizing irreversibility.
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 does not provide guidance on when to use this tool versus alternatives (e.g., duplicate_project for backup) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate an existing project (including its configuration and screen image).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure: mentions what is duplicated (config, screen) but no details on other aspects like permissions, history, or depth of copy. No annotations exist, so description carries full burden but is insufficient for a mutation tool.
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?
Single sentence of 11 words with no redundancy. Front-loaded and efficient.
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?
Simple tool (1 param, no output schema), but lacks usage guidance. With sibling tools present, description leaves agent guessing about when duplication is appropriate.
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 coverage 0% and description adds no extra meaning for the sole parameter projectId beyond its basic type. No format, validation, or examples provided.
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?
Clear verb 'duplicate' with specific resource 'existing project' and explicit scope including configuration and screen image. Distinguishes from siblings like create_project, delete_project, rename_project.
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?
No guidance on when to use this tool versus alternatives like create_project or apply_template. Lacks context such as prerequisites or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ultramock editor URL for a project. Open it in a browser to see the live 3D mockup and export the final image or video (rendering happens in the browser).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description notes that rendering happens in the browser, which is helpful, but lacks detail on side effects, persistence, or authentication needs.
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?
Two sentences, no fluff. Every part adds value, clearly and efficiently.
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?
For a simple one-parameter tool without output schema, the description is mostly complete. It explains the purpose and usage, though the return format (URL) is implied but not explicitly stated.
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?
With 0% schema coverage and only one parameter (projectId), the description adds no additional meaning beyond the schema. It fails to explain the expected format or source of projectId.
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 verb 'Get' and resource 'editor URL for a project', and distinguishes from sibling tools like get_project by focusing on the live editor URL.
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 implies usage via 'Open it in a browser', but does not specify when to use vs alternatives (e.g., get_project) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one project's full configuration: current dial values (camera, scene, effects, device), whether a screen image is set, and the editor URL to open for the final visual export.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The project id (e.g. from list_projects). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the return values (dial values, screen image, editor URL), making it clear this is a read operation. Could be more explicit about read-only nature but still good.
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?
One sentence, front-loaded with purpose, no unnecessary words. Highly efficient and clear.
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?
For a simple read tool with no output schema, the description adequately lists what is returned. Could mention error handling but overall sufficient.
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 projectId is described in the schema as 'e.g. from list_projects', which adds helpful context beyond the name. Schema coverage is 100%, so description adds marginal value but is useful.
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 that the tool gets one project's full configuration, listing specific components like dial values, screen image status, and editor URL. This distinguishes it from siblings like list_projects or get_editor_url.
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 implies use when needing full project configuration but does not explicitly state when to use alternatives like get_editor_url for a subset. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ultramock mockup projects in your account (id, name, version, editor URL).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies a safe read operation (list all), but lacks details like no pagination, no ordering, and no mention of rate limits. While 'list all' suggests it returns all projects without side effects, it could be more explicit about read-only nature.
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?
Single sentence that is front-loaded with the main action and includes all essential details. No redundant words; every part earns its place.
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 zero parameters, no output schema, and a straightforward operation, the description is complete. It tells what is listed and what fields are returned, sufficient for an agent to understand tool behavior.
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?
Input schema is empty, so no parameter details needed. The description adds value by listing returned fields (id, name, version, editor URL), which helps the agent understand output beyond what schema provides. According to guidelines, 0 params gives baseline 4; here description enhances it to 5.
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 action (List), resource (ultramock mockup projects), scope (all in account), and what is returned (id, name, version, editor URL). This distinguishes it from sibling tools like get_project (single project) and list_templates (different resource).
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 purpose is clear for listing all projects, but no explicit when-not or alternatives are given. However, given sibling names, it's implicit when to use get_project for a single project. Could add 'use get_project for a specific project' but not necessary for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available mockup templates (system + your own). Use a template id with create_project or apply_template to get a professionally configured device, angle and lighting in one step.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions listing templates but lacks details on behavior such as ordering, pagination, or side effects.
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?
Two concise sentences that front-load the core purpose and usage guidance with no wasted 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?
The description does not explain the return value format or what information a template contains, which is important for agent usage. However, for a simple list tool, it is 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 input schema has no parameters, and the description does not need to explain them. Baseline for zero parameters is 4.
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 explicitly states it lists both system and user's own templates, clearly distinguishing it from sibling tools like apply_template or create_project.
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 clear context for use, stating that template IDs should be used with create_project or apply_template, but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| projectId | 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 does not disclose any behavioral traits such as whether the rename is immediate, reversible, or has side effects. The description is insufficient for an agent to understand the tool's behavior beyond its basic function.
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 with a single sentence, but it is under-specified. While brevity is valued, the lack of useful information makes it less effective. It could be slightly more informative without losing conciseness.
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's simplicity (2 required params, no output schema, no annotations), the description is too minimal. It does not cover parameter explanations, return values, or any prerequisites. More completeness is needed for an agent to use the tool correctly.
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%, and the description adds no meaning to the parameters. The parameters projectId and name are not explained; the description does not clarify what they represent or any constraints.
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 'Rename a project.' clearly states the verb (rename) and resource (project). It distinguishes from sibling tools like create_project, delete_project, and duplicate_project, as renaming is a distinct operation. However, it lacks any additional scope or context.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., update_config for other project updates). The description merely states the operation without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local image file to use as the screen content shown on the device in the mockup. Accepts PNG, JPG or WebP.
| Name | Required | Description | Default |
|---|---|---|---|
| imagePath | Yes | Absolute path to a local image file (png/jpg/webp). | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details on behavioral traits such as side effects (e.g., overwriting existing screenshots), error handling (e.g., file not found), or required permissions. It only indicates the action and accepted formats.
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 a single, well-structured sentence that is front-loaded with the primary action. It is concise and to the point.
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 simplicity of the tool (2 parameters, no output schema, no annotations), the description is fairly complete. However, it omits what happens after upload (e.g., immediate update, return value) and lacks behavioral context.
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 coverage is 50% (only imagePath has a description). The tool description adds context for imagePath but does not explain projectId. It provides marginal value beyond the schema for one parameter.
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 action (upload), the resource (local image file), and the purpose (to use as screen content on the device in the mockup). It also specifies supported formats (PNG, JPG, WebP), making it distinct from sibling tools like apply_template or create_project.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., project must exist) or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge dial values into a project's configuration to change how the mockup looks. Pass an object of dialKey -> value. Numbers are degrees/units/0-1 strengths; booleans toggle effects; bgColor is a hex string; mockupModel picks the device. Available keys — camera: Viewport.camera.tiltX, Viewport.camera.tiltY, Viewport.camera.roll, Viewport.camera.fov, Viewport.camera.zoom, Viewport.camera.panX, Viewport.camera.panY, Viewport.camera.flap, Viewport.camera.flapX | scene: Viewport.scene.bgMode, Viewport.scene.darkMode, Viewport.scene.bgColor, Viewport.scene.transparentBg, Viewport.devices.mockupModel | border: Viewport.border.borderRadius, Viewport.border.borderStyle | effects: Viewport.effects.depth, Viewport.effects.sharpen, Viewport.effects.vignette, Viewport.effects.grain, Viewport.effects.pixelGrid, Viewport.effects.caStrength, Viewport.effects.bloom, Viewport.effects.bloomStrength, Viewport.effects.bloomThreshold, Viewport.effects.bloomRadius, Viewport.effects.lighting, Viewport.effects.lightingAngle, Viewport.effects.lightingIntensity, Viewport.effects.lightingSoftness, Viewport.effects.reflection | blur: Viewport.blur.mode. Only the keys you pass are changed; everything else is preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| dials | Yes | Dial key -> value, e.g. {"Viewport.camera.tiltX": 20, "Viewport.scene.bgColor": "#111111", "Viewport.effects.reflection": true}. | |
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the tool performs a partial merge, lists accepted types and available keys, but does not disclose side effects, permissions, error states, or idempotency. It covers basic behavioral traits but lacks depth.
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 front-loaded with the core purpose, then breaks down dial keys into categories. It is longer than necessary but structured efficiently for complex information. Every sentence adds value, though some repetition could be trimmed.
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 no output schema and complex input (2 parameters with nested object), the description covers available keys and update behavior well. However, it omits error handling (e.g., invalid projectId), return value, and confirmation of success. This is adequate but not fully complete for an agent.
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 schema has 50% coverage (descriptions for both parameters, but dials is generic). The description adds significant semantic detail: type explanations (e.g., 'numbers are degrees/units/0-1 strengths'), a comprehensive list of dial keys organized by category, and examples. This compensates well for the schema brevity.
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 merges dial values into a project's configuration to change the mockup appearance. It specifies the resource (project configuration) and verb (merge/update), and is distinct from sibling tools that create, delete, or apply templates.
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 implies usage by stating 'only the keys you pass are changed; everything else is preserved,' which guides when to use it for partial updates. However, it does not explicitly compare to sibling tools or provide scenarios for when not to use it.
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. Dates show when Glama detected each change.
v1.0.0apply_templatecreate_projectdelete_projectduplicate_projectget_editor_urlget_projectlist_projectslist_templatesrename_projectset_screenshotupdate_configEach tool targets a distinct operation: project CRUD, template listing and application, screenshot upload, config update, and editor URL retrieval. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (e.g., list_projects, create_project, update_config) with snake_case throughout, making the tool set predictable and easy to navigate.
With 11 tools, the set is well-scoped for managing mockup projects, templates, and configurations. Each tool serves a clear purpose without redundancy or missing essentials.
The tools cover the full project lifecycle (create, read, update, delete, duplicate, rename) plus template application, screenshot upload, and config updates. The editor URL tool provides the final export path, making the surface complete for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and run visual creative-production workflows from your AI agent.
Generate on-brand images from your AI agent: design, edit, and render templates over MCP.
On-brand creative studio for AI agents: images, video, audio, and 3D.
Brand-safe MCP for AI agents to create editable, on-brand graphics and automate variants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastiankehle/ultramock-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
