Skip to main content
Glama
Sign In
LeoGCode

figma-reader-mcp

by LeoGCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

figma_diff

Read-only

Compare two Figma file snapshots by node ID to list added, removed, renamed, or moved pages and layers, while ignoring property edits.

Instructions

Compare two snapshots of one file by node id. Figma keeps a node's id through renames and moves, so the id says what is the same layer: pages added, removed or renamed; top-level layers (a page's children, and the children of its sections) added, removed, renamed (same id, other name) or moved (same id, other parent, so a move to another page shows in from.page/to.page; a layer carried inside a moved section keeps its parent and is not listed); and removedNodes, the topmost node of each subtree gone from the visible pages, with the page and path it had and removedCount, how many nodes went with it (itself included); figma_locate on old and new answers for any id under it. Only ids, names and parents are compared: an edit to text, fills, sizes or any other property is reported nowhere. byPage counts each page's added, removed, renamed, moved (moved in; movedOut, moved from it to another page) and removedNodes, every page counted, excluded ones too: read it, then pass page for the one you need. page or exclude_pages (default: the project's excludePages, echoed as excludedPages) narrow the lists before the limit. Every list stops at limit, shared between the pages it covers so a page with many changes cannot crowd out the rest; counts has each total, and truncated says whether any list was cut. A node created and deleted between the two snapshots is in neither. old may be the word previous: the snapshot this account's cache held for new's key before its latest export (one per key, kept by every export that replaces a snapshot). new is then read from that cache, never from a local copy, and refresh exports it again first, which keeps the snapshot it replaces as previous: so 'previous ' with refresh compares the last export with the live file. old and new are each dated, as the server's instructions say: report the changes as between those two times. Where path does not split on ' / ' into its names, pathIds follows it: one id per name, page first.

Input Schema

NameRequiredDescriptionDefault
newYesThe newer file: a .fig path, file key or figma.com URL; a key or URL when old is previous. A node-id in a URL is ignored
oldYesThe older file: a .fig path, file key or figma.com URL, or the word previous for the snapshot that new's latest export replaced
pageNoOnly changes on this page, by its name in either file; a name neither has is an error listing the pages
limitNoMost entries in each list (default 100)
refreshNoExport new again through the browser first (old is never refreshed). Has no effect when new is a path to a .fig, and the result's new carries refreshIgnored
exclude_pagesNoPages to leave out, by name, before the limit: their changes neither fill a list nor count in counts, and byPage still counts them. Default: excludePages in the project's .figma-reader.json, unless page is given; an empty list covers every page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.2

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint/openWorldHint annotations: it discloses exactly which attributes are compared (ids, names, parents) and which are ignored, how moves surface in from.page/to.page, that a node created and deleted between snapshots is in neither, how 'previous' is cached, and that refresh is ignored for .fig paths. This is unusually thorough behavioral disclosure for a read-only tool.

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

Conciseness3/5

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

Front-loaded with the core purpose, but then collapses into a very long, heavily parenthesized wall of text with no paragraph or list structure, making it hard to scan. Most clauses carry genuine information, but the run-on structure hurts usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing the return shape thoroughly: byPage fields (added, removed, renamed, movedIn/movedOut, removedNodes), counts and truncated, removedNodes with page/path/removedCount, and pathIds. An agent has enough to interpret results and call the tool correctly.

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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: limit is shared across the covered pages so one page cannot crowd out others, exclude_pages applies before the limit, and refresh only affects new. These clarify interactions the parameter descriptions alone don't fully convey.

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?

States a specific verb and resource ('Compare two snapshots of one file by node id') and immediately scopes it precisely: pages added/removed/renamed, top-level layers changed, and removedNodes subtrees. It explicitly says property edits (text, fills, sizes) are reported nowhere, so an agent can distinguish this diff tool from siblings like figma_changes and figma_locate.

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?

Gives rich conditional guidance: when to pass page vs exclude_pages, what default exclude_pages applies, and when old='previous' is meaningful. It points to figma_locate for resolving any id, but never explicitly contrasts this tool with figma_changes, leaving that alternative comparison to inference.

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