Skip to main content
Glama

diff

Compares two saved .fig revisions and reports exact layer ids, types and changed fields per frame, so you can see precisely what changed between design versions.

Instructions

What changed between two saved revisions of a design (old, file): exact layer ids and types only: a frame renamed in place (same id and type) is a structure change, while a recreated frame (a new id) is reported as removed plus added, with a labelled possibleMatch (same name, else same rounded size and position) that never claims identity; lineage between the two files is not verified. Each changed top-level frame (layers directly on a page group under the page) has one summary line with counts per facet: text (text, fonts and laid-out glyphs), layout (size, transform, constraints, auto layout), appearance (fills, strokes, effects, opacity, radius, visibility), properties (component property definitions and assignments, variable values, scopes and code syntax, descriptions, style type, Dev Mode annotations and categories, a page's Ready for dev map and prototype interactions), structure (name, type, parent, order, hidden) and bindings (variable, style, image, main component and prototype edges, old and new compared so removed ones are listed). Nodes carry changed fields with old/new values (each within 512 bytes and 4 KiB per node, 256 KiB per page; larger values say truncated, never unchanged) and edge additions/removals, with swap naming both mains. A side that stopped short reports its missing layers as unknown, never removed; a layer with a field it could not read and no proven difference is unknown with unread, never changed. Pages of changes in stable frame order; nextCursor binds both snapshots, the node, the built corpora and the retained result, so a rebuild that stopped elsewhere is cursor_stale. Nothing is written.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "old": "<old>",
      "file": "<file>"
    },
    "name": "diff"
  }
}

Input Schema

NameRequiredDescriptionDefault
oldYesthe earlier saved .fig: a local path
fileYesthe later saved .fig: a local path
nodeNostored scope root on both sides; default the document0:0
limitNo1-500 changed layers per page, default 100
cursorNonextCursor from the previous page of the same pair and node

Output Schema

NameRequiredDescriptionDefault
nodeNo
framesYesid, name, page, change when the frame itself changed, summary (N listed, then counts per facet and unread), possibleMatch {id, basis, identity possible_match}, and this page's nodes: id, kind, name, change, facets, fields {key: {facet, old, new}}, edges {added, removed, truncated count, swap {old, new} or {truncated}}, descendants, identity_uncertain with oldKind; unread with fields when a field could not be read (change unknown when nothing else proves a difference)
sourceYesold and new sourceId and snapshotId, and freshness.reusedPair
coverageYescomplete; old and new stop and scannedRecords; changes (layers listed across pages, added/removed subtrees counted at their top), possibleMatches and reasons (a side's stop, diff_work_limit, unread_fields, relation_unverified, hidden_content_not_expanded, selection_context_unknown, definition_not_compared for styles, variables, main components and component sets outside the compared records, including variables a compared variable aliases, its collection, explicit variable modes inherited from above the selected node, and Dev Mode state stored above it: a page's Ready for dev status of a compared layer and the document's annotation categories a compared annotation names)
matchingNobasis node_id+kind; lineage unverified
nextCursorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.13.1
    • changedOutput schema / properties / coverage / description
      Previous value: -"complete; old and new stop and scannedRecords; changes (layers listed across pages, added/removed subtrees counted at their top), possibleMatches and reasons (a side's stop, diff_work_limit, unread_fields, relation_unverified, hidden_content_not_expanded, selection_context_unknown, definition_not_compared for styles, variables, main components and component sets outside the compared records, including variables a compared variable aliases, its collection and explicit variable modes inherited from above the selected node)"New value: +"complete; old and new stop and scannedRecords; changes (layers listed across pages, added/removed subtrees counted at their top), possibleMatches and reasons (a side's stop, diff_work_limit, unread_fields, relation_unverified, hidden_content_not_expanded, selection_context_unknown, definition_not_compared for styles, variables, main components and component sets outside the compared records, including variables a compared variable aliases, its collection, explicit variable modes inherited from above the selected node, and Dev Mode state stored above it: a page's Ready for dev status of a compared layer and the document's annotation categories a compared annotation names)"
  2. Addedv0.11.3

TDQS

A4.1/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 load, and it does: it distinguishes in-place renames from recreate-plus-remove, states possibleMatch never claims identity, warns lineage is unverified, and declares 'Nothing is written'. It also discloses truncation thresholds (512 bytes/field, 4 KiB per node, 256 KiB per page) and that partial sides report unknown rather than removed — genuinely beyond structured data.

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

Conciseness2/5

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

There is little filler, but the whole definition is a single dense paragraph of colon-chained clauses that is hard to parse and easy to misread at speed. Front-loading is good (purpose first), but the remaining content needs segmentation into sentences or sections to be usable.

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?

An output schema exists so return values need not be spelled out, and the description covers the hard parts: facets, old/new value reporting, swap naming both mains, unknown vs removed, and page ordering. Missing only peripheral items such as behavior on unreadable or unpaired files, which is minor for this tool.

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 100% and every parameter is already described, so the baseline is 3. The description still adds real meaning by explaining that nextCursor binds both snapshots, the node, the built corpora and the retained result, which turns a mismatched cursor into cursor_stale — context no schema field provides.

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 opening clause states a precise verb and resource ('What changed between two saved revisions of a design (old, file)') and immediately scopes the output ('exact layer ids and types only'). This is clearly distinguishable from sibling tools like changes, verify or find without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by naming the two required inputs and by stating the diff is against saved revisions, so an agent can infer when it applies. However, there is no explicit when-to-use/when-not guidance and no reference to alternatives such as the sibling 'changes' tool, so routing between them is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.