Mozaika
REMOTE · MOZAIKA.DESIGN · SCANNED SEP 21
Measured design systems decoded from 588 real products, for coding agents.
Available components
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. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability79
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4862 tokens (~211/item across 23 items; 23 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage67
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 23 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 24 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Mozaika MCP server?
Mozaika is a hosted endpoint at https://mozaika.design/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mozaika.design
claude mcp add --transport http design-mozaika-mozaika 'https://mozaika.design/mcp'
{
"mcpServers": {
"design-mozaika-mozaika": {
"url": "https://mozaika.design/mcp"
}
}
} {
"servers": {
"design-mozaika-mozaika": {
"type": "http",
"url": "https://mozaika.design/mcp"
}
}
} [mcp_servers.design-mozaika-mozaika] url = "https://mozaika.design/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"design-mozaika-mozaika": {
"type": "remote",
"url": "https://mozaika.design/mcp",
"enabled": true
}
}
} openclaw mcp add design-mozaika-mozaika --url 'https://mozaika.design/mcp' --transport streamable-http
mcp_servers:
design-mozaika-mozaika:
url: "https://mozaika.design/mcp" {
"McpServers": {
"design-mozaika-mozaika": {
"Transport": "http",
"Url": "https://mozaika.design/mcp"
}
}
} assistant mcp add design-mozaika-mozaika -t streamable-http -u 'https://mozaika.design/mcp'
{
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 26 Aug 26 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 0
- Stability: 0.97 → pass security
- 24 Aug 26 +1
- Tool “compare_sections” rewrote its description, which is the text the model reads security
- Tool “search_screens” rewrote its description, which is the text the model reads security
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 9 Aug 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “compare_recipes” rewrote its description, which is the text the model reads security
- Schema quality: 177 → 202 ▼ functional
- First check of Schema quality: 100 functional
- New prompt “build_pattern” functional
- New prompt “design_like” functional
- New prompt “polish_screen” functional
- New tool “audit_code” functional
- 7 Aug 26 0
- Schema quality: 3479 → 3906 ▼ functional
- The server no longer declares the “experimental” capability functional
- Server version: 1.28.1 → 1.29.0 functional
- New tool “get_design_drift” functional
- New tool “list_design_changes” functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Probed https://mozaika.design/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mozaika.design | CN=YE1,O=Let's Encrypt,C=US | 26 Aug 2026 | 24 Nov 2026 | ECDSA 256 | ECDSA-SHA384 | 6a2da274b0f78ac38c0a8ad2221e7ba08a6 |
| SANs: mozaika.design | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mozaika.design. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| design. | present | 27199 | 8 | Verified |
| mozaika.design. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Challenged, unverified
The endpoint asked for a token, but we could not retrieve and validate the RFC 9728 metadata that tells a client how to obtain one.
| Result | Challenged, unverified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer error="invalid_token"
Bearer error="invalid_token" | Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
Protected resource metadata
| Retrieved | No |
|---|---|
| Problem | no_resource_metadata |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mozaika.design/mcp | Verified | 200 | |
| http (plaintext) | http://mozaika.design/mcp | HTTPS enforced | 308 | https://mozaika.design/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
audit_code ~255
When the user says a screen looks generic, cheap or off and you need to know WHY — paste the code and get numbers back. This is the one tool here that reads YOUR work instead of someone else's product. Give it the component's CSS, or the JSX/HTML with its class attributes (Tailwind utilities are read on the default scale), or both. It measures what the paste actually contains — type ladder, spacing grid, radii, transition timing, container width — grades each against hundreds of live-decoded real products, and returns findings worst-first, each with the value, its percentile, the corpus median and the change to make. It only ever reports what it could genuinely read, and lists what it could not: it sees the source, not the rendered screen, so colour contrast, hover/focus states and runtime-resolved variables are out of reach — for a public URL, get_score(domain) reads those from the live DOM instead. Free and unmetered. Args: code: the CSS and/or markup to audit. Paste the real thing, not a summary.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | – |
No output schema declared.
No examples provided.
compare_components ~243
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.
| Name | Type | Req | Description |
|---|---|---|---|
| component_type | string | yes | – |
| industry | string | – | – |
| limit | integer | – | – |
| scheme | string | – | – |
No output schema declared.
No examples provided.
compare_recipes ~285
See how the BEST products each build the same hard pattern — one call, cross-product. Use before building any complex pattern: compare_recipes("Command Palette") returns a ranked panel (one per product), each entry carrying the at-a-glance layer you pick a reference by — overlay radius, whether it ships a shadow, backdrop filter, the open-motion string and the names of the captured states — so you see that Vercel animates the open where Supabase blurs the backdrop, instead of guessing at the invisible motion/state layer. This is the comparison view; call get_recipe(site, recipe_type) on the one you choose for its full measured anatomy tree, easings, state captures and video. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| industry | string | – | – |
| limit | integer | – | – |
| recipe_type | string | yes | – |
| scheme | string | – | – |
No output schema declared.
No examples provided.
compare_sections ~243
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", "Fintech", "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.
| Name | Type | Req | Description |
|---|---|---|---|
| industry | string | – | – |
| limit | integer | – | – |
| scheme | string | – | – |
| section_type | string | yes | – |
No output schema declared.
No examples provided.
generate_asset ~162
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.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | – | – |
| style_from | string | yes | – |
| subjects | array | yes | – |
No output schema declared.
No examples provided.
get_asset_pack ~106
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.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | – |
No output schema declared.
No examples provided.
get_component ~139
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.
| Name | Type | Req | Description |
|---|---|---|---|
| component_type | string | yes | – |
| site | string | yes | – |
No output schema declared.
No examples provided.
get_design_drift ~238
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.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
No output schema declared.
No examples provided.
get_design_history ~147
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.
| Name | Type | Req | Description |
|---|---|---|---|
| site | string | yes | – |
No output schema declared.
No examples provided.
get_design_system ~384
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.
| Name | Type | Req | Description |
|---|---|---|---|
| format | string | – | – |
| site | string | yes | – |
No output schema declared.
No examples provided.
get_product ~123
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.
| Name | Type | Req | Description |
|---|---|---|---|
| site | string | yes | – |
No output schema declared.
No examples provided.
get_recipe ~323
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.
| Name | Type | Req | Description |
|---|---|---|---|
| recipe_type | string | yes | – |
| site | string | yes | – |
No output schema declared.
No examples provided.
get_score ~215
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.
| Name | Type | Req | Description |
|---|---|---|---|
| refresh | boolean | – | – |
| site | string | yes | – |
No output schema declared.
No examples provided.
get_screen ~28
Get full metadata + image_url for a single screen by slug.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | – |
No output schema declared.
No examples provided.
get_screen_sections ~71
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)).
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | – |
No output schema declared.
No examples provided.
get_section ~123
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.
| Name | Type | Req | Description |
|---|---|---|---|
| section_type | string | yes | – |
| site | string | yes | – |
No output schema declared.
No examples provided.
get_user_flow ~47
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.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | – |
No output schema declared.
No examples provided.
get_web_benchmark ~127
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_design_changes ~189
What actually changed in the web's design systems lately — the nightly Drift Ledger feed. Mozaika re-measures ~100 of the most-referenced products every night and records a dated row per product even when nothing moved, so this is a real time series, not a guess: how many products held every token, which ones shipped a change that stuck (with before/after values and the date), and which design tokens move most often across the web. Use it to answer "does anyone actually redesign?", to ground a claim about design churn with a citable measurement, or to spot that a reference you rely on has moved. For one product, call get_design_drift(domain). Args: limit: how many confirmed changes to return (1-40, default 10). Free.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
No output schema declared.
No examples provided.
list_my_design_systems ~73
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).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_user_flows ~78
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.
| Name | Type | Req | Description |
|---|---|---|---|
| industry | string | – | – |
| query | string | – | – |
No output schema declared.
No examples provided.
search_screens ~605
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). `query` alone works well — the filters below are optional. A value outside the lists is treated as a HINT (it ranks, it does not exclude), and if the filters together match nothing they relax rather than hand you an empty list. So a near-miss costs you nothing; spelling one exactly is simply more precise. Args: query: free text, e.g. "fintech onboarding", "dark dashboard", "Linear". page_type: one of Billing · Camera / Capture · Changelog · Chat / Assistant · Checkout · Dashboard · Detail · Docs · Editor · Empty State · Feed · Integrations · Landing Page · Log In · Map · Onboarding · Paywall · Player · Pricing · Profile & Account · Search & Results · Settings · Sign Up · Stories. ux_pattern: e.g. "Dark Mode", "Filter & Sorting", "Stats / KPIs", "Data Table", "Command Palette", "Multi-step Form", "Sidebar Navigation", "Bento Grid", "Progressive Onboarding", "Empty State", "Kanban", "Master-Detail", "WYSIWYG". industry: one of AI · Analytics · Communication · Consumer · Creator · Data · Design · Dev Tools · E-commerce · Entertainment · Fintech · Health & Fitness · Productivity · Real Estate · Security · Travel & Local. 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 Palet…
| Name | Type | Req | Description |
|---|---|---|---|
| industry | string | – | – |
| kind | string | – | – |
| limit | integer | – | – |
| page_type | string | – | – |
| platform | string | – | – |
| query | string | – | – |
| section_type | string | – | – |
| ux_pattern | string | – | – |
No output schema declared.
No examples provided.
validate_design ~196
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | – | – |
No output schema declared.
No examples provided.
What is the Mozaika MCP server?
Mozaika is an MCP server listed in the public MCP registry as design.mozaika/mozaika. Measured design systems decoded from 588 real products, for coding agents. This page covers its hosted endpoint (https://mozaika.design/mcp).
Is the Mozaika MCP server safe to use?
Mozaika scores 89 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Mozaika MCP server expose?
Mozaika exposes 23 tools: search_screens, get_screen_sections, list_user_flows, get_user_flow, get_screen, and 18 more. Their descriptions and schemas cost roughly 4,400 tokens of context every time the server is loaded.
Does the Mozaika MCP server require authentication?
Yes. Mozaika asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Mozaika MCP server still maintained?
Mozaika is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.