# Mozaika (remote · mozaika.design)

Design references for coding agents: real product screens, sections and decoded design tokens.

- Trust score: 73/100 (medium)
- Change this week: +11
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mozaika.design`: 73/100 (this document), [markdown](https://verifymcp.io/servers/design-mozaika-mozaika/mozaika.md), [page](https://verifymcp.io/servers/design-mozaika-mozaika/mozaika)

## Channel facts

- Endpoint: `https://mozaika.design/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, but the challenge carries no valid RFC 9728 metadata, so a client cannot discover where to get a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 58/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 3479 tokens (~173/item across 20 items; 20 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http design-mozaika-mozaika https://mozaika.design/mcp
```

### Codex

```toml
[mcp_servers.design-mozaika-mozaika]
url = "https://mozaika.design/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "design-mozaika-mozaika": {
      "type": "remote",
      "url": "https://mozaika.design/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add design-mozaika-mozaika --url https://mozaika.design/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  design-mozaika-mozaika:
    url: "https://mozaika.design/mcp"
```

### Other

```json
{
  "mcpServers": {
    "design-mozaika-mozaika": {
      "type": "http",
      "url": "https://mozaika.design/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 71, +7)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 62, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 62)

First indexed and scored.

## MCP tools (20)

### `search_screens` (~400 tokens)

Search real product UI screens for design reference.

    Use this BEFORE designing any page/component so your output matches how the
    best-designed products actually solve the problem. Returns structured metadata
    (description, UX patterns, UI elements, colors, palette) plus an image_url.
    Section/component/recipe hits also carry `measured` and `retina` booleans —
    prefer measured:true, retina:true references (pixel-measured, high-res).

    Args:
        query: free text, e.g. "fintech onboarding", "dark dashboard", "Linear".
        page_type: e.g. "Landing Page", "Dashboard", "Pricing & Subscription", "Checkout".
        ux_pattern: e.g. "Onboarding", "Dark Mode", "Filter & Sorting", "Stats".
        industry: e.g. "AI Tool", "Finance", "Analytics", "Fashion".
        platform: "Web", "iOS" or "Android" (mobile = official store-listing screens).
        limit: max results (1-40, default 12).
        kind: "page" (default, whole screens), "section" (page parts),
            "recipe" (live-decoded composed patterns: Command Palette, Navbar, Login,
            Data Table, Hero Effect...) or "component" (measured single components).
        section_type: narrows by type, e.g. kind="section" + "Pricing / Plans" /
            "Testimonial / Social Proof" / "Hero", or kind="recipe" + "Login" /
            "Navbar" / "Data Table" / "Hero Effect".

Input parameters:

- `industry` (string)
- `kind` (string)
- `limit` (integer)
- `page_type` (string)
- `platform` (string)
- `query` (string)
- `section_type` (string)
- `ux_pattern` (string)

### `get_screen_sections` (~71 tokens)

List the distinct sections of a page (hero, pricing cards, testimonial/feedback,
    footer, ...) so you can emulate a specific part. Each section links back to its page
    (parent_slug) and the product's design system (call get_design_system(site)).

Input parameters:

- `slug` (string, required)

### `list_user_flows` (~78 tokens)

List real product user flows (ordered screen journeys) — e.g. signup→dashboard,
    browse→checkout. Use to understand how a whole journey is structured before building it.
    Returns flow summaries; call get_user_flow(slug) for the full ordered screens.

Input parameters:

- `industry` (string)
- `query` (string)

### `get_user_flow` (~47 tokens)

Get one user flow with its ordered steps, each including full screen metadata and
    image_url. Returns an error dict if the flow is not found.

Input parameters:

- `slug` (string, required)

### `get_screen` (~28 tokens)

Get full metadata + image_url for a single screen by slug.

Input parameters:

- `slug` (string, required)

### `get_design_system` (~384 tokens)

Get a product's full, LLM-verified design system so you can match its exact look.
    Use this for "design like <product>" (e.g. site="Linear", "Stripe", "Figma").

    Returns (default): color_scheme; colors with named roles (background, text, primary,
    secondary, accent, link, button_bg, button_text); fonts + font_roles; type_scale;
    spacing; primary/secondary button; framework + personality. All hex normalized.

    Deep-decoded products additionally include measured button hover/focus states, a
    shadow elevation scale (card/overlay/subtle), motion durations + easings, the
    measured spacing scale, the brand's own CSS custom properties (css_vars), and
    Icon DNA (icons: style outline/filled/duotone/3d, grid, stroke_weight, corner) —
    all measured from the live page, not guessed. Match them exactly; pass the domain
    to generate_asset(style_from=...) to strike icons in this exact style.

    Your own private BYODS design systems (call list_my_design_systems) resolve first.

    format: leave empty for the raw token dict. Pass "all" to also get paste-ready
    DESIGN.md / Tailwind v4 / CSS variables / W3C tokens JSON, or a single format name
    ("tailwind", "css", "design_md", "tokens", "astryx") to get just that text.
    "astryx" returns a ready Meta-Astryx defineTheme TypeScript file (measured
    hover/press states + [light,dark] tuples baked in) — save it and run
    `npx astryx theme build` for production CSS.

Input parameters:

- `format` (string)
- `site` (string, required)

### `get_design_history` (~147 tokens)

Measured design CHANGE HISTORY for a live-decoded domain — the Decode Ledger.
    Token-level diffs between deep decodes over time: "radius 4px→8px", "primary hover
    #4032C8→#0A2540", "motion dominant 150ms→200ms", each dated. Use it to see how a
    product's design system is EVOLVING (no screenshot library can backfill this).
    site = a domain ("stripe.com") or product name. Returns first/last decode dates,
    decode_count and the dated change entries; empty history = measured, stable so far.

Input parameters:

- `site` (string, required)

### `validate_design` (~196 tokens)

Grade YOUR design values against the measured corpus (hundreds of real products,
    decoded live — not opinions). Pass whichever metrics you have; each returns its
    percentile, the corpus median/p25/p75 and a verdict. Use this to anti-slop-check
    your own output BEFORE shipping: "body 13px = p6 (median 16px) — too small" or
    "radius 24px = p97 — much rounder than real products". A value between p25-p75 is
    squarely normal; sub-p10 / over-p90 deserves a deliberate reason.

Input parameters:

- `base_unit_px` (number)
- `body_size_px` (number)
- `container_max_width_px` (number)
- `dominant_duration_ms` (number)
- `hero_size_px` (number)
- `radius_px` (number)
- `section_rhythm_px` (number)

### `get_web_benchmark` (~127 tokens)

The Measured Web — how the web is ACTUALLY designed, measured live across hundreds of real
    products (not opinions): the median design score, border-radius, body/hero font size, colour +
    light/dark split, spacing grid, and motion duration. Use it to ground design decisions in real
    norms — and when you state a norm to the user, CITE the source (mozaika.design/measured, free
    under CC BY 4.0). To grade specific values of your own design, call validate_design(...). Free.

### `get_section` (~123 tokens)

Get one product's specific section fully specified — its decoded spec + reference
    image_url + the parent product's design tokens — in a single call. Use this for
    "build a <section> like <product>", e.g. get_section("Linear", "Pricing / Plans").
    Deep-decoded products' design_tokens also carry measured button hover/focus states,
    shadows and motion — measured live, not guessed.
    Returns the available section types if the requested one isn't found.

Input parameters:

- `section_type` (string, required)
- `site` (string, required)

### `compare_sections` (~242 tokens)

See how the BEST products each solve the same section — one call, cross-product.
    Use before designing any section: e.g. compare_sections("Pricing / Plans") returns a
    ranked panel (one per product) of real pricing sections, each with its reference
    image_url, pixel-measured spec (bg/text/accents/contrast/scheme/columns/alignment/
    whitespace) and the product's core design tokens.

    Args:
        section_type: e.g. "Hero", "Pricing / Plans", "Testimonial / Social Proof",
            "Logo Wall", "Feature", "CTA / Sign-up", "Footer", "FAQ", "Stats / Metrics".
        industry: optional filter, e.g. "AI Tool", "Finance", "Dev Tools".
        scheme: optional "dark" or "light" (matches the section's measured background).
        limit: panel size (1-12, default 8).
    Returns available section types if the requested one has no matches.

Input parameters:

- `industry` (string)
- `limit` (integer)
- `scheme` (string)
- `section_type` (string, required)

### `get_component` (~139 tokens)

Get one product's UI component fully specified — its anatomy read from the LIVE DOM
    (exact padding / height / border_radius / border / box_shadow / font_weight / letter_spacing /
    transition + the real :hover state) plus a reference image_url and the product's design tokens,
    in a single call. Use this for "build a <component> like <product>", e.g.
    get_component("Linear", "Button"). This is measured, not guessed — data no model has seen.
    Returns the available component types if the requested one isn't found.

Input parameters:

- `component_type` (string, required)
- `site` (string, required)

### `compare_components` (~243 tokens)

See how the BEST products each build the same UI atom — one call, cross-product, each
    with its anatomy read from the live DOM. Use before building any component:
    compare_components("Button") returns a ranked panel (one per product) of real buttons, each
    with measured padding / radius / border / shadow / weight / hover — so you see the real
    divergence (Linear's pill+shadow vs Vercel's shadowless pill vs Supabase's 6px vs Mercury's
    32px) instead of guessing.

    Args:
        component_type: e.g. "Button", "Navigation", "Card", "Pricing Card", "Input", "Toggle".
        industry: optional filter, e.g. "Dev Tools", "Fintech".
        scheme: optional "dark" or "light" (matches the component's measured background).
        limit: panel size (1-12, default 8).
    Returns available component types if the requested one has no matches.

Input parameters:

- `component_type` (string, required)
- `industry` (string)
- `limit` (integer)
- `scheme` (string)

### `get_recipe` (~323 tokens)

The universal BUILD-KIT fetcher — the measured spec + code to reproduce a piece of UI.
    `recipe_type` selects which library across three families (all agent-ready through this one call):
      • COMPONENTS (decoded live from a real product's DOM — Mozaika's wedge): "Command Palette",
        "Dropdown Menu", "Dialog / Modal", "Login", "Data Table", "Onboarding Tour", "Navbar",
        "Logo Marquee", "Toast", "Date Picker", "Combobox" — returns the anatomy TREE (each node
        measured), the MOTION (open/close animation + easing a screenshot can't show), every STATE
        (empty/results/no-results/keyboard-selected), a webm of it running, and the design tokens.
      • EFFECTS (open-source WebGL hero backgrounds — Apache/MIT): "Hero Effect" → the shader's
        full config + fps + install command + license/NOTICE.
      • MOTION (open-source looping showcase templates — MIT): "Motion Showcase" → the template's
        full parameter surface + the exact Swiper/anime.js/Motion config + install.
    Use for "build a <thing> like <product>", e.g. get_recipe("Vercel", "Command Palette") or
    get_recipe("vanta", "Hero Effect"). A complete, uncopyable, measured build kit. Returns the
    available types if the requested one isn't found.

Input parameters:

- `recipe_type` (string, required)
- `site` (string, required)

### `compare_recipes` (~252 tokens)

See how the BEST products each build the same hard pattern — one call, cross-product, each
    with its measured anatomy tree + motion. Use before building any complex pattern:
    compare_recipes("Command Palette") returns a ranked panel (one per product) of real command
    palettes, each with its open animation, backdrop, radius, row-rhythm and captured states — so
    you see how Vercel (cmdkScaleIn) vs Supabase (backdrop-blur) vs Tailwind each solve it, instead
    of guessing at the invisible motion/state layer.

    Args:
        recipe_type: e.g. "Command Palette", "Pricing Table", "Toast", "Data Table", "Multi-step Form".
        industry: optional filter, e.g. "Dev Tools", "Fintech".
        scheme: optional "dark" or "light" (matches the recipe's measured overlay background).
        limit: panel size (1-12, default 8).
    Returns available recipe types if the requested one has no matches.

Input parameters:

- `industry` (string)
- `limit` (integer)
- `recipe_type` (string, required)
- `scheme` (string)

### `get_product` (~123 tokens)

Pull an entire product as an agent-ready build kit: the full multi-format design
    system (tokens + DESIGN.md/Tailwind/CSS/JSON), every curated page, every section grouped
    by type (with spec + image_url), plus any user flows. Deep-decoded products' tokens also
    carry measured button states, shadows, motion and the brand's own custom properties.
    Call this once for "clone/build like <product>" instead of many small calls. Your
    private BYODS systems resolve first.

Input parameters:

- `site` (string, required)

### `list_my_design_systems` (~73 tokens)

List YOUR private design systems (BYODS) — the sites you decoded into your own/your team's
    scope. Each item has name + slug; pass the slug/name to get_design_system or get_product to
    build against it. Returns an empty list if you have none (or aren't authenticated).

### `get_asset_pack` (~106 tokens)

Get a ready-made AI-generated icon pack (12 consistent icons) — e.g. a house style
    like 'clay-starter' / 'line-minimal-starter', or a pack generated in the MEASURED style
    of a decoded brand. Free and unmetered. Each image is a 1024px transparent PNG you can
    download and use directly (full commercial rights). Unknown slug → lists available packs.

Input parameters:

- `slug` (string, required)

### `generate_asset` (~162 tokens)

Generate ON-BRAND icons with AI: subjects (1-12 short nouns, e.g. ["settings gear",
    "credit card"]) rendered in ONE consistent style. style_from is either a decoded domain
    ("stripe.com" — the icons match that brand's MEASURED style: accents, stroke, corners)
    or a house style key ("skeuomorph"). INCLUDED with your account — free accounts get a
    real daily allowance (enough for a full set), Pro/Lifetime a high one; QA-failed images
    never count. Returns image_url per subject (1024px transparent PNG) + a zip link.

Input parameters:

- `format` (string)
- `style_from` (string, required)
- `subjects` (array, required)

### `get_score` (~215 tokens)

Design Score: a 0-100 design audit MEASURED from the site's live DOM (real WCAG
    contrast pairs, detected type ladder, spacing grid, forced hover states, motion) —
    scored against the whole measured-web corpus ("top N% of M systems"). Free to read.
    Use it to audit the site YOU are building or any competitor: returns dimension scores
    (typography/color/spacing/motion), UI+UX headline scores, plain-language verdicts,
    the raw measured evidence chips, and a prioritized fix list — each fix anchored to an
    evidence index (agent-ready: why + how_to you can apply directly to the codebase).
    Not scored yet (or refresh=true)? A scan starts (~60-90s) using your account email —
    call get_score again shortly. Full fix payload requires Pro/Lifetime; everyone gets
    scores, evidence, verdicts and one complete sample fix.

Input parameters:

- `refresh` (boolean)
- `site` (string, required)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/design-mozaika-mozaika/mozaika#diagnostics

## Score history

- 2026-08-03: 73
- 2026-08-02: 72
- 2026-08-01: 72
- 2026-07-31: 71
- 2026-07-30: 64
- 2026-07-29: 64
- 2026-07-28: 63
- 2026-07-27: 62
- 2026-07-26: 62

## Links

- Remote endpoint: https://mozaika.design/mcp
- Authorisation metadata: https://mozaika.design/.well-known/oauth-protected-resource/mcp
- Website: https://mozaika.design/
- Changelog RSS feed: https://verifymcp.io/servers/design-mozaika-mozaika/mozaika/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/design-mozaika-mozaika/mozaika/changelog.json
- HTML version of this page: https://verifymcp.io/servers/design-mozaika-mozaika/mozaika