Skip to main content
Glama

Gmail inbox video

create_gmail_inbox

Create a Gmail inbox animation (new emails sliding in at the top of the inbox, unread emails in bold until they are opened, opening an email, stars, importance markers, a reply typed into the thread, an on-screen keyboard that slides up while you type). emails is the inbox, top first: each row shows senderName (on a monogram disc — monogram letter, avatarColor palette index or hex — or senderAvatarUrl), time, subject and the one-line preview; unread rows are bold; starred / important set the markers. body, to (default "to me") and label (the chip, default "Inbox") are what the email screen shows. incoming emails arrive during the clip. script plays in order: arrive (the next incoming email — or id — slides in at the top, unread, with a sound), open (tap the row with that id: the email screen slides in and the email is read from then on), star (a row's star on the inbox — id, default the top row — or the open email's), important (the open email's marker), reply (text typed on the keyboard into a draft under the email — typingSpeed chars/s, default 16 — then sent), back (to the inbox, the row now read) and pause (seconds); each step waits delayBefore seconds first. Ids default to m1, m2… for emails and n1, n2… for incoming. myName / myAvatarUrl is the account owner (replies, the search bar's disc). keyboard auto / always / never; showTaps (default true) draws a touch indicator before each tap. All options controllable. Free-plan exports include a MockClip watermark and the free plan includes 2 MCP renders; if the caller is on the free plan, mention that they can upgrade at /pricing for watermark-free exports and more renders.

Input Schema

