Retrieve prototype reactions and exposed public motion data for a Figma node or current selection to inspect interaction and animation context; cloud timeline and code conversion are not emulated.
Read prototype reactions and public motion data when exposed. Cloud timeline/code conversion is not emulated.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | No | Figma node ID, e.g. 12:34. Omit to use the editor selection where supported. |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only says data is read 'when exposed' and that cloud timeline/code conversion is not emulated. It says nothing about what failing/empty results look like, whether it requires an active editor session, or what is actually returned.
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?
It is short and the read-purpose is front-loaded, but the second sentence is jargon-heavy and its relevance to selecting or invoking the tool is unclear, so it does not fully earn its place.
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?
For a tool with no annotations and no output schema, the description should compensate by explaining the return content and preconditions. Instead it leaves the agent unsure what 'public motion data' or 'reactions' look like and when the call will yield nothing.
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?
There is a single optional parameter documented at 100% schema coverage, so the schema already explains nodeId and the selection fallback. The description adds no extra meaning about how nodeId affects behavior, so the baseline 3 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?
States a verb and resource ('Read prototype reactions and public motion data'), which gives a rough sense of purpose, but the hedge 'when exposed' and the opaque clause 'Cloud timeline/code conversion is not emulated' blur what the tool actually returns. It never distinguishes itself from near-siblings like get_design_context or get_component_context.
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?
There is no statement of when to call this versus the many siblings that read Figma design content. The only guidance is the implicit limitation 'when exposed', which tells the agent nothing about how to choose between this tool and get_design_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.