Skip to main content
Glama

changes

Read-only

Read recorded design revisions for tracked Figma scopes, including summaries, affected layers, and stored subscription evaluations.

Instructions

Recorded design changes of the scopes index track follows; never writes or builds. A query subscription's subscriptionId instead pages its stored search evaluations (evaluations, evaluation, tracking; no revision pages); ack them the same way. Its evaluation is current, current_for_index (the file changed or is gone since that index: refresh, then evaluate), pending with an evaluate step, or unavailable (also when its last evaluate at this publication failed, with that reason, until a later publication); a stored evaluation too large or damaged to page fails with a recovery that acks past it. Each revision is one published build of a tracked scope: kind baseline (tracking started, or nothing comparable before it, with a reason: tracking_started, tracking_changed, previous_changed, previous_untracked, previous_unpublished, facet_version_changed, or index_version_changed when the previous build used other index versions, such as relations before library references) or changes, with coverage, exact summary counts per change kind and facet, and detail complete, truncated or expired. A changes revision's impact says which layers its changes reach: complete, reasons with counts (impact_truncated: layers left out of its detail) and listed, the count per class (direct, effective, effective_unchanged, possible; a class judges the layer's own fields, not its children, which have their own changes) of the layers its detail listed when recorded, never a total (an expired detail no longer keeps them); it is null for a baseline or a revision recorded before impact, never an empty complete one. A node subscription also reads revisions whose changes reach that layer or a layer of that top-level frame, or whose impact is incomplete. Pages run oldest first after cursor, else after the consumer's checkpoint (moved by watch ack), else from the oldest kept. Pass revision to page that revision's changed nodes, then the layers its impact lists, instead; each entry's entry field says which (change or impact). tracking lists each tracked scope's state, lastRevisionId and refreshRequired (the file changed since its last build: refresh the scope to record it; an empty page never proves the file unchanged); monitor is the watch monitor, separate from tracking. A cursor is bound to the filters, the visible sources and the workspace incarnation: any other use is cursor_stale. event_gap means retention deleted revisions before they were read: follow its recovery and treat the scope as possibly changed.

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": {
      "workspaceId": "<workspaceId>"
    },
    "name": "changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNorevisions per page, 1-50 (default 20); with revision, entries per page, 1-500 (default 100)
scopeNoonly this scope's revisions
cursorNonextCursor of the previous page
storageNoabsolute custom storage directory, only for a workspace kept outside the default storage; must be under the server's --storage-root
consumerNowithout cursor, start after this consumer's checkpoint
revisionNoa revisionId: page its changed nodes, then its impact's listed layers, instead
sourceIdNoonly this source's revisions
workspaceIdYesws_... from the index tool
subscriptionIdNoread with this subscription's filters and its own checkpoint; pass no sourceId, scope or consumer with it

Output Schema

NameRequiredDescriptionDefault
nodesNowith revision: its change rows (entry change: frame, id, kind, change, facets, unread, descendants), then its impact's listed layers (entry impact: id, class, sides, facets {changed, unknown, equal}, via {relation, target} or null)
detailNowith revision: complete, truncated (rows or impact entries past the cap were not kept) or expired (neither is kept)
hasMoreNo
monitorNothe watch monitor's state, separate from tracking: inactive when no lease covers the view, partial when some tracked scope of the view has none, else watching or the first problem (unauthorized, source_busy, source_missing, source_unreadable, refresh_failed, stale); source_busy then source_unreadable also when the source path now leads elsewhere through a link, which is never read: relocate the source
trackingNoeach tracked scope of the visible sources: sourceId, scope, state (baseline_pending, active or disabled), lastRevisionId, lastCheckedAtMs (when its last build verified the file), refreshRequired (the file's size or mtime differs from that build's), model (its published generation's semantic layer under the active profile: state ready|partial|pending|unavailable, profileId, policy, generation; coverage only, never a revision)
revisionsNooldest first: revisionId, sourceId, scope, kind (baseline or changes), from (the previous revisionId, null for a baseline or when deleted), snapshotId, coverage (a baseline's reason, such as tracking_started or index_version_changed), summary (changes, kinds, facets, possibleMatches), detail (complete, truncated or expired), detailRows, impact (null, or complete, reasons [{reason, count}], listed per class)
evaluationNoa query subscription: state current, current_for_index (the file changed or is unreadable since that index: refresh, then evaluate), pending (with reason and an evaluate step), unavailable, or disabled (a source set: subscription.disabled.reason is source_removed, a member was removed, or sources_unreadable, its stored set is damaged; no evaluations: unsubscribe, then subscribe again)
nextCursorYespass as cursor for the next page, or to watch ack once handled
revisionIdNowith revision
evaluationsNoa query subscription's stored evaluations, oldest first: evaluationId, snapshotId, coverage, causes (initial, source_changed, index_rebuilt, coverage_changed, ranking_changed, corpus_changed), total (null unless every hit was counted), topK, delta (from evaluationId, fromSnapshotId, snapshotId; enteredTopK and leftTopK as exact sourceId/snapshotId/nodeId refs in the new and old snapshot; rankChanged within the window as new-snapshot refs with from and to, null when rankComparable is false; a source set's also sources, fromSources and changedSourceIds, a library question's definitionMatchChanged and notFollowedSourceIds), createdAtMs
workspaceIdYes
subscriptionNowith subscriptionId: as watch subscribe describes it
trackingTruncatedNotrue when more tracked scopes exist than tracking lists

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.3

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses many behavioral traits: no writes/builds, cursor binding to filters/sources/workspace incarnation, cursor_stale semantics, event_gap retention behavior, checkpoint movement by watch ack, evaluation statuses and recovery, impact truncation and expiry, and oldest-first paging. This is substantial context that annotations alone do not provide.

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?

The description is a single dense run-on paragraph with long parenthetical clauses and many concepts interleaved. Important routing information is buried rather than front-loaded, and the structure makes it hard to scan. While most details are relevant, the presentation is not concise.

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 a complex nine-parameter read tool with an output schema, the description covers much of what an agent needs: revision kinds, coverage/detail states, impact semantics, evaluation states, cursor/checkpoint behavior, and event_gap recovery. The main gap is organizational rather than informational; an agent can extract the necessary behavior but must work through heavy prose.

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%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: subscriptionId reads with the subscription's filters and own checkpoint and must not be combined with sourceId/scope/consumer; revision pages changed nodes then impact-listed layers; consumer starts after a checkpoint only when cursor is absent; cursor is bound to filters, visible sources, and workspace incarnation. These clarify parameter interactions rather than merely restating field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence identifies the resource ('Recorded design changes of the scopes index track follows') and clarifies it never writes or builds. But the actual operation is implied rather than stated ('pages', 'reads revisions'), and the description spends much of its length on subscription/evaluation/impact semantics rather than plainly saying what calling the tool returns. Sibling differentiation is partial: tracking and monitor are mentioned, but other relevant siblings like diff or inspect are not addressed.

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?

It gives some conditional guidance: use subscriptionId to page stored search evaluations, pass revision to page a revision's changed nodes, and use cursor/consumer according to checkpoints. It also explains event_gap recovery. However, it does not clearly say when to choose this tool over alternatives such as diff, inspect, tracking, or watch, so an agent must infer usage from dense prose.

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