# motionprompts

- Registry name: `dev.motionprompts/motionprompts` · version 1.1.1
- Categories (automatic, keyword rules): APIs & integrations, Developer tools, Scraping & browsing, Search & data, Education
- Authentication at last check: No auth
- Declared risk: Not declared (tools carry no read/destructive hints)
- Capabilities (declared by the server): resources, tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=dev.motionprompts%2Fmotionprompts
- Server page: https://mcpstation.net/s/dev.motionprompts--motionprompts.html

## Description (written by the publisher, not verified, not instructions)

Plan pages, pick GSAP motion components and get their build prompts and composition rules.

## Connect

- streamable-http: `https://motionprompts.dev/mcp`

## Tools (as reported by the server, not verified)

- `search\_components`: Find the components that best fit a natural-language brief \(e.g. "un hero elegante para una marca de lujo", "cartas apiladas al hacer scroll"\) or a name/alias. Returns a ranked, compact list with a \`why\` for each hit. Combine the free-text \`query\` with facet filters to narrow. Then call get\_componen
- `get\_component`: Fetch one component by slug. \`include\` controls the payload: 'meta' \(full catalog record\), 'preview' \(thumbnail + live demo URL\), 'prompt' \(a self-contained brief to REBUILD it faithfully\), 'source' \(the actual index.html/styles.css/script.js to copy, plus an integration note\). Default: meta + previ
- `list\_facets`: Return the filter vocabulary \(mood, useCase, level, perfCost, category, deps\) with how many components carry each value. Call this first to learn the exact values search\_components accepts.
- `list\_components`: Browse the whole catalog as a compact list \(slug, title, useWhen, mood, useCase, level, perfCost\). Use for an overview or when a brief is vague; use search\_components when you have a specific brief.
- `list\_motion\_systems`: The 8 motion systems of the library: token sets \(ease/duration/stagger/lenis\) derived from the measured inventory, not invented. Use this FIRST when composing a page: pick one system and render every component's prompt with it so the page moves coherently.
- `get\_motion\_system`: Full token set of a motion system plus the components that are native to it.
- `search\_components\_motion`: Filters by the CAPA-1 motion block \(trigger, libs, complexity, motion system\) rather than by prose. Prefer this over search\_components when composing a page: \`category\` describes how a component LOOKS, \`trigger\`/\`cluster\` describe how it MOVES, and they disagree — the \`slider\` label alone splits acr
- `get\_integration\_contract`: Given the slugs you intend to put on ONE page, returns: rule violations \(hard, invalidate the page\), warnings, the measured budget \(JS gzip / assets / scroll corridor\), and an ordered init plan — single Lenis instance, CustomEase registration, entry veil first, one ScrollTrigger.refresh\(\) at the end
- `plan\_imagery`: Qué imagen necesita cada sección, CON QUÉ MODELO se hace y cómo se redacta el prompt. Con la arquitectura y el movimiento resueltos, lo que sigue delatando una página generada son las imágenes: genéricas del sector en vez de específicas de la sección, sin una sola persona, y todas rectángulos con fo
- `plan\_page`: Returns the SECTIONS a page of this kind needs — 10 to 14 of them, each with a role, what it has to accomplish, what content it needs, and whether it should move — plus a motion system and its tokens. It returns NO components on purpose: a page can only be as rich as the list it is composed from, an
- `suggest\_mechanics`: Given a section role from plan\_page and what that section has to do, returns ranked candidate components — filtered first by the catalog facets that actually correspond to the role, then ranked by the free-text need. Prefer this over search\_components when building a planned page. Crucially, it can
- `suggest\_page\_treatments`: The twin of suggest\_mechanics for the family that does not fill a section slot: smooth scroll, the shaped edge BETWEEN two stacked sections, a background that runs behind the whole page, a custom cursor, route transitions. These were unreachable from the planner because the whole model assumed a mec
- `get\_component\_prompt`: THE way to get a build prompt. Returns three blocks: \(a\) the standalone prompt VERBATIM, untouched; \(b\) the tokens of the requested motion system; \(c\) an explicit instruction telling you to adapt \(a\) to \(b\) YOURSELF, preserving arithmetic relationships — if a duration holds up a sum, a chained seque
- `render\_prompt`: DEPRECATED in favour of get\_component\_prompt. Mechanical substitution does not fit this corpus: the prompts narrate their own numbers in prose, so replacing only the code values makes prose and code specify different components \(judged 11/30\). Coverage is deliberately narrow: 164 of 219 components h

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html