Skip to main content
Glama
ODU33104

rive-mcp

by ODU33104
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Turn a detected UI screenshot into an animated .riv

riv_ui_prototype

Turn detected UI elements into a working Rive prototype: assign each a role to generate entrances, hover, and press states as a .riv file.

Instructions

Take the elements from riv_ui_detect, assign each one a role, and get back a working .riv: every element becomes a shape or an image asset, each gets an entrance appropriate to its role, and buttons and cards get hover and press states. Roles: background, nav, header, card, panel, button, fab, text, icon, image, chart, list-item, badge, divider, avatar, input. Elements you leave unassigned animate as a generic panel. Pass the same imagePath (or svgPath), minArea and maxElements you gave riv_ui_detect, or the ids will not line up. With svgPath no screenshot is embedded, every element stays editable, and the file reproduces the SVG; its becomes real Rive text you can re-type at runtime, and its embedded data becomes an image asset. figmaUrl fetches the same thing straight from Figma, and needs FIGMA_TOKEN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fontsNoFonts for the SVG's <text>. svgPath only. Without a match the bundled Inter is used and a warning says so; a run whose glyphs the font lacks (CJK, say) is baked as a picture rather than embedded as tofu
rolesYesRole for each element. Ids you omit fall back to a generic panel.
ambientNoGive roles with an idle motion a looping ambient animation (default true)
minAreaNoMust match the riv_ui_detect call (default 576)
outPathYesWhere to write the .riv
staggerNoDelay between elements entering, in milliseconds
svgPathNoThe same SVG you passed to riv_ui_detect (instead of imagePath)
figmaUrlNoThe same Figma link you passed to riv_ui_detect. Off unless FIGMA_TOKEN is set in the server's environment. The frame is fetched again, so a design that changed in between can move the ids
imagePathNoThe same screenshot you passed to riv_ui_detect
entranceMsNoHow long the whole entrance takes, in milliseconds
maxElementsNoMust match the riv_ui_detect call (default 120)
interactionsNoAdd hover and press states where the role has them (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it discloses the core behaviors: elements become shapes or image assets, get role-appropriate entrances, buttons/cards get hover and press states, and unassigned elements become generic panels. It also surfaces important constraints like id alignment, SVG text/image asset behavior, and Figma re-fetching.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

A single dense paragraph front-loads the core purpose, then covers roles, fallback behavior, and input-mode caveats without filler. Every sentence earns its place, and the length is justified by the tool's complexity.

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?

Given 12 parameters, 100% schema coverage, no output schema, and no annotations, the description covers the pipeline, role semantics, animation behavior, and source constraints well. Minor omissions like explicit overwrite behavior for outPath and the return payload keep it just below perfect.

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?

The schema already documents all 12 parameters clearly, so the baseline is 3. The description adds load-bearing semantics: the full role vocabulary referenced by the roles schema, the dependency that input parameters must match the prior detect call, and the behavioral differences between imagePath, svgPath, and figmaUrl.

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 concrete verb+resource: take elements from riv_ui_detect, assign roles, and produce a working .riv. It names the role vocabulary, the animation behaviors, and how this differs from detection or import tools.

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?

It explicitly ties the tool to a prior riv_ui_detect call and warns that imagePath/svgPath, minArea, and maxElements must match or ids will not line up. It also gives decision guidance among imagePath, svgPath, and figmaUrl, including the FIGMA_TOKEN requirement. It does not name sibling alternatives to exclude, but the usage context is strong.

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