NameRequiredDescriptionDefault
themeNo
emailsYes
myNameNo
scriptNo
sceneIdNoComposite the clip onto real footage of a hand holding a phone, for a filmed look. Overrides videoFormat and showBezel: the export takes the scene's aspect, with the footage around the phone. Vertical 9:16 scenes: "outdoors" (outdoors), "bookshelf" (bookshelf), "two-hands" (two hands), "on-desk" (on the desk), "dim-room" (dim room). Landscape 16:9 scenes (YouTube, presentations): "city-wide" (city), "desk-wide" (desk), "neon-wide" (neon), "studio-wide" (studio). Default: none.
incomingNo
keyboardNo
showTapsNo
showBezelNoDraw the iPhone bezel around the screen (default true). With 1:1 it frames the top of the phone; false gives a plain frame.
textScaleNoText size: a zoom of the phone UI (text, bubbles, avatars, bars, keyboard, notification banners) as a multiplier from 1 (default, the app's real size) to 1.5, in steps of 0.1 — use it when a short conversation or a single notification should fill the screen. Chat and notification apps only; the other apps ignore it.
myAvatarUrlNo
videoFormatNoOutput aspect ratio. "1:1" is a square for feed posts: chat apps fit the conversation into the square, the other apps show the top of the screen (phone-call ignores it). "9:16", "9:19.5" (iPhone) and "3:2" apply with showBezel false. Default: the iPhone bezel, 9:16.
exportFormatNoOutput file. "mp4" (default) and "gif" are opaque. "webm" (VP9) and "mov" (ProRes 4444, large files) keep an alpha channel: the only way a transparent background, or the corners around the phone bezel, stay transparent. With background.backgroundType "transparent" and no exportFormat the clip exports as webm. Transparent WebM / MOV export needs a Creator or Studio plan; on other plans the clip is made as mp4 and the reply says so.
exportQualityNoResolution and frame rate of the file: "720p" or "1080p" (Full HD) at 15, 24, 30 or 60 fps, e.g. "1080p-30". Default "720p-30". Full HD takes up to 4× as long to export; 60 fps about twice as long and needs a Creator or Studio plan — on other plans the clip is made at 30 fps and the reply says so.
showStatusBarNoDraw the iOS status bar (time, signal, battery) at the top of the screen (default true). Applies with showBezel false or a sceneId: inside the iPhone bezel the status bar is always drawn, so to remove it set showBezel false too.
soundSettingsNo
showHomeIndicatorNoDraw the iOS home indicator bar at the bottom of the screen (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / textScale
      Added value: +{
      +  "description": "Text size: a zoom of the phone UI (text, bubbles, avatars, bars, keyboard, notification banners) as a multiplier from 1 (default, the app's real size) to 1.5, in steps of 0.1 — use it when a short conversation or a single notification should fill the screen. Chat and notification apps only; the other apps ignore it.",
      +  "maximum": 1.5,
      +  "minimum": 1,
      +  "type": "number"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / exportQuality
      Added value: +{
      +  "description": "Resolution and frame rate of the file: \"720p\" or \"1080p\" (Full HD) at 15, 24, 30 or 60 fps, e.g. \"1080p-30\". Default \"720p-30\". Full HD takes up to 4× as long to export; 60 fps about twice as long and needs a Creator or Studio plan — on other plans the clip is made at 30 fps and the reply says so.",
      +  "enum": [
      +    "720p-15",
      +    "720p-24",
      +    "720p-30",
      +    "720p-60",
      +    "1080p-15",
      +    "1080p-24",
      +    "1080p-30",
      +    "1080p-60"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / showHomeIndicator
      Added value: +{
      +  "description": "Draw the iOS home indicator bar at the bottom of the screen (default true).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / showStatusBar
      Added value: +{
      +  "description": "Draw the iOS status bar (time, signal, battery) at the top of the screen (default true). Applies with showBezel false or a sceneId: inside the iPhone bezel the status bar is always drawn, so to remove it set showBezel false too.",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / exportFormat
      Added value: +{
      +  "description": "Output file. \"mp4\" (default) and \"gif\" are opaque. \"webm\" (VP9) and \"mov\" (ProRes 4444, large files) keep an alpha channel: the only way a transparent background, or the corners around the phone bezel, stay transparent. With background.backgroundType \"transparent\" and no exportFormat the clip exports as webm. Transparent WebM / MOV export needs a Creator or Studio plan; on other plans the clip is made as mp4 and the reply says so.",
      +  "enum": [
      +    "mp4",
      +    "gif",
      +    "webm",
      +    "mov"
      +  ],
      +  "type": "string"
      +}
  4. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare a non-readonly, non-destructive, non-idempotent create op, so the safety profile is covered. The description adds real behavioral context beyond that: free-plan exports carry a MockClip watermark, the free plan allows only 2 MCP renders, and the caller should surface the upgrade path. It does not describe latency or the returned artifact, keeping it short of 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.

Conciseness3/5

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

A single dense run-on paragraph with no headings or bullets, which is hard to scan for the 17-param structure. It is front-loaded with purpose, but tangents like "All options controllable" add no value and could be cut.

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

Completeness3/5

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

For a 17-param nested creation tool with no output schema, most visual and script semantics are covered, but the description never says what the tool returns (render/URL/asset) nor does it hint at the enum-heavy export/format options handled only by the schema. Adequate but leaves an agent guessing about the result shape.

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?

With schema coverage at only 47% across 17 params, the description compensates well: it maps `emails` row fields (senderName/monogram/avatarColor/senderAvatarUrl/time/subject/preview/unread/starred/important), `body`/`to`/`label`, `incoming`, all `script` step types, `myName`/`myAvatarUrl`, `keyboard` and `showTaps`, and supplies defaults (to="to me", label="Inbox", typingSpeed=16, showTaps=true, auto ids m1/n1). The remaining rendered-layout params rely on 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?

The description opens with a specific verb+resource ("Create a Gmail inbox animation") and then enumerates the exact visual contents (emails sliding in, bold unread, replies, keyboard). This is unmistakably distinct from every sibling (iMessage/Discord/Slack conversation, notifications), so an agent can select it without opening the schema.

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

Usage Guidelines3/5

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

It gives implied context (this builds an inbox animation, `script` plays steps in order) but never states when to pick this over a sibling app tool or any exclusions. The only directive is a plan-policy note about mentioning the /pricing upgrade, which is not tool-selection guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources