Skip to main content
Glama

create_motion_playground

Destructive

Build a self-contained HTML animation playground to tune motion by hand, with a live stage, designer-labeled controls, and copyable params JSON, SVG frame, and WAAPI exports.

Instructions

Build a motion playground: one self-contained HTML file with an animation on a stage, its controls labelled in designer language, live preview and copyable exports (params JSON, an SVG frame, a WAAPI snippet), written under the taste home's playgrounds/ directory or output_path. Use it when someone wants to tune an animation by hand rather than describe it. Pass profile and project to prefill the playground's Copy for Raven text and, for a motif, to start from the bound surface's motion notes (only the terms restrained, subtle, snappy and no bounce are mapped; anything else is listed in warnings). The user pastes the Copy for Raven text back so you can call record_taste_decision with it. A default that breaks a motif constraint is corrected to the nearest valid step and reported in warnings; an override that cannot be corrected inside the control's range is an error. Raven never draws new artwork. Pass exactly one of motif or timeline. motif builds from a built-in motif. timeline builds from a Motion Lab timeline document you write: text, phases and tracks, checked by Motion Lab's own validator, with text outlined from the font files it names. An element target animates a part of the page passed in fragment, keyed by its id. A timeline plays on load, on hover ({ on: 'hover', target, leave: 'reverse' or 'finish' }) or when scrolled into view ({ on: 'scroll', threshold, once }). Timeline track properties: opacity, translateX, translateY, scale, scaleX, scaleY, rotate, fill, stroke, color, background, draw, clip, blur. Target kinds: surface, text, element. Named easings: linear, ease-in, ease-out, ease-in-out, or { cubicBezier: [x1, y1, x2, y2] }, or { spring: { duration, bounce } }. Use ONLY these.

Input Schema

NameRequiredDescriptionDefault
seedNoRandom seed for any jitter in the motif, so a shared playground replays identically.
motifNoBuilt-in motif to build from. Valid values: keyfob. Use ONLY these. Omit when passing timeline.
titleNoPlayground title shown in the header and tab, 1-40 characters. Defaults to the motif's or timeline's own title.
profileNoTaste profile name (see list_taste_profiles). Pass with project, or omit both.
projectNoBound project name. Pass with profile, or omit both.
fragmentNoHTML for the timeline's element targets: the page part to animate, with ids the targets name. Raven cleans it first: scripts, handlers, style attributes, links and external URLs are removed, and images must be inlined as data: PNG, JPEG, WebP or GIF. At most 3 MB. Timelines only.
timelineNoA Motion Lab timeline document (schemaVersion, id, title, stage, fonts, targets, phases, tracks, trigger, groups, params; optional presets and constraints), at most 256 KB of JSON. Font paths must be absolute or start with ~/ and end in .otf, .ttf, .woff or .woff2. Validation errors are returned in full; fix them and call again. Omit when passing motif.
overridesNoChanges to the motif's controls and group labels. Defaults set here are kept as given and are not adjusted by taste notes. Motifs only: a timeline sets these in its own document.
output_pathNoAbsolute path for the HTML file, ending in .html. Defaults to <taste home>/playgrounds/<motif or timeline id>-<id>.html.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag a destructive, non-idempotent write, and the description adds real substance beyond that: the file is written under the taste home or output_path, motif constraint violations are auto-corrected and surfaced in warnings while uncorrectable overrides error out, fragment HTML is sanitized (scripts/handlers/styles/links stripped, images forced to data: URIs, 3 MB cap), and timeline validation errors are returned in full. It stops short of saying whether an existing file at output_path is overwritten, which matters for a destructiveHint tool.

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?

The core purpose and the primary constraint are front-loaded, which is good, but the body is a dense run-on block that mixes user-facing workflow, schema vocabulary lists, and error semantics into long unbroken sentences. The track-property and target-kind enumerations in particular read as reference material crammed into prose, making it hard to scan.

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?

For a 9-parameter tool with nested objects and no output schema, the description covers nearly everything an agent needs: input modes, sanitization rules, size limits, warnings versus errors, and the Copy for Raven round-trip. The remaining gap is return behavior — aside from error surfacing, it does not say what a successful call hands back (file path, warnings array), which matters given the absent output schema.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds constraints the schema cannot express: motif and timeline are mutually exclusive, profile and project must be passed together or omitted, overrides defaults are preserved verbatim while motif defaults get corrected, and fragment only applies to element targets. It also enumerates the timeline vocabulary (track properties, target kinds, easing forms, trigger shapes) that an agent would otherwise have to guess.

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 precise verb and artifact: 'Build a motion playground: one self-contained HTML file with an animation on a stage... live preview and copyable exports'. The named outputs (params JSON, SVG frame, WAAPI snippet) and the destination (taste home's playgrounds/ or output_path) make it unambiguous against siblings like open_motion_playground or suggest_motion.

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

Usage Guidelines4/5

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

Gives a clear selection rule: 'Use it when someone wants to tune an animation by hand rather than describe it', plus the mutual-exclusion rule 'Pass exactly one of motif or timeline' and the downstream handoff to record_taste_decision. It never names the adjacent sibling tools (open_motion_playground, suggest_motion) as alternatives, so routing between them is left to inference.

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