Mozaika

get_design_drift

Has this product's design system CHANGED since it was decoded — and which of its numbers are safe to hard-code? Mozaika re-measures the most-referenced products from the live DOM every night and keeps a dated ledger, so this answers what a screenshot never can:

  • verdict "held"     — nothing moved for N consecutive nights; the spec is still accurate.
  • verdict "shifted"  — a token changed and the new value stuck (with the date and before/after).
  • verdict "unstable" — a value alternates between nights: a live A/B test, rotating content,
                         or a page that renders differently each run. `do_not_hardcode` lists it.

Call this BEFORE building against a cached spec, and before baking any measured value into a
token file. Pairs with get_design_system(site) — that gives the spec, this gives its shelf life.

Args:
    domain: e.g. "stripe.com", "linear.app" (bare domain, no scheme).
Free.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well. It discloses that measurements are taken nightly from the live DOM, a dated ledger is kept, and what each verdict (held/shifted/unstable) means. It also mentions the do_not_hardcode field. It does not detail the response format or potential rate limits, but the coverage is substantial.

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 description is somewhat long but well-structured: an engaging lead, a mechanism explanation, a bulleted list of verdicts, clear usage guidance, and a parameter note. Each section adds value and the information is front-loaded enough that the tool's purpose is evident within the first sentence.

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?

The tool has one parameter and no output schema, and the description provides sufficient context: it explains the return verdicts, when to call it, and how it relates to siblings. It could mention edge cases or error conditions, but for typical use the description is complete.

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?

The input schema only defines 'domain' as a string, with 0% coverage. The description compensates by providing the expected format ('bare domain, no scheme') and concrete examples ('stripe.com', 'linear.app'), which is exactly the kind of guidance needed for correct invocation.

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 clearly answers what the tool does: it determines whether a product's design system has changed since decoding and identifies which numbers are safe to hard-code. It explicitly names the verdicts (held, shifted, unstable) and distinguishes itself from the sibling get_design_system by stating that it provides 'shelf life' rather than the spec.

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?

The description gives explicit when-to-use guidance: 'Call this BEFORE building against a cached spec, and before baking any measured value into a token file.' It also names the alternative and pair: get_design_system(site), clearly delineating when to use which tool.

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

All Mozaika tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

The compare_* / get_* / search_* family creates real overlap: compare_components, get_component, get_recipe, and search_screens(kind="component") can all answer similar component questions, and the drift family (get_design_drift, get_design_history, list_design_changes) requires careful reading to pick the right one. However, the detailed descriptions mostly draw clear lines between cross-product comparison, single-spec retrieval, and corpus-level search.

Naming Consistency4/5

The server mostly follows a clean verb_noun convention: get_*, compare_*, list_*, search_*, validate_design, generate_asset. The pattern is highly consistent, though a few names differ slightly in style (audit_code vs validate_design vs get_score), and pluralization varies in tools like compare_components and compare_sections.

Tool Count3/5

At 23 tools this is on the heavy side, and several calls overlap in scope enough to feel redundant. That said, the server's broad purpose suggests a design system reference plus audit platform, so the count is justifiable; it could be consolidated into a tighter 15-18 set.

Completeness4/5

The surface covers design system retrieval, component/section/recipe specs, screens and flows, search, audit/tools, icon assets, and drift/history of measured design tokens, leaving few cap gaps for the declared domain. Minor gaps remain around some metadata like direct screenshot banding by product, but no major dead-end workflow is apparent.

Resources

Need Help?