Mozaika
Server Details
Design references for coding agents: real product screens, sections and decoded design tokens.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 16 of 20 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: compare tools aggregate across products, get tools retrieve specific items, generate creates assets, list enumerates, search explores, and validate checks values. No two tools have overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_components, get_design_system, search_screens). The naming is predictable and readable throughout.
20 tools is slightly above the ideal 3-15 range, but the count is justified by the server's broad scope covering comparison, retrieval, generation, listing, searching, and validation. Each tool serves a distinct need without redundancy.
The tool set covers the full lifecycle of design analysis: comparison across products, detailed retrieval of components/systems/recipes, benchmarking, validation, and asset generation. There are no obvious gaps for the server's stated purpose of providing design references and measurements.
Available Tools
20 toolscompare_componentsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses live DOM reading, measured properties (padding, radius, etc.), and return of available types on no match. No mention of side effects or permissions, which is acceptable for a read-only analysis tool.
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?
Well-structured: starts with purpose, then usage, then parameter details, then return behavior. Some redundancy (e.g., example in description), but overall efficient.
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 4 parameters and no output schema, description covers everything: required params, optional filters, return format, edge cases (no matches). No gaps remain.
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 description must explain all params. It does: component_type with examples, industry as optional filter, scheme as optional light/dark, limit with range. Provides more meaning than 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?
Clear verb+resource: 'compare' + 'components'. Specifies cross-product comparison of UI atoms from live DOM. Distinguishes from siblings like compare_recipes and compare_sections by focusing on components.
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 recommends using before building any component. Provides example call and explains fallback behavior when no matches. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_recipesAInspect
See how the BEST products each build the same hard pattern — one call, cross-product, each with its measured anatomy tree + motion. Use before building any complex pattern: compare_recipes("Command Palette") returns a ranked panel (one per product) of real command palettes, each with its open animation, backdrop, radius, row-rhythm and captured states — so you see how Vercel (cmdkScaleIn) vs Supabase (backdrop-blur) vs Tailwind each solve it, instead of guessing at the invisible motion/state layer.
Args:
recipe_type: e.g. "Command Palette", "Pricing Table", "Toast", "Data Table", "Multi-step Form".
industry: optional filter, e.g. "Dev Tools", "Fintech".
scheme: optional "dark" or "light" (matches the recipe's measured overlay background).
limit: panel size (1-12, default 8).
Returns available recipe types if the requested one has no matches.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scheme | No | ||
| industry | No | ||
| recipe_type | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It explains the tool returns a ranked panel with details like open animation, backdrop, radius, etc. Also describes arguments behavior. No mention of side effects, but it appears to be a read-only query tool.
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 somewhat verbose but well-structured with a bolded summary, example, and args list. Could be slightly more concise, but effective and front-loaded.
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 fully explains return value and covers edge case of no matches. Parameter count is 4, all explained. Sibling context is similar, so description provides sufficient differentiation.
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%, but description adds meaning: recipe_type with example, industry as optional filter, scheme as optional dark/light, limit as panel size (with default). However, no enum or specific valid values for recipe_type beyond examples.
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 compares recipes across products for a given pattern, using specific verbs like 'compare' and 'returns'. It distinguishes from sibling tools like compare_components and compare_sections by focusing on recipes and hard patterns.
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 explicitly says 'Use before building any complex pattern' and gives an example with 'Command Palette'. It also explains return behavior when no matches (returns available recipe types). Could be clearer about when not to use, but adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_sectionsAInspect
See how the BEST products each solve the same section — one call, cross-product. Use before designing any section: e.g. compare_sections("Pricing / Plans") returns a ranked panel (one per product) of real pricing sections, each with its reference image_url, pixel-measured spec (bg/text/accents/contrast/scheme/columns/alignment/ whitespace) and the product's core design tokens.
Args:
section_type: e.g. "Hero", "Pricing / Plans", "Testimonial / Social Proof",
"Logo Wall", "Feature", "CTA / Sign-up", "Footer", "FAQ", "Stats / Metrics".
industry: optional filter, e.g. "AI Tool", "Finance", "Dev Tools".
scheme: optional "dark" or "light" (matches the section's measured background).
limit: panel size (1-12, default 8).
Returns available section types if the requested one has no matches.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scheme | No | ||
| industry | No | ||
| section_type | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It details return structure and parameter effects but lacks info on side effects, auth, or error handling. Adequate for a read-like tool.
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?
Well-organized with a summary, return description, and args list. Slightly verbose but each sentence adds value; could tighten but not a major issue.
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, but description covers return structure (panel, specs, tokens). Four params explained well. For a moderately complex tool, this is sufficient context.
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 compensates well by explaining each parameter with examples, defaults, and purpose. Adds significant value beyond 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 clearly states the tool compares sections across products, provides examples, and distinguishes from siblings like compare_components and compare_recipes by focusing on 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?
Explicitly suggests use 'before designing any section', gives an example call, and notes fallback behavior when no matches. Lacks explicit when-not-to-use or alternatives but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_assetAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers behavioral traits: returns image_url and zip link, QA-failed images not counted, allowance by account type. Lacks explicit mention of rate limits or error handling but is sufficient for basic usage.
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?
Concise yet comprehensive; front-loaded with main purpose, uses examples, and efficient sentences. Every sentence adds value.
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 and 3 parameters, description explains inputs, outputs (image_url plus zip), and usage policy (allowance, counting). No major 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 coverage is 0%, description compensates by explaining subjects (1-12 short nouns) and style_from (domain or house style). However, it does not explain the 'format' parameter, which has a default value in schema. Adds meaning for two of three parameters.
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 it generates ON-BRAND icons with AI, specifying input as short nouns and output as images with consistent style. Distinguishes from sibling tools as the only 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?
Provides context for when to use: when needing icons in a consistent style, with allowance details per account type. Does not explicitly state when not to use or mention alternatives, but sibling tools are all read-only, so guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_asset_packAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the schema: free and unmetered usage, full commercial rights, 1024px transparent PNG output, and the fallback behavior for unknown slugs. Since no annotations are provided, the description fully carries the burden and does so excellently.
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 concise with four sentences that are front-loaded and directly useful. Every sentence adds value: purpose, examples, licensing and output details, and error handling. No wasted 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?
Given the tool's low complexity (single required parameter, no output schema), the description is complete. It covers input (slug), behavior (lists available packs on unknown slug), and output (12 icons, PNG, 1024px, commercial rights). An agent has sufficient information to use the tool correctly.
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 only parameter 'slug' is explained indirectly: it identifies the pack, and if unknown, the tool lists available packs. This adds meaning beyond the schema's type-only definition. However, the description could be more explicit about the expected format of the slug.
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 verb 'Get' and the specific resource 'ready-made AI-generated icon pack (12 consistent icons)' with examples like 'clay-starter'. It distinguishes itself from sibling tools like generate_asset by focusing on a pack of 12 consistent icons rather than a single asset.
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 for when to use this tool (to get a pre-made icon pack, free and unmetered) and includes behavior for unknown slug (lists available packs). However, it does not explicitly mention when not to use it or suggest alternatives like generate_asset for single icons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_componentAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that data is read from live DOM (measured, not guessed), includes exact hover state and design tokens, and notes data has not been seen by models. Also explains fallback when component not 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?
Single paragraph of 68 words, front-loaded with main action. Every sentence adds value: definition, usage, data source, fallback. No redundancy 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?
Despite no output schema, description explains return value thoroughly (anatomy, image_url, design tokens) and covers edge case (not found). Parameter count is low, but could provide more detail on parameter values. Still, largely complete for the tool's purpose.
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 description must compensate. Only provides example usage ('Linear', 'Button') but does not explicitly define 'site' or 'component_type' or their possible values. Leaves agent to infer meaning from context, which is insufficient.
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?
Clearly states verb (get), resource (component), and details what is returned (anatomy from live DOM, image_url, design tokens). Distinguishes from siblings by focusing on single component measurement, not comparison or asset generation. Includes example usage for context.
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 'Use this for build a <component> like <product>' with concrete example. Does not mention when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_design_historyAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return fields (first/last decode dates, decode_count, dated change entries), behavior for empty history ('measured, stable so far'), and the nature of data (token-level diffs). No mention of side effects, but the tool is read-only and non-destructive based on context.
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 well-structured: main action first, then examples, usage hint, parameter clarification, and return format. While slightly verbose, every sentence adds value and the key purpose is front-loaded.
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 tool with 1 parameter, no output schema, and no annotations, the description is remarkably complete. It covers what the tool does, what it returns, edge cases (empty history), and how to use the parameter. No additional context seems necessary.
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 single parameter 'site' has type string with no schema description (0% coverage). The description adds crucial context: 'site = a domain ("stripe.com") or product name', which clarifies the acceptable inputs beyond the schema alone.
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?
Description defines the tool as providing 'measured design CHANGE HISTORY' with specific examples of token-level diffs, clearly distinguishing it from screenshot libraries. The verb 'get' plus 'design history' is precise and the resource (Decode Ledger) is well-defined.
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 explicitly states when to use the tool: 'Use it to see how a product's design system is EVOLVING'. It does not mention alternative tools or when not to use, but the unique purpose makes this clear. The sibling tools like 'compare_components' suggest other use cases, but no direct exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_design_systemAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses what is returned (default vs deep-decoded) and explains the format parameter. It does not mention error cases, auth needs, or rate limits, but for a read-only tool it is reasonably transparent.
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 relatively long but well-structured with clear sections. Every sentence adds value, though some redundancy could be trimmed. It is front-loaded with the main 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 no output schema and complex return data, the description thoroughly explains default and deep-decoded outputs, including hex normalization, measured states, and format options. It even references sibling tools like 'generate_asset' and 'list_my_design_systems' for integration.
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 fully explains both parameters: 'site' is implied in usage context, and 'format' is detailed with possible values ('all', 'tailwind', etc.) and what each returns. Adds significant meaning beyond the 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 clearly states the tool retrieves a product's full design system to match its exact look, using a specific verb and resource. It distinguishes itself from siblings by focusing on design system extraction rather than comparison or asset generation.
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 'Use this for design like <product>' and gives examples. Mentions that private BYODS design systems resolve first, providing context. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a comprehensive build kit with detailed contents and mentions deep-decoded token properties. Does not mention side effects because it is a read operation, but could note performance 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?
Three well-structured sentences: first defines purpose and contents, second adds detail on tokens, third gives usage guidance. No fluff, front-loaded with most important 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?
Good overview of return content but lacks explanation of the only parameter. For a high-complexity tool with no output schema, more detail on input semantics and return size would improve completeness.
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 sole parameter 'site' has no description in schema (0% coverage). The description does not explain what 'site' represents, leaving agents to guess. Should have clarified that 'site' identifies the product.
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 it pulls an entire product as an agent-ready build kit, listing included components (design system, pages, sections, user flows). It distinguishes from siblings like get_component and get_section by emphasizing the all-in-one nature.
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 'Call this once for clone/build like <product> instead of many small calls', providing clear when-to-use context. Does not explicitly name alternatives but implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipeAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details return values for each recipe type (TREE, MOTION, STATE, webm, tokens, etc.) and error handling. However, it does not mention side effects, authentication requirements, rate limits, or performance implications, which leaves some uncertainty for an agent.
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 fairly long but well-structured with bullet points and examples. It front-loads the core purpose. While slightly verbose, every sentence contributes valuable information without repetition.
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 two required parameters and no output schema, the description provides detailed return information for each recipe type and error behavior. It covers the three families thoroughly. Missing details like output format or pagination are minor given the tool's purpose.
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%, but the description compensates well. It explains the 'site' and 'recipe_type' parameters through examples and lists possible values for recipe_type (COMPONENTS, EFFECTS, MOTION) with sub-values. This adds significant meaning beyond 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?
The description clearly states the tool's purpose: 'The universal BUILD-KIT fetcher — the measured spec + code to reproduce a piece of UI.' It lists three families (COMPONENTS, EFFECTS, MOTION) with examples, and distinguishes itself from siblings like get_component or get_section by focusing on recipe retrieval for reproduction.
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 explicit usage context: 'Use for "build a <thing> like <product>"' with examples like get_recipe('Vercel', 'Command Palette'). It also explains fallback behavior: 'Returns the available types if the requested one isn't found.' However, it does not explicitly state when not to use this tool or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scoreAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses scan duration (~60-90s), account email requirement, and that full fix payload requires Pro/Lifetime. Transparent about non-destructive nature and free access.
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?
Description is comprehensive and well-structured, starting with the score and audit, listing outputs, then behavioral notes. Slightly verbose but every sentence adds value.
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 explains return values (dimension scores, verdicts, evidence, fix list) and the scanning process. Adequate for a complex 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?
Schema coverage is 0%, but description does not explicitly explain parameter semantics beyond implying 'site' is a URL and 'refresh' triggers new scan. No format or examples provided.
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 returns a 0-100 design audit score measured from live DOM, specifying dimensions and outputs. It distinguishes from sibling tools (components, design systems) by focusing on site scoring.
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: 'audit the site YOU are building or any competitor'. It explains the scanning process and Pro limitations. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screenAInspect
Get full metadata + image_url for a single screen by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('get'), but without annotations, it does not explicitly state safety, rate limits, or authentication requirements. It adds some context about the return payload but lacks full behavioral disclosure.
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 sentence that efficiently conveys the tool's action and target, with no unnecessary words or repetition.
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 low complexity and no output schema, the description covers the essential information (what it does and how to identify the screen). However, 'full metadata' is vague and could be clarified, and the lack of output format details is noticeable.
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 single required parameter 'slug' is only mentioned by name in the description, not explained (e.g., format, example, source). With 0% schema description coverage, the description should compensate but does not provide meaningful guidance beyond the parameter name.
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 verb 'get', the resource 'screen', and the key identifier 'slug'. It specifies that it returns 'full metadata + image_url', making the tool's purpose distinct from siblings like get_screen_sections or search_screens.
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 is provided on when to use this tool versus alternatives such as search_screens for listing or get_screen_sections for sections. With many sibling tools, explicit usage context is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screen_sectionsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions linking to page and design system but does not disclose read-only nature, side effects, performance, or error cases.
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 focused sentences, front-loaded with purpose, no unnecessary 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?
Given simple tool (one param, no output schema), description covers core purpose and usage hint. Could mention expected output format or example, but overall adequate.
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 has required 'slug' parameter with no description; only implicit meaning from context (page slug). Schema description coverage is 0%, and description adds minimal detail about the parameter.
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?
Description clearly states it lists distinct sections of a page with examples (hero, pricing cards, etc.), distinguishing it from sibling tools like get_section and get_screen.
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?
Implies usage for emulating a specific part of a page and suggests calling get_design_system afterwards, but does not explicitly state when not to use or compare to alternatives like get_section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sectionAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly describes what is returned including special behavior for deep-decoded products and error handling (returns available section types if not found). No annotations to contradict.
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 sentence clearly states purpose. Three additional sentences add valuable details without redundancy. Entire description is informative and efficient.
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 simplicity (2 params, no output schema), the description covers input usage, output data, error handling, and special conditions. No gaps apparent.
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?
While the description does not explicitly define each parameter, the example ('get_section("Linear", "Pricing / Plans")') clearly maps site and section_type. This compensates for the 0% schema coverage by providing real-world usage.
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?
Clearly states verb 'Get one product's specific section' with details on what is returned (decoded spec, image_url, design tokens). Provides example usage. Distinguishes from other get_ tools by focusing on sections and deep-decoded design tokens.
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?
Provides a clear use case ('build a <section> like <product>') and example. Does not explicitly exclude other contexts or mention alternatives, but the scope is clear from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_flowAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return content (steps with metadata and image_url) and error handling (returns error dict if not found). No annotations are provided, but the tool is clearly read-only and the description gives sufficient behavioral insight.
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, front-loaded with the action and result, no unnecessary words. Every sentence adds value.
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 retrieval tool with one parameter, the description covers what is retrieved, what is returned (steps with screen metadata and image_url), and error behavior. It is nearly complete, though it could add return format details.
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 only parameter 'slug' is not described in the schema (0% coverage), but the tool name and description imply it identifies the user flow. However, the description could explicitly clarify that slug is the unique identifier.
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 'Get one user flow' and specifies its output includes ordered steps with full screen metadata and image_url, distinguishing it from siblings like list_user_flows that list all flows.
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?
Usage context is implied (use when you need a specific flow by slug), but the description lacks explicit guidance on when to use this tool versus alternatives like list_user_flows or get_screen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_web_benchmarkAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should fully disclose behavior. It implies a read-only operation but does not explicitly state safety, authentication needs, or side effects. The missing transparency is a gap.
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?
Description is informative and front-loaded, but includes extra details like license and citation that, while useful, slightly extend it. Still efficient overall.
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 parameters and no output schema, description explains what data is returned, provides source, and gives usage guidance. No gaps identified.
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 are 0 parameters, so schema coverage is 100%. Description adds no param info but none is needed. Baseline for 0 params is 4.
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?
Description clearly states the tool retrieves live design metrics from hundreds of products, listing specific data points. It distinguishes from sibling 'validate_design' by stating that tool grades specific values, while this tool provides norms.
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 ('ground design decisions in real norms') and provides citation instructions. Also mentions alternative tool for grading specific values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_design_systemsAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication-dependent behavior (empty list if not authenticated), return format (name+slug), and that results are private scope. Lacks details on pagination or sorting, but since it lists all with no parameters, it's acceptable.
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, front-loaded with action, no unnecessary words. Every sentence adds value.
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 parameters and no output schema, description covers purpose, usage, behavior, and result format fully. Complete for a simple list 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?
No parameters in schema (100% coverage), baseline 4. Description adds context on how results are used, which compensates for lack of parameters.
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?
Clearly states 'List YOUR private design systems (BYODS)' with specific verb and resource. Distinguishes from sibling tools like get_design_system by noting that results can be used with that 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?
Explains how to use the results (pass slug/name to get_design_system or get_product) and mentions authentication edge case. Does not explicitly contrast with other list tools like list_user_flows, but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_user_flowsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a safe read operation (listing summaries) but does not explicitly state idempotency, authentication needs, pagination, or ordering. A 3 is appropriate as it is adequate but lacks depth beyond the basic listing function.
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 three sentences, front-loads the main action, includes examples, and points to an alternative tool. It is efficient and contains no wasted 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?
The description covers the basic purpose and output format (flow summaries) and references the sibling tool for full details. However, it fails to explain the filtering parameters (query, industry), which are essential for using the tool effectively. Given the simple nature of the tool, this omission reduces completeness.
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 input schema has two parameters (query, industry) with zero description coverage. The description adds no explanation for these parameters, leaving the agent to infer their meaning from names alone. While the names are somewhat self-explanatory, the description should clarify their role to ensure correct invocation.
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 lists real product user flows with ordered screen journeys, provides concrete examples (e.g., signup→dashboard), and distinguishes itself from the sibling tool get_user_flow by noting it returns summaries while the other returns full details. This makes the purpose specific and actionable.
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 explicitly states when to use the tool: 'to understand how a whole journey is structured before building it.' It also provides a clear alternative: 'call get_user_flow(slug) for the full ordered screens.' This gives precise context and avoids ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_screensAInspect
Search real product UI screens for design reference.
Use this BEFORE designing any page/component so your output matches how the
best-designed products actually solve the problem. Returns structured metadata
(description, UX patterns, UI elements, colors, palette) plus an image_url.
Section/component/recipe hits also carry `measured` and `retina` booleans —
prefer measured:true, retina:true references (pixel-measured, high-res).
Args:
query: free text, e.g. "fintech onboarding", "dark dashboard", "Linear".
page_type: e.g. "Landing Page", "Dashboard", "Pricing & Subscription", "Checkout".
ux_pattern: e.g. "Onboarding", "Dark Mode", "Filter & Sorting", "Stats".
industry: e.g. "AI Tool", "Finance", "Analytics", "Fashion".
platform: "Web", "iOS" or "Android" (mobile = official store-listing screens).
limit: max results (1-40, default 12).
kind: "page" (default, whole screens), "section" (page parts),
"recipe" (live-decoded composed patterns: Command Palette, Navbar, Login,
Data Table, Hero Effect...) or "component" (measured single components).
section_type: narrows by type, e.g. kind="section" + "Pricing / Plans" /
"Testimonial / Social Proof" / "Hero", or kind="recipe" + "Login" /
"Navbar" / "Data Table" / "Hero Effect".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | page | |
| limit | No | ||
| query | No | ||
| industry | No | ||
| platform | No | ||
| page_type | No | ||
| ux_pattern | No | ||
| section_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes return values (metadata, image_url) and behavioral traits (measured/retina booleans, behavior per kind). However, it does not mention potential side effects, auth needs, or rate limits, though these are less critical for a read-only search.
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 well-structured with an opening, usage guidance, return info, and parameter details. It is front-loaded with purpose and each sentence adds value. Slightly longer than necessary but appropriate for the complexity of 8 parameters.
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 or annotations, the description covers purpose, usage, parameters, and return values adequately. It lacks some details like error handling or pagination beyond limit, but is otherwise complete for a search 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?
Schema description coverage is 0%, but the description compensates fully by explaining each parameter with examples and default values. It clarifies the meaning of 'kind', 'section_type', and platform behavior, adding significant value beyond the 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 clearly states 'Search real product UI screens for design reference.' It uses a specific verb ('Search') and resource, and distinguishes itself from sibling tools like get_screen or compare_components by positioning it as a discovery tool to use before designing.
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 'Use this BEFORE designing any page/component' and advises preferring 'measured:true, retina:true references'. It provides detailed parameter explanations and examples, giving clear context on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_designAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the behavior: returns percentile, median, quartiles, and verdict. It also includes interpretation guidance (p25-p75 normal, extremes need reasons). Does not mention side effects, but the context suggests a read-only safe operation.
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?
Four sentences packed with essential information: purpose, input flexibility, output details, and interpretation. No redundant words. Front-loaded with the main 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 7 parameters, no schema descriptions, no output schema, and no annotations, the description provides a good overview but lacks detailed per-parameter explanations and precise output format. Sufficient for basic use but may require trial for full understanding.
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 has 0% description coverage for 7 parameters. The description adds meaning by stating any metric can be passed and gives examples ('body 13px', 'radius 24px'), but does not detail all parameters or their units beyond what the names imply. Partial compensation.
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?
Description clearly states the tool grades design values against a corpus, returning percentiles and verdicts. This is a specific verb+resource action that distinguishes it from sibling tools which are mostly get/list/search operations.
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 advises using this tool to 'anti-slop-check your own output BEFORE shipping', providing a clear use case. However, it does not mention when not to use it or provide explicit alternatives, though the unique function implicitly differentiates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!