Measured design systems decoded from 588 real products, for coding agents.
Scored across 23 tools
Multiple retrieval families overlap in subtle ways: compare_components vs get_component vs get_recipe vs get_section, and get_design_system vs get_product vs search_screens. The descriptions do clarify distinctions (cross-product panel vs single-product spec, component vs section vs recipe), but an agent could still misselect among the many 'get' and 'compare' tools.
All tool names use lowercase snake_case and follow predictable verb_noun patterns: get_, list_, compare_, search_, validate_, audit_, generate_. The convention is applied consistently across the entire set.
23 tools is on the heavy side for a design-reference/measurement server. While the domain is broad, several tools overlap in purpose, making the count feel bloated rather than tightly scoped.
The surface covers design discovery, reference retrieval, comparison, auditing, asset generation, drift tracking, and user flows comprehensively. Minor gaps exist around managing private design systems (no create/update/delete tools), but agents can work around this.
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 | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses that it only reports what it could genuinely read and lists what it could not, that it sees source not the rendered screen (so contrast, hover/focus, runtime variables are out of reach), and that it is free and unmetered. This is rich behavioural context the annotations do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the triggering scenario and the return shape before the args block, and every sentence carries usable information (what it measures, what it returns, its limits). It runs somewhat long for a single-parameter tool, but there is little outright waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in and describes the return value precisely (findings worst-first with value, percentile, corpus median, and the change to make). It also covers inputs, limits, and the alternative for rendered-DOM checks, leaving nothing essential unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'code' param, so the description must compensate: it specifies accepting CSS, JSX/HTML with class attributes, or both, notes Tailwind utilities are read on the default scale, and warns to 'paste the real thing, not a summary.' That adds substantial meaning beyond the bare string schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — measure a code paste and return graded numbers — and enumerates the exact dimensions audited (type ladder, spacing grid, radii, transition timing, container width). It explicitly differentiates itself from siblings: 'the one tool here that reads YOUR work instead of someone else's product,' and routes DOM-dependent checks to get_score(domain).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete trigger ('when the user says a screen looks generic, cheap or off and you need to know WHY') and an explicit alternative with its condition ('for a public URL, get_score(domain) reads those from the live DOM instead'). It also states what the tool cannot cover, steering the agent away when those are the goal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scheme | No | ||
| industry | No | ||
| component_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only safety profile is covered. The description adds genuine context beyond them: anatomy is read from the live DOM, results are a ranked per-product panel, and it discloses the fallback behavior when no component matches. It doesn't mention caching or refresh semantics, which keeps it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the pre-build trigger are front-loaded, then args. The divergence illustration (Linear's pill+shadow vs Vercel's shadowless pill) is somewhat verbose but earns its place by showing what the output looks like.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the return shape (one ranked panel per product with measured padding/radius/border/shadow/weight/hover) plus the no-match fallback. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameters — and it does: component_type with six concrete examples, industry with example values, scheme as "dark"/"light" including the meaningful note that it matches the measured background, and limit with its range (1-12) and default (8).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (UI atoms across products), and even distinguishes itself from data-fetching siblings by emphasizing cross-product, live-DOM anatomy. An agent can tell it apart from get_component or compare_sections 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use before building any component" gives an explicit trigger context. It does not, however, name the alternative (e.g. get_component for a single product) or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scheme | No | ||
| industry | No | ||
| recipe_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context beyond that — what the panel entries contain (overlay radius, shadow, backdrop filter, open-motion string, state names) and an edge-case behavior ('Returns available recipe types if the requested one has no matches'). It stops short of stating result size caps or ranking criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose then usage then args, and every section is relevant. The middle sentence is dense and runs long, but the detail is substantive rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain the return shape — and it does, describing the ranked panel, per-entry fields, and the no-match fallback. Combined with the full parameter coverage, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden — and it does: recipe_type with five concrete examples, industry as an optional filter with examples, scheme restricted to 'dark'/'light' with its matching semantics, and limit as panel size 1-12 default 8. This supplies meaning the schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('compare_recipes' returns a ranked cross-product panel) with explicit scope: 'one call, cross-product.' It distinguishes itself from the sibling get_recipe by naming it and stating what each returns, so an agent can pick without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('Use before building any complex pattern') and an explicit alternative with the selecting condition: 'call get_recipe(site, recipe_type) on the one you choose for its full measured anatomy tree.' The when/when-not split is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scheme | No | ||
| industry | No | ||
| section_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds substantial context beyond that: it explains the return shape (ranked panel, one per product, image_url, pixel-measured spec, core design tokens) and the no-match fallback behavior (returns available section types).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a usage trigger, then a clean Args block. Every sentence earns its place, though the argument examples are somewhat verbose given the schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by describing the return payload and the no-match fallback. For a read-only comparison tool with fully documented params, nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the full burden — and it does. Each of the 4 parameters gets meaning beyond the schema: enumerated section_type values, industry examples, scheme semantics ('matches the section's measured background'), and the limit range (1-12, default 8).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare), resource (sections), and distinctive scope: 'how the BEST products each solve the same section — one call, cross-product.' This differentiates it from siblings like compare_components and compare_recipes without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use before designing any section' gives explicit timing context and a concrete invocation example. It does not, however, name alternatives (e.g., when to prefer compare_components or get_section), so it stops short of the when-not/alternative bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| format | No | icon | |
| subjects | Yes | ||
| style_from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is included with the account with specific allowances for free vs Pro/Lifetime, QA-failed images never count, and it returns image URLs and a zip link. This goes beyond basic expectations and covers operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of three dense sentences, each adding value: purpose and subjects, style_from explanation, and account/QA/return details. It is somewhat long but contains no filler; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (image_url per subject as 1024px transparent PNG plus a zip link). It also covers usage context, account allowances, and the QA behavior, making it complete for an AI generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description compensates by explaining 'subjects' as 1-12 short nouns with concrete examples, and 'style_from' as either a decoded domain or house style key. The 'format' parameter is not explained, but it has a default value and is less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates ON-BRAND icons with AI, specifies the subjects input and the style_from parameter, and differentiates it from sibling tools (which are all get/compare/validate operations). It names the specific resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: subjects should be 1-12 short nouns, and style_from can be a domain or house style key. It also clarifies account-based allowances. However, it does not explicitly state when to use this tool instead of alternatives like get_asset_pack, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond that with genuinely useful behavior: cost model ('free and unmetered'), licensing ('full commercial rights'), output format ('1024px transparent PNG'), and the unknown-slug fallback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each front-loaded with a distinct fact (what it returns, cost/rights, output format, error behavior). No repetition of the tool name or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of explaining the return payload (12 PNGs, 1024px, transparent) and the fallback listing behavior, which is sufficient for a single-parameter read tool. Minor omission: no note on pack catalog size or whether slugs are case-sensitive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required parameter, so the description must carry the load. It does: it names example slugs ('clay-starter', 'line-minimal-starter'), describes the MEASURED-style variant, and specifies the behavior for an unknown slug value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Get a ready-made AI-generated icon pack (12 consistent icons)') with concrete examples of the slug space and a clear contrast to the generative sibling generate_asset. An agent can tell immediately this is a retrieval tool, not a generation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context (free, unmetered, ready-made packs) and a procedural fallback: 'Unknown slug → lists available packs,' which tells the agent how to recover from a bad argument. It stops short of explicitly naming generate_asset as the alternative when a custom/customized icon is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 like ", 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 | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| component_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds real behavioral context beyond that: the data is measured from the LIVE DOM rather than guessed, and it discloses fallback behavior ('returns the available component types if the requested one isn't found').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then the use case, then the caveat. The long enumerated field list is informative rather than filler, though it makes the middle sentence dense; every sentence still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return burden and does so (anatomy fields, image_url, design tokens), and it covers the not-found error path. Complete enough to call correctly, though parameter value formats remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and the example get_component('Linear', 'Button') maps positionally to site='Linear' (a product name) and component_type='Button', clarifying both required params' expected values. It still doesn't define what forms 'site' accepts (name vs domain) or list valid component_type values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get one product's UI component fully specified') and enumerates exactly what comes back (anatomy from the live DOM, image_url, design tokens). It is clearly about a single component, which separates it from get_screen/get_section, though it never explicitly names a sibling to contrast against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger use case ('build a <component> like <product>') plus an example invocation, so the agent knows when to reach for it. It stops short of naming alternatives or stating when-not-to-use (e.g., versus get_design_system or compare_components).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by disclosing the operational model (nightly re-measurement of most-referenced products from live DOM, dated ledger) and what each verdict means, including the do_not_hardcode signal. That is substantial behavioral context the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core question, then uses a tight bulleted breakdown of the three verdicts, so each sentence earns its place. Minor marketing flourish ('what a screenshot never can') and the trailing 'Free.' are slight padding but do not obscure the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain the return values, and the verdict taxonomy (held/shifted/unstable plus do_not_hardcode) does the heavy lifting. It is complete enough to call correctly, though the broader ledger/before-after payload shape is only sketched rather than fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage the description must carry the single parameter, and it does: it specifies the format ('bare domain, no scheme') and supplies concrete examples ('stripe.com', 'linear.app'). This meaningfully compensates for the empty schema, though it stops short of adding further constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific question it answers ('Has this product's design system CHANGED since it was decoded — and which of its numbers are safe to hard-code') with a clear verb+resource, and explicitly differentiates from the sibling: 'get_design_system(site) gives the spec, this gives its shelf life.' An agent can pick it apart from the other design tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use instructions ('Call this BEFORE building against a cached spec, and before baking any measured value into a token file') and names its complementary sibling. It omits any explicit when-not-to-use or exclusions, which keeps it from a full 5, but the routing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds real behavior: what gets returned (first/last decode dates, decode_count, dated change entries) and the meaning of an empty result ("measured, stable so far"). That empty-case semantics is genuinely useful beyond the annotations, though it omits any volume/pagination limits for long histories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core identity and the return shape up front; the parenthetical examples (radius, hover color, motion duration) are dense but they earn their place by showing the diff granularity. Slightly longer than needed — the "live-decoded domain / Decode Ledger" framing and the trailing aside about screenshot libraries could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations about returns, the description fully specifies what comes back (first/last decode dates, decode_count, dated entries) and the empty-history case. Nothing an agent needs in order to call this correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for the single `site` parameter, and it does: "a domain ('stripe.com') or product name" with an example. This resolves the main ambiguity (domain vs product key) but leaves unresolved what happens on an unknown site.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (measured design change history / Decode Ledger) and explains it concretely as token-level diffs between deep decodes over time, with inline examples of the diff format. It does not, however, distinguish itself from close siblings like list_design_changes or get_design_drift, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it to see how a product's design system is EVOLVING (no screenshot library can backfill this)" gives a clear when-to-use rationale and even a contrast against an alternative source of truth. It stops short of naming sibling tools or stating exclusions, so no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a product's full, LLM-verified design system so you can match its exact look. Use this for "design like " (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 | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/openWorldHint, so the description carries the burden and does so richly: it enumerates the default return shape, the extra measured fields for deep-decoded products, normalization ('All hex normalized'), and that data is 'measured from the live page, not guessed'. It also discloses the astryx build workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage, then return values, then the format option — a logical order with no filler sentences. It is fairly long and the format paragraph is dense, but every sentence conveys distinct operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully compensates by describing the returned token groups, the deep-decoded extras, and the alternate text outputs per format. An agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for 'format' by spelling out empty, 'all', and each named format ('tailwind', 'css', 'design_md', 'tokens', 'astryx') with what each returns. The 'site' parameter is only conveyed by example ('site="Linear"'), which is adequate but less explicit than the format documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Get a product's full, LLM-verified design system') and states the goal ('match its exact look'). It clearly differentiates itself from siblings like list_my_design_systems and generate_asset by naming them in their proper roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger phrase ('Use this for "design like <product>"') with concrete examples (Linear, Stripe, Figma). It also explains resolution order ('Your own private BYODS design systems ... resolve first') and points to the downstream call generate_asset(style_from=...) for icon matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 " instead of many small calls. Your private BYODS systems resolve first.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds genuinely useful behavior beyond that: deep-decoded products carry extra token data, and private BYODS systems resolve first. However, it omits response size/pagination behavior for what is clearly a large aggregate payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The payload contents are front-loaded, which is good, but the prose leans on proprietary jargon ('agent-ready', 'deep-decoded', 'BYODS') that spends words without adding precision. It is dense and mid-length rather than tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry the return-value burden — and it does describe the returned assets reasonably well. But it leaves the single input underspecified and says nothing about payload size, limits, or pagination for an aggregate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, 'site', at 0% schema description coverage, and the description never explains it — no format (URL vs. slug vs. product name), no resolution semantics despite mentioning BYODS resolution. The sole input is left fully ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (pull) and resource (product) and enumerates the exact payload: multi-format design system, pages, sections grouped by type, and user flows. It's clearly a bundle in contrast to the granular siblings, but it never explicitly names those siblings (get_design_system, get_screen_sections, get_user_flow) to help an agent choose between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Call this once for 'clone/build like <product>' instead of many small calls" gives an explicit use condition and names the alternative pattern (many small calls). It's clear context without explicit exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 like ", 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 | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| recipe_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely useful behavior: it enumerates the returned artifacts (anatomy tree, motion, states, webm, tokens) and discloses fallback behavior when a requested type is missing. Marketing framing dilutes it slightly, but the extra context is real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and bullets aid scanning, but the text is bloated with promotional filler ("Mozaika's wedge", "A complete, uncopyable, measured build kit") and an exhaustive catalog that is partly redundant listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 describe returns — it does so in detail. However, with zero schema description coverage, the unexplained 'site' parameter and absent tie-breakers against siblings leave the definition incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for both required parameters, so the description must carry the full burden. It compensates well for recipe_type by listing accepted values and families, but the 'site' parameter is never explained semantically beyond appearing in the examples, leaving a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource (fetch a measured spec + code 'build kit' for a piece of UI) and details the three content families it returns. It is clear what the tool does, but it never names or contrasts itself against close siblings like get_component, get_asset_pack, or compare_recipes, so the agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage trigger ("Use for 'build a <thing> like <product>'") with concrete call examples, which is strong context. It stops short of exclusions or naming alternatives, so it does not reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosure. It reveals scan duration (60-90s), dependency on account email, need to call again for results, and free vs Pro/Lifetime access limits. This is comprehensive and honest about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, starting with a bold summary and expanding into details about outputs, scan process, and access tiers. Every sentence adds value, though slightly longer than minimal; the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async scan, paywall, rich output), the description covers all essential aspects: what it returns (scores, evidence, verdicts, fixes), how to handle un-scored sites, account requirements, and limitations. Without an output schema, this description provides a complete mental model for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'refresh=true' triggers a new scan, and the 'site' parameter is implicit as the URL to audit. While 'site' format isn't explicitly stated, the tool's purpose makes it obvious; the refresh behavior is explicitly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a 0-100 design audit measured from the site's live DOM, with specific metrics (WCAG contrast, type ladder, spacing, motion). It distinguishes itself from sibling tools (get_component, compare_*) by focusing on scoring/auditing rather than retrieval or comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'audit the site YOU are building or any competitor.' It also explains the refresh behavior and first-time scan process. While it doesn't name alternative tools, the use case is clearly scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata + image_url for a single screen by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that the return includes metadata and image_url, which is useful context, but says nothing about error behavior for unknown slugs or response size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with the resource and lookup key front-loaded; nothing is padded. It is close to minimal but earns its words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param read tool with annotations and no output schema, the description roughly conveys the return shape. It stops short of explaining slug format or failure behavior, which leaves minor gaps an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'slug' parameter, so the description is the only source of meaning — it tells the agent slug is the lookup key. However, it adds no format details (e.g., URL-style slug, case sensitivity) beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (screen) plus the scope ('a single screen by slug'), and names the returned content ('metadata + image_url'). This distinguishes it from list/search siblings like search_screens and get_screen_sections, though it doesn't name an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus search_screens, get_screen_sections, or get_section. The phrase 'by slug' implies it's a direct lookup, but no conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds useful structural context: each section links back to its page via parent_slug and to the product design system, plus a recommended follow-up call. It does not describe return shape, section count limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the resource and its examples front-loaded ahead of the follow-up guidance. Slightly dense with parenthetical examples but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param read tool with no output schema, the description covers what is returned (distinct page sections), the cross-references in each result, and the related design-system call. Only the input slug's meaning and any result-size behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single required parameter 'slug' is never explained in the description. The text mentions parent_slug only as an output field, not as the input identifier. The meaning of the input is inferable from 'sections of a page' but not stated, leaving the one required param undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (distinct sections of a page) and enumerates concrete examples (hero, pricing cards, testimonial/feedback, footer). It implicitly contrasts with the singular get_section and the comparative compare_sections by scoping to a page's full section set, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a motive ('so you can emulate a specific part') and a follow-up action (call get_design_system(site)), which implies usage context. However, it offers no explicit when-to-use vs when-not, and no comparison to get_section or compare_sections, so the routing decision is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 like ", 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 | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| section_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the fallback behavior ('Returns the available section types if the requested one isn't found') and the note that deep-decoded tokens include measured hover/focus states, shadows, and motion. No auth or rate-limit context, but the behavioral disclosure is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and payload are front-loaded, and the example plus fallback note each earn their place. Slightly padded with em-dash asides, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does list what comes back. The fallback-return behavior is disclosed. Missing only minor details such as output size/limits or what the 'available section types' response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does by showing an example call, get_section("Linear", "Pricing / Plans"), which clarifies that 'site' is a product name and 'section_type' is a path-like label. It doesn't define the valid value space or case sensitivity, but the format is far clearer than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get one product's specific section') and enumerates the payload contents (decoded spec, reference image_url, parent product's design tokens), which cleanly separates it from siblings like get_component, get_screen, and get_screen_sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage scenario ('build a <section> like <product>') with an example invocation, which tells the agent when this tool fits. It stops short of naming alternative siblings (e.g., get_component or get_screen_sections) for adjacent needs, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is in disclosing the not-found behavior ('Returns an error dict if the flow is not found') and the result shape (ordered steps with screen metadata and image_url). That is genuinely useful disclosure beyond the annotations, though it says nothing about missing/incomplete flows or step ordering guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with what is returned and followed by the error case. No filler, no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully summarizes the returned structure and the error case, and the read-only annotations cover safety. The remaining gaps are the undocumented slug argument and the absent pointer to list_user_flows as the way to discover valid slugs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter 'slug' has no schema description, so the description must compensate — but it never explains what 'slug' identifies, its format, or where to obtain it. Because there is only one param the burden is modest, but the gap is real.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one user flow') and even enumerates the payload (ordered steps, screen metadata, image_url), so the agent knows exactly what it returns. It does not explicitly contrast itself with the sibling list_user_flows, so the singular-vs-list distinction must be inferred from the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus list_user_flows, and no indication of where the required slug comes from (presumably a prior list call). Usage is only implied by the name and the 'one' quantifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not carry: the data source and license (CC BY 4.0), the attribution obligation when citing a norm to a user, and that access is free. It does not describe freshness, caching, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The metric list and the validate_design pointer are front-loaded and earn their place, but the promotional register ('ACTUALLY', 'not opinions', capitalised emphasis) inflates the text and adds no selection value. It is one dense block rather than wastefully long, but a portion of it is hype rather than information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return content, and it does by enumerating the benchmark fields an agent can expect. The one remaining gap is the response's structural form (single object vs. per-metric records) and any freshness caveat, but for a zero-parameter read tool this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema description coverage is 100%, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (live-measured web design norms) and enumerates the exact metrics returned — median design score, border-radius, font sizes, colour split, spacing grid, motion duration. It also distinguishes itself from the sibling validate_design. It stops short of a clean verb+resource framing ('get_web_benchmark' is never restated) because the opening is marketing copy rather than a functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use it ('ground design decisions in real norms') and names the alternative for a related-but-different job ('To grade specific values of your own design, call validate_design(...)'). No explicit when-not-to-use or negative conditions are given, but the routing guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior — nightly refresh cadence, a dated row recorded even when nothing changed, and the shape of returned data (before/after values, dates, counts). It doesn't mention pagination or result ordering, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core answer (the Drift Ledger feed) before the mechanism and use cases. Mostly earns its length, but the 'real time series, not a guess' flourish is promotional padding that could be cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only list with no output schema, the description covers what is returned and how fresh it is. Missing only minor operational detail such as ordering or how to page beyond the 40-item cap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema shows only a default, but the description supplies the missing bound ('1-40, default 10') and states the semantics — confirmed changes returned. That compensates well for a single parameter, though it's a modest addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: the nightly-measured record of design changes across ~100 reference products. It explicitly differentiates from the sibling get_design_drift by noting that tool is for a single product, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use cases (answer 'does anyone redesign?', ground a churn claim with a citation, detect a reference has moved) and names the alternative tool plus the condition selecting it ('For one product, call get_design_drift(domain)').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, yet the description still adds real behavior: the empty-list case and the unauthenticated failure mode. This is exactly the kind of context annotations can't express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the scope-defining phrase ('YOUR private design systems') is front-loaded. Each sentence carries distinct information: identity/scope, then consumption path, then edge behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly compensates by describing the return shape (name + slug) and the empty-list outcome. Nothing an agent needs in order to call and use this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, which is the baseline for a 4. The description also clarifies the shape of each returned item (name + slug), which is the only 'parameter-like' semantic an agent needs to know to consume the output correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) plus a precisely scoped resource ('YOUR private design systems (BYODS) — the sites you decoded into your own/your team's scope'). This cleanly separates it from get_design_system (fetch a single system) and from generic listing siblings. An agent knows exactly what this returns without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent what to do with the output: 'pass the slug/name to get_design_system or get_product to build against it,' naming the two natural follow-up tools. It stops short of a full when-to-use/when-not statement against the broader catalog, but the routing intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| industry | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered externally. The description usefully adds that this returns summaries rather than full flows, but says nothing about filtering behavior, result volume, or ordering of the list itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler; the identity of the resource and the routing instruction are both front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description should convey what comes back; 'Returns flow summaries' is a bare minimum that doesn't describe the shape, count, or pagination. Combined with two completely undocumented filter parameters, the definition is adequate but leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters ('query', 'industry') are bare strings with titles only. The description never mentions either parameter, so it fails to compensate for the schema gap and an agent cannot know what values or filtering semantics to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List real product user flows') and immediately defines the resource with a concrete gloss ('ordered screen journeys') plus examples (signup→dashboard, browse→checkout). This clearly distinguishes it from the sibling get_user_flow, which returns the drill-down detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context ('Use to understand how a whole journey is structured before building it') and routes to the alternative with an explicit condition: 'call get_user_flow(slug) for the full ordered screens.' No explicit when-not-to-use guidance, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 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".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | page | |
| limit | No | ||
| query | No | ||
| industry | No | ||
| platform | No | ||
| page_type | No | ||
| ux_pattern | No | ||
| section_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that — the return payload shape, the measured/retina preference flags, and the important relaxation behavior (filters that match nothing relax instead of returning empty). However, it says nothing about pagination, result ordering, or rate limits, so it is additive but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the before-you-design rule, then returns, then the filter-semantics caveat, then Args. Every section earns its place given the zero-coverage schema, though the long inline enumeration lists make it heavier than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly summarizes the return shape (description, UX patterns, UI elements, colors, palette, image_url, measured/retina). For an 8-parameter, zero-coverage search tool this is close to complete; only pagination/ordering behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden — and it does: it enumerates the allowed page_type, industry and platform values, gives examples for query/ux_pattern, explains limit bounds (1-40, default 12), defines kind's four modes, and clarifies how section_type pairs with kind. This is exactly what an untyped 8-param schema needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search real product UI screens) plus the resource's scope (design reference), and differentiates it from retrieval siblings like get_screen/get_screen_sections by establishing this as the discovery entry point. An agent knows immediately what it gets back: structured metadata plus an image_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prescriptive timing: "Use this BEFORE designing any page/component." It further tells the agent that `query` alone works and that filters are optional, and that near-miss filter values rank rather than exclude — effectively telling the agent when it is safe to skip parameters entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| radius_px | No | ||
| base_unit_px | No | ||
| body_size_px | No | ||
| hero_size_px | No | ||
| section_rhythm_px | No | ||
| dominant_duration_ms | No | ||
| container_max_width_px | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnly and not open-world, so the bar is lower, yet the description adds real behavioral context: the corpus is measured rather than opinion-based, and 'Pass whichever metrics you have' clarifies that partial input is valid — important since all 7 params are optional with 0/-1 defaults. It stops short of stating what happens with default/omitted values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then the use case, then interpretation guidance — a logical order with no filler sentences. The inline quoted examples are illustrative rather than redundant, though the description runs slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 correctly takes on return-value explanation (percentile, corpus median/p25/p75, verdict) and passes the interpretation thresholds. It is nearly complete for a 7-parameter tool, with the remaining gap being the meaning of undocumented parameters and their default sentinels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load. It explains the return semantics per metric (percentile, median/p25/p75, verdict) and implies px/ms units, which helps, but it never defines base_unit_px, section_rhythm_px, hero_size_px or dominant_duration_ms, nor what the sentinel defaults 0/-1 mean. Only body size and radius are exemplified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (grade/validate) applied to a specific resource (your design values) against a clearly characterized corpus (measured real products, decoded live). It is distinguishable from siblings like get_web_benchmark or compare_components, which benchmark products rather than validate the caller's own numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('anti-slop-check your own output BEFORE shipping') and what counts as normal (p25-p75) vs. needing justification (sub-p10/over-p90). It gives no named alternative tool for a different need, but the temporal guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
audit_codeget_design_driftlist_design_changesget_web_benchmarkcompare_componentscompare_recipescompare_sectionsgenerate_assetget_asset_packget_componentget_design_historyget_design_systemget_productget_recipeget_scoreget_screenget_screen_sectionsget_sectionget_user_flowlist_my_design_systemslist_user_flowssearch_screensvalidate_designReal UI references for coding agents: iOS app screens, user journeys and website design systems.
Design intelligence for coding agents: audits, design systems, and a taste profile agents consult.
A design harness for AI coding agents: design systems, design principles, icons and UI review.
Real product UI captures (onboarding, pricing, in-app screens) with design guides for coding agents.
Add one secure layer between your agents and this server.
