The MotionSpec MCP server is a trust-enforced UI animation compiler and accessibility checker for creating, validating, compiling, and auditing motion-safe animations in AI-generated web apps. It provides five tools:
motion_catalog — Retrieve the catalog of verified animation primitives (names, purposes, parameter schemas, defaults) plus authoring rules. Call this first before writing any spec.
motion_validate — Pre-check a MotionSpec JSON against the schema, primitive allow-list, parameter bounds, and injection rules. Returns precise [MS-XXX] error codes on failure (fail-closed).
motion_compile — Deterministically compile a validated MotionSpec into production-ready vanilla GSAP JavaScript + CSS, with enforced prefers-reduced-motion fallbacks, WCAG 2.2.2 pause paths for loops, and a performance budget report. Identical input always yields identical output.
motion_audit — Statically audit a live URL's HTML and linked stylesheets for motion accessibility issues: missing reduced-motion guards (WCAG 2.3.3), non-transform/opacity animations, infinite loops without pause paths (WCAG 2.2.2), and <marquee>/autoplay over 5 seconds. Returns findings and a reduced-motion-safe badge for clean sites.
motion_stats — View telemetry summaries of routing and compile outcomes, where escalation clusters indicate which new primitives the catalog should add next.
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., "@motionspec Create a parallax scrolling effect for the hero background"
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.
MotionSpec is an open-core trust layer that checks and compiles reduced-motion-safe, on-budget UI animation for AI-generated web apps. An LLM authors a schema-validated JSON spec; a deterministic compiler emits vanilla-GSAP JavaScript + CSS — injection-proof and catalog-validated by construction, with an enforced prefers-reduced-motion fallback and a performance budget, with WCAG 2.2.2 (Pause, Stop, Hide) pause-path candidates reported — reduced-motion guards map to WCAG 2.3.3 (Animation from Interactions), Level AAA.
Run it two ways: as a keyless MCP server any LLM host can call (npx motionspec), or as a CLI compiler in your build (motion compile spec.json). Either way you keep plain files — a GSAP build or a dependency-free WAAPI/CSS lowering. MIT core. Docs: https://motionspec.dev
The thesis: capability lives in the catalog, not the model. A bigger model can write more elaborate specs, but it can never emit a primitive, parameter, or selector the Trust Boundary hasn't approved. The compiler trusts only what passes.
request ──> Routing (small model, Stage A) ──> MotionSpec (JSON)
│ cache · 1 repair-retry · escalation │
▼ ▼
telemetry TRUST BOUNDARY (fail-closed)
│
┌─────────────┴─────────────┐
▼ ▼
Compiler (no model, Stage B) WAAPI lowering (no GSAP)
│ │
out/*.motion.js + .css Element.animate / IO / @keyframesNot to be confused with: the Android Material Components
MotionSpecclass, the iOS material-motionMotionSpec, Motion.dev / Framer Motion, the usemotion.com calendar app, the Motion Specialties mobility brand, or text-to-video generators (Runway/Sora/Kling/Viggle). MotionSpec checks the UI animation inside web apps — it does not generate video.
npx motionspec # stdio MCP server — no install needed
claude mcp add motionspec -- npx motionspec # register in Claude Code / any MCP host
npm install -g motionspec # or take the CLI:
motion compile spec.json # deterministic build → ./out in your cwdThe host LLM authors the spec; the Trust Boundary stays enforced either way. Listed on the MCP Registry as io.github.MasterPlayspots/motionspec. A hosted MCP endpoint is live: keyless motion_catalog + motion_validate at https://api.motionspec.dev/mcp (streamable-http; keyed tiers cover compile/audit/stats) — setup: https://motionspec.dev/docs.
This repo is also a Claude Code plugin: it bundles the MCP server (npx motionspec, all five tools, local, keyless) with two skills — /motionspec:motion (the author→validate→compile workflow) and /motionspec:audit <url> (motion-accessibility check, WCAG 2.2.2/2.3.3). Try it directly from a clone with claude --plugin-dir ., or install it from the community marketplace once listed:
/plugin marketplace add anthropics/claude-plugins-community
/plugin install motionspec@claude-communityRelated MCP server: GSAP MCP Server
Version | v1.2.7 · schema frozen at spec v1 (ADR-0001, signed) |
Published | npm |
Tests | 295 green — injection attacks, 6000-spec fuzz, golden determinism, schema parity, pause-controls, motion-a11y audit · CI on Node 18/20/22 + x86 Playwright e2e |
Catalog | 40 primitives, every one device-verified, reduced-motion-fallback mandatory; the 18 continuous loops also carry a WCAG-2.2.2 pause path |
Supply chain | 2 runtime deps (MCP SDK, zod — both pinned) · 0 vulnerabilities · CycloneDX SBOM committed · all permissive licenses · CI actions SHA-pinned |
Coverage | ≈99% lines / ≈98% functions / ≈80% branches of |
Last audit | 2026-07-03 — 17/17 integration handshakes evidenced, infra 8.1/10, security: 0 critical, full-git-history secret scan clean |
First client | CHS Computer — live on Vercel |
Hosted MCP | live — keyless |
Schema v1 is frozen: specVersion "1.0" is the stable public contract; "0.1" is deprecated and accepted until v1.2 (a tripwire test enforces the revisit). The [MS-XXX] error-code registry is public API — codes are never reused or redefined.
Allow-list — a primitive not in the catalog never reaches the compiler.
Injection-proof — ids, selectors, string params and triggers are charset-validated; every interpolation is a JS literal (JSON.stringify) or a CSS-screened raw value through one shared safety gate (safety.js). Malicious model output is rejected fail-closed — tested and fuzzed over 6000 random specs.
a11y by construction (motion) — safe defaults, enforced gates, and proof per build. respectReducedMotion is default-on at the compiler level (fail-safe): omitting it still yields a prefers-reduced-motion guard. Opting out is possible but emits MS-GLOBALS-RRM-OFF; a prompt-side instruction alone can never disable the guard.
Pause/Stop for loops (WCAG 2.2.2) — every continuous loop primitive is tagged a11y.persistent, and the compiler emits a pause path by construction: an animation-play-state: paused rule keyed on html[data-ms-paused] (outside the reduced-motion guard, so it is always live) plus, under pauseControls: "auto" (the fail-safe default), one accessible pause/stop toggle (type="button", aria-pressed in sync, ≥24 px target, visible focus ring, not rendered under reduced motion). pauseControls: "api" keeps the CSS contract and leaves the control to the integrator; "off" opts out but emits MS-GLOBALS-PAUSE-OFF when a persistent motion is present. The promote-gate refuses any infinite/repeat:-1 primitive that is not a11y.persistent. A spec with no loops adds zero extra bytes.
Determinism — same spec ⇒ byte-identical code (golden-file tests on both targets).
Versioned — schema frozen v1; catalog SemVer enforced by a diff-gate (a tightened bound shipped as a "patch" fails CI); specs may pin catalogVersion for reproducibility (MS-CATALOG-PIN-MISMATCH fail-closed).
Observability — every request logs model | model-repaired | cache-hit | escalate-* (local: JSONL sink · hosted: Cloudflare Analytics Engine, PII-scrubbed). Escalation clusters are the growth signal for new primitives.
Every catalog primitive compiles through the same validated spec to:
vanilla-gsap — GSAP + ScrollTrigger, the production default.
WAAPI/CSS lowering — zero-GSAP output on Element.animate, IntersectionObserver, and @keyframes/position: sticky. Full catalog coverage, byte-identical golden per primitive, same accessibility guard, same CSS safety gate. This is the framework-decoupling hedge: the IR outlives any animation library. Internal for now — not yet exposed through the MCP tools or the CLI (meta.target is frozen to vanilla-gsap, ADR-0001; engine wiring out of scope, ADR-0002).
The Catalog Forge (CI workflow, manual dispatch) picks the top telemetry-ranked gap, generates one candidate primitive, drives it through a multi-stage gauntlet — meta-schema, mandatory reduced-motion fallback, performance budget, output determinism (entropy tokens like Math.random/Date.now fail the gate), catalog-SemVer legality, golden creation — and opens a PR. It cannot merge, publish, or deploy: structurally (workflow permissions carry no packages/id-token, PR-only) and by regression test (forge-workflow-guard fails CI if anyone smuggles a publish step in). Gate 1 is always a human taste review.
Tool | Contract |
| primitives + authoring rules + catalog version (16-hex pin) |
| fail-closed Trust Boundary; precise |
| deterministic spec → code; never emits on a failed validation |
| static motion-a11y check of a live URL (read-only, open-world) |
| telemetry summary (escalations = catalog growth signal) |
Input is size-capped (MS-INPUT-TOO-LARGE, 64 KB). The stdio server exposes one tool factory as the single source of truth, contract-tested in test/mcp.test.mjs. A hosted MCP endpoint is live: keyless motion_catalog + motion_validate at https://api.motionspec.dev/mcp; keyed tiers cover compile/audit/stats.
motion audit <url> (CLI, --json for the machine payload) and the motion_audit MCP tool run a static scan of a page's HTML and linked stylesheets — no headless browser, no new dependency. It reports four motion problems: CSS animation/transition without a prefers-reduced-motion guard (WCAG 2.3.3), animated properties other than transform/opacity, infinite animations with no pause path (animation-play-state/data-*), and <marquee>/autoplay motion over 5 s (WCAG 2.2.2). Each finding carries a selector, the WCAG reference, and a copy-paste fix. It is honest about its limits: runtime motion (WAAPI/GSAP/JS) is reported as not audited (V2) rather than silently passed. A page that clears every check earns the reduced-motion-safe badge — the exact output MotionSpec itself produces.
MotionSpec is a governed format, not just a tool. The normative spec is SPEC.md (versioned 1.0, RFC-2119 MUST/SHOULD/MAY over the JSON Schema, with a documented ADR-based change process). CONFORMANCE.md defines the five checks (schema, diagnostics, output, determinism, accessibility) an implementation passes to call itself MotionSpec 1.0 compatible, run against the published test/golden corpus. Multiple implementations passing the same corpus is what makes it a standard.
MotionSpec turns specific legal and normative accessibility requirements into compiler-enforced defaults. Each check maps to the frameworks that mandate it:
MotionSpec mechanism | WCAG 2.2 | EN 301 549 | U.S. Section 508 | EAA / BFSG |
Pause/stop path for every continuous loop ( | SC 2.2.2 Pause, Stop, Hide (Level A) | clause 9.2.2.2 (mirrors the WCAG SC) | incorporated (WCAG 2.0 A/AA baseline; 2.2.2 is Level A, in scope) | conformance presumed via EN 301 549 |
Reduced-motion guard on every motion ( | SC 2.3.3 Animation from Interactions (Level AAA) | clause 9.2.3.3 | beyond the AA baseline; provided anyway | supports the EAA "perceivable/operable" duties |
| 2.2.2 / 2.3.3 | clause 9 (web) | WCAG-incorporated success criteria | pre-market self-check for covered products |
Notes: EN 301 549 is the EU harmonised standard whose clause 9 adopts the WCAG success criteria by number. U.S. Section 508 (Revised) incorporates WCAG 2.0 Level A and AA — SC 2.2.2 is Level A and therefore in scope; SC 2.3.3 is Level AAA and is provided as a stronger guarantee than the baseline requires. The European Accessibility Act (EAA) and its German transposition (BFSG, applicable from 28 June 2025) require covered digital products and services to be accessible, with conformance commonly demonstrated against EN 301 549. MotionSpec enforces the motion subset of these obligations by construction; it does not by itself make an entire product conformant.
npm ci # install (0 runtime deps beyond MCP SDK + zod)
npm test # 295 tests: validator, goldens, router, fuzz, parity
node bin/motion.js catalog # primitives + catalog version
node bin/motion.js compile examples/hero.motionspec.json
node bin/motion.js pipeline "Hero headline fades in, cards staggered" --mock
node bin/motion.js stats # telemetry (model / repaired / cache-hit / escalate)Live model instead of --mock: set MOTION_API_KEY (or OPENROUTER_API_KEY); optional MOTION_MODEL (default anthropic/claude-haiku-4.5) and MOTION_BASE_URL (any OpenAI-compatible endpoint). See .env.example.
npm test # full suite, fail-closed trust boundary + golden determinism
npm run coverage # FAILS under 90/90/75 (lines/functions/branches)
npm run catalog-lock:check # ADR-0001 D2: a tightened bound shipped as a "patch" fails here
npm run sbom && npm run sbom:check && node bin/license-check.js
npm run e2e # real-browser Playwright (CI x86 runner)Releases run the whole chain plus a canonical-clone guard and finish with a registry truth check — a version is "live" when the npm dist-tag says so, not when a local run went green.
Defense in depth on the hosted path: constant-time admin-secret comparison (no timing side channel on position or length) · customer keys stored hashed (SHA-256) in KV, fail-closed on any lookup error · pre-auth per-IP rate limiting closes the key-enumeration gap before auth work starts, per-key limiting after · throttled abuse alerts with zero PII · telemetry scrubbed before storage · strict CSP/X-Frame-Options/nosniff on the only ungated page (a data-free dashboard shell). Full posture incl. reporting: SECURITY.md. Last audit (2026-07-03): no critical findings, no secret ever committed across 197 commits of history.
schema/ MotionSpec JSON schema (static contract, parity-tested against the validator)
primitives/ catalog: 40 verified primitives (safe templates)
catalog.lock.json released catalog baseline (SemVer diff-gate)
src/compiler/ validate.js (Trust Boundary) · compile.js (GSAP) · lower-waapi.js (WAAPI/CSS)
safety.js (one shared CSS gate) · keyword-map.js · catalog.js · catalog-semver.js
src/router/ prompt.js · clients.js (openai-compat + mock) · route.js · cache.js · telemetry
src/mcp/ server.mjs (stdio) · register-tools.js (shared tool factory)
src/forge/ generate.js · prioritize.js — the gauntlet-verified catalog forge
src/discover/ gap analysis: request intents ↔ catalog coverage
src/demo/ device-verification demo pages (`?rm=1` simulates reduced motion)
bin/ motion.js (CLI) · promote-gate.js — dev/CI gate scripts stay repo-only
test/ 295 tests incl. injection, fuzz, goldens (both targets), parity; test/e2e (Playwright)
docs/ ADR records (docs/adr/) and per-primitive reference (docs/primitives/)SECURITY.md — security posture of the npm package and hosted endpoint.
docs/adr/0001-schema-freeze-v1.md — the frozen v1 contract and why.
CONTRIBUTING.md covers setup, the gate-driven PR checklist, commit conventions, golden-file regeneration, and a short architecture tour. Issue templates live under .github/ISSUE_TEMPLATE/.
MIT.
Static motion-a11y checker: fetches a URL's HTML + linked stylesheets and scans the CSS for (1) animation/transition without a prefers-reduced-motion guard, (2) animated non-transform/opacity properties, (3) infinite animations with no pause path, (4) /autoplay >5s. Runtime motion (WAAPI/GSAP/JS) is disclosed as 'not audited (V2)'. Returns {ok, score, findings, summary, badge, disclosures, markdown}; a clean site earns the badge 'reduced-motion-safe'. Does network I/O (openWorldHint).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to audit (http/https). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds significant behavioral context: fetches HTML+linked stylesheets, scans CSS for four categories, returns specific JSON structure including badge and disclosures. Discloses network I/O explicitly, aligning with openWorldHint. No contradiction.
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?
Description is compact for the amount of detail, front-loading purpose and listing checks in a clear numbered list. Each sentence adds value. Slightly long but appropriate for the complexity.
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?
Despite no output schema, the description specifies the return structure ({ok, score, findings, summary, badge, disclosures, markdown}) and the condition for the badge. It covers limitations (runtime not audited) and network behavior. Complete for a single-parameter tool.
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 covers the single parameter (url) with 100% description. Description adds meaning by explaining the tool fetches the URL's HTML and linked stylesheets, implying the URL is the target page. This adds context beyond the schema's basic type and format.
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?
Description uses specific verb 'audit' with resource 'live URL', lists four concrete CSS checks, and explicitly distinguishes from runtime motion auditors by disclosing 'Runtime motion... not audited (V2)'. This differentiates from sibling tools (catalog, compile, stats, validate) clearly.
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?
Implicitly states use case for static motion accessibility checks on live URLs. Highlights that runtime motion is not covered, guiding agents to avoid this tool for JS-based motion. Could be more explicit about when to prefer sibling tools, but the limitation is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the catalog of verified motion primitives (names, purpose, parameter schemas, defaults) plus the authoring rules for writing a MotionSpec. Call this FIRST, then write the spec yourself and pass it to motion_compile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description adds that it returns catalog and rules, and positions it as a first step, providing useful behavioral context.
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, front-loaded purpose, and a clear action directive with zero redundant information.
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 parameters and no output schema, the description fully covers what the tool does and how to use it in the workflow.
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?
No parameters exist (100% schema coverage), so baseline 4 applies; description adds no unnecessary param details.
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 returns the catalog of verified motion primitives and authoring rules, distinguishing it from sibling tools like motion_compile by specifying it should be called first.
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?
Explicitly instructs to call this tool first and then write the spec for motion_compile, providing clear sequential guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates (fail-closed) and deterministically compiles a MotionSpec into production-ready vanilla-GSAP JavaScript and CSS, with enforced prefers-reduced-motion fallbacks and a performance-budget report. Same spec always yields identical code. Returns {ok, js, css, report} or {ok:false, errors}.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | The MotionSpec JSON object | |
| specName | No | Optional name used in the artifact header |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it discloses deterministic compilation (idempotent), fail-closed validation, enforcement of prefers-reduced-motion, and a performance report. Annotations already indicate idempotentHint and readOnlyHint, but the description elaborates with concrete behaviors and outputs.
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 two sentences, front-loaded with the key action and outputs. Every sentence adds value: the first covers validation, compilation, and features; the second covers determinism and return shape. No fluff.
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?
Despite no output schema, the description fully explains the return structure ({ok, js, css, report} or errors). It covers input, process, and output comprehensively for a compilation tool. Nested objects are described as MotionSpec JSON, and the behavioral details are complete.
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 100% with basic descriptions. The description enhances understanding by explaining that the spec is validated and compiled deterministically, and that specName is for artifact headers. This adds semantic value beyond the schema's minimal descriptions.
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 validates (fail-closed) and compiles a MotionSpec into GSAP/CSS with deterministic output, specifying verb, resource, and output format. It distinguishes itself from siblings by focusing on compilation, while others like motion_validate and motion_audit handle different operations.
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 when to use the tool (e.g., for production-ready code with reduced-motion fallbacks) but does not explicitly contrast with siblings or state when not to use it. The context is clear enough for an agent to infer, but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of routing/compile telemetry (counts per outcome). Escalation clusters indicate which new primitive the catalog needs next.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true (safe read) and openWorldHint=false. The description adds meaningful behavioral context: it returns aggregated counts per outcome and identifies escalation clusters for catalog needs. This goes beyond the annotations without contradicting them.
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 extremely concise with two sentences and no unnecessary words. It is front-loaded with the core purpose ('Summary of routing/compile telemetry') and efficiently conveys the key output.
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 there is no output schema, the description adequately describes the return content (counts per outcome, escalation clusters). However, for a telemetry tool, it might be improved by clarifying the time period or data scope, though it is sufficient for basic 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?
The tool has zero parameters with 100% schema coverage (empty object). There are no parameters to document, so the description need not add parameter information. Baseline score of 4 is appropriate.
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 it provides a summary of routing/compile telemetry with counts per outcome and escalation clusters indicating catalog needs. However, it does not explicitly differentiate from sibling tools like motion_audit or motion_catalog, which could share similar purposes.
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. There is no mention of prerequisites, limitations, or comparison with sibling tools. The description only states what it does 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.
Checks a MotionSpec against the schema, the primitive allow-list, parameter bounds and injection rules. Fail-closed: returns ok=false with precise errors. Use to pre-check a spec before compiling.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | The MotionSpec JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: fail-closed behavior, returns ok=false with precise errors, and enumerates validation checks. Annotations already indicate read-only, but description enriches with specific failure mode.
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 zero wasted words. First sentence defines action and scope, second sentence gives usage hint. 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?
Provides sufficient context for agent decision: validation checks performed, fail-closed outcome, and recommended usage. Lacks output schema but description hints at return format. Still complete for this simple tool.
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 100% and the schema itself describes the spec parameter as 'The MotionSpec JSON object'. The tool description repeats this without adding further parameter semantics, so baseline score applies.
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?
Clearly states the tool validates a MotionSpec against schema, allow-list, bounds, and injection rules. Distinct from siblings like motion_compile (which does compilation) and motion_audit (auditing).
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?
Explicitly recommends using it 'to pre-check a spec before compiling', providing clear context and implied when-not to use (not for actual compilation).
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.
v0.1.0motion_auditmotion_catalogmotion_compilemotion_statsmotion_validateEach tool has a clearly distinct purpose: audit checks accessibility, catalog lists primitives, compile generates code, validate checks specs, and stats provides telemetry. No overlaps.
All tools follow a consistent 'motion_<verb>' pattern (audit, catalog, compile, stats, validate), making them predictable and easy to distinguish.
With 5 tools, the set is well-scoped for a motion spec management server, covering creation, validation, compilation, auditing, and telemetry without excess.
The tools cover the core workflow (catalog, validate, compile) plus audit and stats. Minor gaps: no tool to list compiled outputs or modify the catalog, and audit only covers CSS, not runtime motion.
Turn any LLM multimodal; generate images, voices, videos, 3D models, music, and more.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MasterPlayspots/motionspec'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
