Skip to main content
Glama
Sign In
omelas-tech

@appscreen/mcp

by omelas-tech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render App Store / Play Store screenshots

render_screenshots

Generate App Store and Google Play screenshots from layout JSON and local image paths. Queue a render job, poll status, then download the finished bundle.

Instructions

Queue a screenshot render; returns jobId, poll get_render_status until done, then fetch the bundle from the resource_link.

BEFORE CALLING THIS: read the appscreen://options resource and present the user the FULL menu of background effects, frames, and presets — each has a preview URL they can open. Let the user pick; never choose a background or frame silently. blur+tint, mesh, and every frame are all valid choices they should see.

IMAGES — put a local file path right on the element; the server reads the bytes off disk and wires up the binding for you. Never base64 real screenshots (a large base64 corrupts token-by-token → renders black): • screenshot: screens[i].screenshot.path = "/shot.png" (or pathsByLang: { en, es } for per-locale shots) • background image: screens[i].bg = { kind:"image", box, path:"/bg.png" } • logo/decoration: screens[i].objects[] = { kind:"image", id:"logo", box, mime:"image/png", path:"~/logo.png" }

Geometry is automatic: omit screenshot.box and the server centers the device at the correct aspect ratio. screensMeta is auto-derived when you upload exactly one file per screen. Text overlays use the tiptap doc format and support rich, PARTIAL styling — per-run color, fontSize, fontWeight, fontFamily (~37 fonts), plus bold/italic/underline and per-paragraph align. See appscreen://schema/text + appscreen://catalog/fonts. Free anonymous tier: 5 lifetime renders.

Input Schema

NameRequiredDescriptionDefault
filesNoLow-level uploads + manual screensMeta binding. PREFER inline paths instead: put screenshot.path / screenshot.pathsByLang on each screen, bg.path on an image background, and path on image objects — the server assembles the upload + binding for you. Use this top-level files[] only if you're hand-managing screensMeta.
langsYesLocales (catalog.langs).
sizesYesTarget canvas sizes (catalog.sizes[].id).
layoutNoOne of catalog.layouts (default = `default`).
roundedNo
screensYes
screensMetaNo
cornerRadiusNo
idempotencyKeyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.30.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the async job pattern, the free-tier quota (5 lifetime renders), the failure mode of base64 (renders black), and that geometry and screensMeta are auto-derived. It stops short of describing error handling or the bundle's contents, so not quite a 5.

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 operational sequence, then bullets the image-handling rules with concrete paths. The 'why' behind each rule (corruption, auto-binding) earns its space. Slightly dense and overlapping with schema descriptions, but no padding.

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

Completeness4/5

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

No output schema exists, and the description correctly explains the return flow (jobId → poll → resource_link bundle). For a 9-param nested tool with no annotations, it covers the critical path but omits guidance on the required sizes/langs catalogs and the files[] fallback.

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 coverage is only 44%, so the description must compensate — and it does for the hard nested params: screens[i].screenshot.path, pathsByLang, bg kind:'image' with path, objects[] images, omitting screenshot.box for auto-centering, and the tiptap text format. It leaves sizes, langs, layout, files[], and idempotencyKey unexplained, so it doesn't fully close the gap.

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 ('Queue a screenshot render') scoped to App Store / Play Store screenshots, and immediately names the sibling it works with ('poll get_render_status'). An agent can distinguish this from get_render_status 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?

Explicit sequencing: call this, then poll get_render_status, then fetch from the resource_link. It also gives a hard precondition ('BEFORE CALLING THIS: read the appscreen://options resource') and a behavioral rule ('never choose a background or frame silently'). This is exactly when/when-not/alternatives coverage.

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

Deploy Server

Other Tools