Direct the site before decorating it.

Motion Menu gives coding agents a deliberate design direction, a reproducible whole-page plan, compatibility constraints, and proven implementation mechanisms. It is not a random effect picker and it is not the renderer.

Connect

Motion Menu is a standard JSON-RPC 2.0 MCP server over streamable HTTP. The live tools/list response is authoritative for tool names, input schemas, and availability.

codex mcp add motion-menu --url https://www.motionmenu.ca/api/mcp

Any MCP-capable client can use the same endpoint. Without an MCP client, read kit.md and retrieve selected patterns over the plain HTTP surface below.

Manual mode: an explicit number is an instruction

When a human names a pattern number, use manual mode: call get_pattern with that number and honor the choice. Numbers are permanent aliases. Do not replace an explicit selection with an autonomous recommendation unless the human asks for alternatives.

Autonomous Director workflow

1. get_design_digest — Read the quality contract before selecting a direction or a pattern.
2. propose_directions — Turn the business, audience, offer, content, assets, constraints, and primary action into distinct design directions; choose one direction_id.
3. build_page — Plan the complete page with that direction_id plus an explicit seed, project history, and exclusions. The result is a plan, not rendered code.
4. validate_combination — Validate every selected pattern together and revise the plan if the combination fails or warns.
5. get_pattern — Retrieve only the selected pattern bodies or framework wrappers, then adapt them to the real codebase and content.
6. External implementation and verification — Implement, render, capture desktop and mobile states, critique the result visually, test motion and accessibility, and iterate in the host agent's own browser workflow.

Quality gate

Autonomous planning is quality-gated: hidden, blocked, placeholder, broken, and below-bar patterns do not enter autonomous selection. The whole-page selection is validated before implementation. Manual lookup remains available for every permanent number.

Seeds, memory, and exclusions

The seed makes a direction reproducible against the same catalogue version and the same inputs. Change it to explore another valid realization. Pass project history to penalize recently repeated choices and exclusions to hard-block patterns or approaches that must not recur.

Responsibility boundary

Motion Menu directs: it provides design intelligence, a page plan, compatibility checks, and transplantable pattern code. The host agent implements and renders the site, then performs the visual critique. Motion Menu does not claim an MCP screenshot critic. audit_page and verify_repair inspect page markup for default-AI grammar; they are not visual render review.

What a direction contains

A direction is an art-direction system, not a style label. The proposals should materially diverge across these decisions:

Working contract

Give the Director real inputs

Include the business, audience, offer, primary action, content inventory, available assets, brand constraints, target framework, runtime budget, accessibility needs, and anything the project has used recently. Generic inputs can only produce weakly differentiated directions.

Treat the plan as a whole

Do not select each section in isolation. Use the chosen direction_id throughout build_page, validate the complete selected set, and replace any failed choice before pulling implementation code.

Keep a project record

Save the direction, seed, history, exclusions, selected pattern identities, and catalogue version with the project. That record makes a result reproducible and gives the next session enough memory to avoid repeating it.

Minimal autonomous handoff

propose_directions {
  "brief": "Business, audience, offer, action, assets, and constraints",
  "seed": "project-name:exploration-02"
}

build_page {
  "intent": "The same business and page brief",
  "direction_id": "<chosen direction_id>",
  "seed": "project-name:exploration-02",
  "history": ["<recently used slug>"],
  "exclusions": ["<hard-blocked slug or number>"]
}

validate_combination {
  "components": ["<every selected slug from the page plan>"]
}

After validation passes, retrieve each selected identity with get_pattern. The host agent then implements the plan in the actual project and owns browser rendering, screenshots, visual critique, and iteration.

Existing-page repair

audit_page can inspect supplied HTML or a public URL for repeated default-AI section grammar. After changing the page, verify_repair can re-check that markup and report the score delta. These are deterministic structure checks, not screenshot analysis or visual taste evaluation.

HTTP surface

GET  /p/manifest.json          catalogue version, counts, and per-item hashes
GET  /p/catalog.json           pattern metadata filed by page role
GET  /p/design-digest.json     machine-readable quality contract
GET  /p/<slug-or-number>.json  one pattern's HTML, CSS, and JavaScript
GET  /p/<slug-or-number>.md    the same pattern as agent-readable Markdown
GET  /r/registry.json          shadcn-compatible registry index
GET  /api/updates?since=<ver>  changed identities since a catalogue version
POST /api/mcp                  MCP server

Pattern slugs are preferred in project records. Pattern numbers are permanent aliases and are especially useful when a human is directing the agent manually. Framework wrappers are available through get_pattern and the registry; read their live schemas for supported formats.

Motion Menu · Catalogue · Changelog · Terms · Privacy · Support