Mozaika

compare_sections

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`scheme`	No
`industry`	No
`section_type`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. It explains what the return contains: a ranked panel per product, including image_url, pixel-measured spec fields, design tokens, plus fallback behavior when there are no matches. It is not explicit about read-only semantics or API limits, but the described behavior is concrete and non-mutating in intent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core value and usage guidance, followed by an efficient Args section. It is somewhat dense but every sentence earns its place; there is no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 rightly provides return structure: ranked panel, one per product, reference image, pixel-measured spec, design tokens, and fallback behavior. For a four-parameter comparison tool, this gives an agent enough context to select and invoke it properly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema_description_coverage, the description must fully compensate for the schema. It does: section_type is given examples, industry is shown as an optional filter with industry examples, scheme is tied to the section's measured background, and limit is given a range and default. The Args block adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb + resource: compare sections across products, with the output being a ranked panel of real sections. It is clearly differentiated from sibling tools like compare_components and compare_recipes by operating on sections and by its cross-product comparison behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use the tool before designing any section, and it gives a concrete example. It handles the no-match case by saying it returns available section types. It does not explicitly name when not to use it or contrast with siblings like get_section or compare_components, but the usage context is still clear.

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

All Mozaika tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

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

Naming Consistency4/5

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

Tool Count3/5

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

Completeness4/5

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

Resources

Need Help?