Skip to main content
Glama
Sign In

Designers

by com.allthepossibles
OverviewDiscussionsAdmin

Token drift compare

compare_token_sets
Read-only

Compare two versions of a design system. Pass before and after (each CSS with custom properties, W3C design tokens JSON, or a flat key/value JSON object; free) or before_url and after_url (Pro). Tokens are matched by name. Reports added, removed, renamed (same value under a new name) and changed tokens, and gives an overall class. Breaking: a token removed or renamed, a type change, a color that moved by deltaE 25 or more, or a size that changed by half or more. Minor: a new token, a visible color shift (deltaE 2 to 25) or size change. Patch: a color change under deltaE 2 or a size nudge of 1px or less. When a side defines no custom properties, the two are compared by the values they use and the class is minor if 15% or more of the values churned, otherwise patch. This is different from check_design_drift, which compares a design file with code at one point in time.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "compare_token_sets"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNoLater token set, same formats.
beforeNoEarlier token set: CSS, DTCG JSON or flat JSON.
after_urlNoPro only. Public page whose linked and inline stylesheets are fetched (up to 12 sheets, 5 MB).
before_urlNoPro only. Public page whose linked and inline stylesheets are fetched (up to 12 sheets, 5 MB).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial non-schema behavior: name-based token matching, the breaking/minor/patch classification thresholds, and the special fallback when a side has no custom properties. It stops short of describing output shape or how renames are detected, hence not a 5.

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

Conciseness4/5

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

The lead sentence establishes what it is, then moves immediately into input modes before the classification rules. It is dense and mostly front-loaded, though the classification detail makes it long enough that an agent must read several sentences before reaching the sibling distinction.

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?

There is no output schema, so the description must convey return semantics – and it does, listing the report categories and the overall class plus the rules that produce each class. For a four-parameter comparison tool this is complete enough to call 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 100%, so the parameters are already documented, setting a baseline of 3. The description adds meaning beyond the schema by pairing the parameters ('before' and 'after' together, or the URL pair) and tying them to the free vs Pro tiers, which the schema does not 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?

The description states a precise verb+resource (compare two versions of a design system / token sets) and enumerates exactly what is reported (added/removed/renamed/changed plus an overall class). It also explicitly distinguishes itself from the sibling check_design_drift, so the agent can choose without opening a schema.

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

Usage Guidelines5/5

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

It spells out the two input modes and their tiers ('before'/'after' free vs 'before_url'/'after_url' Pro) and names the alternative tool with the condition that selects it ('check_design_drift compares a design file with code at one point in time'). When-to-use and when-not-to-use are both covered.

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

All Designers toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources