Mozaika

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

With no annotations provided, the description carries full burden and does an excellent job. It discloses that it only reads source code, not rendered screen, and lists specific limitations (color contrast, hover/focus states, runtime-resolved variables). It also explains it reports only measurable items and lists what it couldn't read, plus the output format (worst-first findings with value, percentile, median, change).

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 long but every sentence earns its place. It front-loads the use case, then methodically covers input, metrics, output, limitations, and alternatives. No fluff—all content is relevant and organized logically, from problem to solution to caveats.

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 has only one parameter, no output schema, and no annotations, the description is remarkably complete. It covers what the tool does, when to use it, what to provide, what it returns, what it cannot do, and an alternative tool for related cases. Nothing essential is missing for an agent to invoke it 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 schema provides no description (0% coverage), so the description fully compensates. It explains the 'code' parameter precisely: 'the CSS and/or markup to audit. Paste the real thing, not a summary.' It also describes what to include (component's CSS, JSX/HTML with class attributes, or both) and how Tailwind utilities are read, making the parameter semantics crystal clear 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 audits the user's own code (CSS or JSX/HTML) and returns numeric metrics comparing against real products. It explicitly distinguishes itself from siblings: 'This is the one tool here that reads YOUR work instead of someone else's product.' This is specific and differentiates from related tools like get_score.

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 it: when a screen looks generic, cheap, or off and the user needs to know why. It also directs the user to an alternative for public URLs: 'for a public URL, get_score(domain) reads those from the live DOM instead.' This provides clear usage context and exclusion/alternative.

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

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

With no annotations, the description carries the burden and discloses key behaviors: it reads the live DOM, produces a ranked panel, and falls back to returning available types if no matches. It mentions real-world divergence examples, but doesn't cover potential performance or freshness caveats, so it's not 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?

The description is well-structured with a hook, usage directive, example, and parameter list. It's slightly verbose due to the brand-specific examples, but each sentence adds value and the arg list is clean.

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?

Since there's no output schema, the description explains return values: a ranked panel with measured attributes, and fallback to available types. It covers purpose, parameters, and behavior, but doesn't mention prerequisites or edge cases like invalid inputs, making it complete but not exhaustive.

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 documents all four parameters: component_type with examples, industry as an optional filter, scheme with dark/light and matching measured background, and limit with range/default. This exceeds what the schema provides and adds semantic meaning.

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 function: comparing how the best products build the same UI atom, with results from live DOM measurements. It distinguishes itself from siblings by emphasizing cross-product comparison and specific measured attributes (padding, radius, etc.), which is not apparent in sibling names like get_component or compare_recipes.

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 guidance: 'Use before building any component' and gives examples of component types. It lacks explicit when-not-to-use or alternative tool mentions, but the context is clear enough to infer appropriate usage.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return structure in detail (ranked panel, per-entry fields like overlay radius, shadow, backdrop filter, open-motion string, state names) and the fallback behavior ('Returns available recipe types if the requested one has no matches'). It does not explicitly state read-only semantics, but the nature of the tool makes that implicit.

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, front-loaded with a high-level summary followed by parameter details and return behavior. The illustrative Vercel/Supabase example helps convey value but is not strictly necessary; still, every sentence serves a purpose in explaining what the tool does and returns.

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 4-parameter complexity, no output schema, and no annotations, the description is comprehensive. It explains the return object's fields and the fallback case. It does not specify the ranking criteria, but that is a minor omission given the overall 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?

Schema description coverage is 0%, and the description fully compensates. The Args block explains every parameter with examples ('Command Palette', 'Dev Tools', 'dark'/'light') and constraints ('limit: panel size (1-12, default 8)'). It also adds semantic context, such as scheme meaning 'matches the recipe's measured overlay background.'

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: 'See how the BEST products each build the same hard pattern — one call, cross-product.' It explicitly differentiates from siblings by saying 'This is the comparison view; call get_recipe on the one you choose,' distinguishing it from get_recipe and other comparison tools.

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 explicit usage direction: 'Use before building any complex pattern.' It also names the alternative tool: 'call get_recipe(site, recipe_type) on the one you choose for its full measured anatomy tree,' giving clear when-to-use and when-to-use-other guidance.

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

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

With no annotations, the description carries the full burden of behavioral transparency. It discloses that the tool 'returns a ranked panel (one per product)' with detailed pixel-measured specs, and also handles the no-match case by returning available section types. It does not mention permissions or rate limits, but these are not essential for a read-only comparison 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 front-loaded with a clear purpose statement, followed by a structured Args section that covers all parameters without redundancy. The example call and fallback note are useful and earn their place; there is no wasted text.

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 is complete enough given there is no output schema: it explains what is returned (a ranked panel with image_url and detailed spec fields) and what happens when there are no matches. The only minor gap is that it does not specify how the panel is ranked, but this is not critical for an agent 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 input schema has 0% description coverage, so the description fully compensates by explaining each parameter with concrete examples: section_type is listed with many valid values, industry gets examples, scheme is 'dark' or 'light', and limit has a range and default. This gives the agent everything needed to invoke the tool 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?

The description opens with 'See how the BEST products each solve the same section' and includes an example call 'compare_sections("Pricing / Plans")', making it immediately clear this tool compares sections across products. It is specific to 'sections', differentiating it from sibling tools like compare_components and compare_recipes.

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 'Use before designing any section', giving a clear context for when to invoke it. It does not explicitly name alternative tools or state when not to use it, but the sibling tool names and the tool's focus on sections provide implicit guidance.

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

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.

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

With no annotations provided, the description carries full burden and does an excellent job. It discloses that the tool is free and unmetered, returns 1024px transparent PNGs, grants full commercial rights, and lists available packs for unknown slugs. This is rich behavioral context beyond the basic getter nature.

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-loaded with purpose, followed by examples and key details about format, licensing, and error behavior. Every sentence earns its place with no fluff.

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 one-parameter tool with no output schema, the description covers purpose, usage context, exact output format (PNG, 1024px), licensing, and fallback behavior. It provides sufficient information for an agent to invoke and interpret the result 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 schema has only a slug parameter with 0% coverage, and the description fully compensates by giving concrete examples ('clay-starter', 'line-minimal-starter') and explaining that unknown slugs trigger a list of available packs. This adds meaning far 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: retrieving a ready-made AI-generated icon pack. It specifies the resource (icon pack) and differentiates it from sibling get_* tools by emphasizing the 12 consistent icons, PNG format, and the option to list available packs for unknown slugs.

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 (when needing a ready-made icon pack, with examples of house styles and brand-specific packs) and highlights free/unmetered access. However, it does not explicitly mention alternatives or exclusion cases, such as when to use generate_asset instead, which would qualify for a 5.

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

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

With no annotations, the description transparently discloses key behavioral traits: data is 'read from the LIVE DOM', is 'measured, not guessed', and includes 'the real :hover state'. It also notes the fallback when a component type isn't found. This goes beyond typical descriptions, though it omits any mention of rate limits or authorization.

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 with high-value details, front-loads the core purpose, and every sentence adds useful information (return contents, use case, data provenance, error fallback). Slightly long but justified.

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 annotations or output schema, this description covers return contents (anatomy, image_url, design tokens, fallback types), data source (live DOM), and usage context. It lacks an explicit response format or error handling details beyond fallback, but is sufficient for the tool's simplicity.

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 provides no descriptions, but the description compensates with an example call get_component("Linear", "Button") that maps site to product name and component_type to component type. It also clarifies the fallback behavior when component_type is invalid, adding pragmatic meaning to both 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 identifies the tool as retrieving a fully specified UI component from a product's live DOM, including detailed styling properties, hover state, image URL, and design tokens. It distinguishes itself from sibling tools by focusing on 'build a <component> like <product>' with a concrete example.

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 explicitly states the intended use case ('Use this for "build a <component> like <product>"') and provides an example call. While it doesn't enumerate alternatives or when-not-to-use, the context is unambiguous and includes error fallback behavior.

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

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

With no annotations provided, the description carries the full burden and does well. It discloses that measurements are taken nightly from the live DOM, a dated ledger is kept, and what each verdict (held/shifted/unstable) means. It also mentions the do_not_hardcode field. It does not detail the response format or potential rate limits, but the coverage is substantial.

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 long but well-structured: an engaging lead, a mechanism explanation, a bulleted list of verdicts, clear usage guidance, and a parameter note. Each section adds value and the information is front-loaded enough that the tool's purpose is evident within the first sentence.

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 tool has one parameter and no output schema, and the description provides sufficient context: it explains the return verdicts, when to call it, and how it relates to siblings. It could mention edge cases or error conditions, but for typical use the description is 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 input schema only defines 'domain' as a string, with 0% coverage. The description compensates by providing the expected format ('bare domain, no scheme') and concrete examples ('stripe.com', 'linear.app'), which is exactly the kind of guidance needed for 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 answers what the tool does: it determines whether a product's design system has changed since decoding and identifies which numbers are safe to hard-code. It explicitly names the verdicts (held, shifted, unstable) and distinguishes itself from the sibling get_design_system by stating that it provides 'shelf life' rather than the spec.

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 gives explicit when-to-use guidance: 'Call this BEFORE building against a cached spec, and before baking any measured value into a token file.' It also names the alternative and pair: get_design_system(site), clearly delineating when to use which tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool returns first/last decode dates, decode_count, and dated change entries, and clarifies that an empty history means 'measured, stable so far' rather than an error. It also describes the token-level diff format with examples, giving strong insight into expected output 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 front-loaded with the core purpose, uses examples to illustrate the diff format efficiently, and includes a concise parameter definition and return value summary. Every sentence adds useful information without redundancy.

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 single parameter and no output schema, the description provides a complete picture: it explains the input format, what the output contains, and even the interpretation of an empty result. It leaves no significant gaps for the agent to guess.

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 only names the parameter 'site' with no description. The tool description compensates fully by defining site as 'a domain ("stripe.com") or product name' with a concrete example. This is the only parameter, and its semantics are made clear.

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 identifies the tool as returning measured design CHANGE HISTORY for a live-decoded domain, with concrete examples of token-level diffs. It distinguishes itself from screenshot-based tools by emphasizing historical evolution, which separates it from sibling tools like get_design_system or 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?

It explicitly states the intended use: 'Use it to see how a product's design system is EVOLVING.' It also notes that screenshots cannot backfill this data, providing contrast. However, it does not name specific sibling tools as alternatives or explicitly state when not to use it.

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

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

No annotations are present, but the description thoroughly discloses return payload structure, 'deep-decoded' extra data, measurement methodology, format options, and behavior across different inputs. It covers both default and optional outputs in detail.

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?

Though long, the description is information-dense and front-loaded with purpose. Each section adds value, from return details to format options, with no filler or redundancy.

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 or annotations, the description fully covers returns, variants, usage context, and parameter behavior, making it self-sufficient for an agent to invoke 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 schema only defines site and format as strings, but the description explains site as a product domain (Linear, Stripe, Figma) and details every format option including 'all' and 'astryx', adding substantial 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 it retrieves a product's full design system and explicitly ties it to 'design like <product>' use cases. It distinguishes itself from sibling tools like get_component or get_product by focusing on the complete design system.

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 explicitly specifies when to use the tool (e.g., 'design like Linear/Stripe/Figma'), mentions BYODS resolution order, and references generate_asset for complementary icon creation. This provides clear context and alternatives.

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

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

With no annotations, the description carries the burden of disclosing behavior. It details what the returned 'build kit' includes, notes conditional extra data for 'deep-decoded products', and explains resolution precedence. It does not mention auth or rate limits, but for a read-oriented aggregate tool, the disclosure is substantial.

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-loaded with the main purpose and then elaborating on contents and use case. Every sentence adds value, though the detail is somewhat dense. It is efficient for a tool with high complexity.

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 lack of output schema, the description provides a strong overview of the return payload (design system formats, sections with specs and image URLs, user flows). It covers the main use case and special token data. Minor gaps remain: no explicit mention of error behavior or limits, but the description is largely sufficient for an agent to invoke 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 schema has 0% description coverage, leaving the sole parameter 'site' completely unexplained. The description implies that 'site' refers to a product identifier ('clone/build like <product>') and mentions BYODS resolution, but it never explicitly states the expected format (URL, name, ID) or how to reference a product. The agent must 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?

The description clearly states the tool's function: 'Pull an entire product as an agent-ready build kit' with a specific verb and resource. It also enumerates the included components (design system, pages, sections, flows), which distinguishes it from sibling tools like get_design_system or get_section.

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: 'Call this once for "clone/build like <product>" instead of many small calls.' It also mentions resolution order ('Your private BYODS systems resolve first'). It does not explicitly list exclusion cases, but the guidance is clear enough for most scenarios.

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

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

With no annotations, the description carries full burden. It discloses detailed return behavior for each recipe type (anatomy tree, motion, states, webm, tokens; shader config, fps, install command; parameter surfaces) and also states the error fallback ('Returns the available types if the requested one isn't found'). This is highly transparent for a read-only fetcher.

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 longer than average but well-structured with an intro, bullet-separated families, usage examples, and a fallback note. Every section adds value, though it could be slightly trimmed without losing clarity, so it earns a 4 rather than a 5.

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?

This is a complex tool with three recipe families, no output schema, and rich return details. The description covers return values, valid inputs, use cases, and error behavior comprehensively, making it fully contextual for an agent to select and invoke 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 schema provides only names and types with 0% coverage, so the description must define all parameters. It thoroughly explains recipe_type with a full list of valid values and what each returns, and gives examples for site, thus adding complete semantic 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 it is a universal BUILD-KIT fetcher that returns measured spec + code to reproduce a UI. It explicitly lists three recipe families (COMPONENTS, EFFECTS, MOTION) and differentiates itself from siblings like get_component and get_section by calling itself the universal one-call solution.

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 provides explicit use-case guidance ('Use for "build a <thing> like <product>"') and gives concrete examples. However, it does not explicitly state when NOT to use this tool or name alternative sibling tools for exclusion, so it falls 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.

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.

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

No annotations are provided, so the description carries the transparency burden. It does disclose that the return includes full metadata and image_url, which is useful. However, it does not clarify behavior like not-found handling, authentication requirements, or response format.

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, front-loads the action and resource, and contains no filler or redundant 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 read-by-slug tool with one parameter, the description provides the essential purpose and return value. It could be improved by mentioning what happens when no screen matches, but the low complexity makes the description sufficient.

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 only defines 'slug' as a string with no additional description. The tool description explains that the slug is used to identify a single screen, adding meaningful context 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 uses a specific verb ('Get') and a precise resource ('full metadata + image_url for a single screen by slug'). It clearly identifies the input (slug) and distinguishes this tool from siblings like search_screens or 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?

The description implies the tool is for retrieving a single screen when its slug is known. However, it does not explicitly mention when to use it instead of alternatives, such as search_screens for discovery or get_screen_sections for screen sections.

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

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

With no annotations, the description carries the behavioral burden. It discloses that each section links back to its parent page and the design system, giving useful context about the returned data. It does not mention pagination, filtering, or mutability, but for a read-only listing tool this is moderately 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 two sentences, front-loads the core action with examples, and adds relevant navigation context. 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 simplicity (one parameter, no output schema, no annotations), the description adequately covers what it does and what the results contain. It could mention the return format or that it returns an array, but the examples and links to related tools make it sufficiently complete for an agent to select and invoke.

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 0% coverage for the single 'slug' parameter. The description implies slug identifies the page ('of a page'), which helps, but it doesn't explicitly define what a valid slug looks like or how it relates to parent_slug. It adds some meaning but does not fully compensate for the missing schema 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?

The description clearly states the tool's function: to list distinct sections of a page, with concrete examples (hero, pricing cards, footer). It also distinguishes itself from related tools like get_screen (page-level) and get_section (specific section) by focusing on enumerating 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?

The description explains the intended use case ('so you can emulate a specific part') and points to get_design_system for design system context. It could be clearer about when to use this instead of get_section, but the purpose is well implied by the examples and structure.

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

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

With no annotations, the description carries the burden and does well: it discloses the return contents (decoded spec, image_url, design tokens), mentions that deep-decoded products include measured states, and explains the fallback behavior when the section is not found. It could be more explicit about read-only semantics, but the 'Get' verb and 'Returns' phrasing imply safety.

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: three sentences, front-loaded with the primary function, then uses an example, then adds a useful detail about measured data, and ends with the fallback behavior. Every sentence adds value with no fluff.

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 simple 2-parameter schema, lack of output schema, and no annotations, the description covers the core purpose, return contents, fallback, and example. It could be more explicit about parameter formats or output shape, but the provided information is sufficient for a getter 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%, so the description must clarify parameters. It provides an example (site='Linear', section_type='Pricing / Plans') and implies site is a product name and section_type is a section label. However, it doesn't define the exact format or valid values for either parameter, leaving room for ambiguity.

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 gets one product's specific section fully specified, including decoded spec, reference image_url, and parent product's design tokens. It uses a specific verb ('Get') with a concrete resource and even includes an example, distinguishing it from siblings like get_screen_sections or get_component.

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 gives the intended use case: "Use this for 'build a <section> like <product>'", with a concrete example call. It doesn't mention when not to use it or name alternative tools, but the use case is clear enough for selection.

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

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

With no annotations, the description carries the full burden. It discloses the error dict behavior on missing flows and the content of the response (ordered steps, screen metadata, image_url). However, it does not mention authentication, rate limits, or side effects, though the read-only nature is inferable from 'Get'.

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 two sentences, front-loaded with the action, and every word contributes. It provides essential information without redundancy or fluff.

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-get tool, the description covers what is returned (ordered steps with screen metadata and image_url), the error case, and the resource. It does not explicitly state that the slug parameter is required or the exact format, but given the one-param schema and descriptive tool name, the context is adequately 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 description does not explain the 'slug' parameter beyond its name, and the schema provides no coverage (0%). The agent must infer that slug is the identifier for the flow, but the description adds no meaning beyond simply restating the resource type.

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 specifies that the tool retrieves a single user flow, including its ordered steps with full screen metadata and image_url. It also notes the error dict behavior on missing flows, distinguishing it from sibling getters by naming the specific resource and its unique structure.

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 explicit guidance is given on when to use this tool versus alternatives like list_user_flows for multiple flows or other get_* tools. The usage is only implied by the description's focus on a single flow, but no alternatives or exclusions are mentioned.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. It discloses the tool is live-measured and enumerates the returned metrics, but does not explicitly state it's a read-only operation or describe output formatting. Overall, it provides useful context beyond a simple 'get' 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 information-dense with an engaging hook and a list of metrics, but includes some marketing flair and extraneous details like the CC BY license and 'Free'. It is front-loaded with a clear subject and remains concise enough for an agent to parse quickly.

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 zero annotations, the description must explain what the tool returns. It enumerates the key metrics and states it is live data across real products. It also provides the citation source. It is complete enough for an agent to understand the tool's purpose and output, though a sample output structure would improve comprehensiveness.

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 has zero parameters, so the baseline is 4. The description adds no parameter details because none are needed, and the schema is vacuous. No further compensation is required.

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 provides measured web design norms (median design score, border-radius, font sizes, etc.) across real products. It explicitly differentiates from validate_design, which grades specific values, making the purpose unmistakable.

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 says to use it to ground design decisions in real norms and explicitly points to validate_design for grading specific values. This provides clear when-to-use and an explicit alternative, distinguishing it from siblings.

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

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

With no annotations present, the description carries the transparency burden and does well: it discloses the nightly re-measurement cadence, the ~100 product coverage, the fact that rows are recorded even when nothing changes, and the before/after value semantics. However, it does not explicitly describe the exact response structure or any authentication/rate-limit behavior, so it falls just short of a perfect score.

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 and front-loaded, starting with a clear purpose statement. It is slightly verbose with marketing-style language such as 'real time series, not a guess' and ends with a standalone 'Free.' that adds little operational value, but overall it remains focused and readable.

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 (one optional parameter, no annotations, no output schema), the description is remarkably complete. It explains the data source, update frequency, what the returned changes include, and how to use the tool versus its sibling. There is enough context for an agent to invoke it 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 schema provides only a default value for `limit` with 0% description coverage, but the description fully compensates by defining it as 'how many confirmed changes to return (1-40, default 10).' This adds both the valid range and the semantic meaning, which is exactly what the agent 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?

The description clearly identifies the tool as a listing function for design-system changes aggregated across ~100 products via the 'nightly Drift Ledger feed.' It uses specific language like 'what actually changed' and describes the time-series data, which distinguishes it from single-product tools such as get_design_drift.

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 answer 'does anyone actually redesign?', ground claims about design churn, or spot moved references. It also provides a clear alternative for single-product queries: 'For one product, call get_design_drift(domain).' This is strong usage guidance.

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

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 discloses that the tool returns an empty list if the user has no private design systems or is not authenticated, which is a key behavioral trait. It also reveals that each item only contains name and slug, setting expectations for the response structure. However, it does not elaborate on authentication requirements beyond the empty list case, nor any other edge behaviors like rate limits or ordering, but for a simple list operation this 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 two sentences long, front-loaded with the core purpose, and every clause adds meaningful information: the scope ('YOUR private'), the item structure ('name + slug'), the integration with other tools, and the edge case for an empty list. No redundant phrases exist, making it highly concise and well-structured.

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 having no output schema and only minimal formal metadata, the description fully explains the return value (each item has name + slug; empty list when none/not authenticated). It provides enough context for an agent to invoke the tool and understand the result. The tool's simplicity means the description covers all essential aspects without needing extra detail, so it is complete for its 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?

The tool has zero parameters, so parameter semantics are not applicable in the traditional sense. The description adds value by explaining the output format (name + slug) and how those values are used, which compensates for the lack of an output schema. Since there are no params, the baseline is 4, and the description meets this by not omitting any parameter-related meaning.

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 lists the user's private design systems, using the verb 'List' and specifying the resource ('YOUR private design systems'). The phrase 'BYODS' and the distinction from other tools (via 'private' and 'your') help differentiate it from sibling tools like get_design_system. It also explains what each item contains and how to use it, leaving no ambiguity about the tool's function.

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 guidance on when to use this tool: to list private design systems, and it directly tells the user to pass the slug/name to get_design_system or get_product for further actions. It also warns about the empty list when not authenticated, which is a clear context signal. However, it doesn't explicitly mention when to NOT use this tool or compare it to alternative list methods, so it lacks a bit of exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns flow summaries, not full sequences, and specifies the nature of the data ('real product'). It implies a read-only operation without stating it explicitly, but the behavior 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 concise, two sentences long, with a clear opening verb, concrete examples, and a useful pointer to another tool. Every word contributes to understanding the tool's purpose and usage.

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 core functionality and return shape are well covered, but the optional filter parameters are entirely unexplained, and there is no mention of sorting, pagination, or any limitations. Given no output schema or annotations, the description could be more 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?

Schema description coverage is 0% for the two parameters (query and industry), and the description never mentions them. The agent has no guidance on how to use these optional filters or what values to provide, which is a significant 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 clearly states the verb 'list' and resource 'user flows' with concrete examples (signup→dashboard, browse→checkout). It distinguishes from the sibling get_user_flow by noting that summaries are returned here, while full ordered screens require a separate call.

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: 'Use to understand how a whole journey is structured before building it.' It also directs to get_user_flow(slug) as the alternative for full detail, providing clear usage context.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains return shape (structured metadata, image_url), result variations (measured/retina booleans), and even provides a preference guidance for selecting hits. However, it does not discuss rate limits, ordering, auth, or side effects, leaving some room for further transparency.

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 long but earned: it bundles a one-sentence summary, a usage directive, and a structured Args block that documents all eight parameters. The front-loaded purpose and the use of bullet-like examples make it scannable and information-dense without fluff.

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 has 8 parameters, no output schema, and no annotations, the description supplies the necessary context: when to use it, what each parameter means, what results look like, and how to prefer higher-quality hits. No critical operational detail seems missing for an agent to select and invoke 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?

Schema coverage is 0%, so the description fully compensates. Each parameter is explained with concrete examples and constraints: query examples, platform values (including mobile semantics), limit range and default, kind options with definitions, and section_type combination patterns. This exceeds what the minimal schema provides.

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 opens with a specific verb and resource: 'Search real product UI screens for design reference.' It clearly differentiates from sibling tools like get_screen or compare_components by framing the tool as discovery/search 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?

The description gives an explicit usage directive: 'Use this BEFORE designing any page/component so your output matches how the best-designed products actually solve the problem.' This establishes clear context for when to call the tool, though it does not explicitly mention when not to use it or name alternative tools.

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

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

With no annotations, the description carries full burden. It discloses what each validation returns ('percentile, the corpus median/p25/p75 and a verdict') and includes concrete examples. It implies read-only behavior but doesn't explicitly state non-destructive intent, so a 4 is appropriate.

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 moderately long but every sentence adds value: purpose, usage, examples, and interpretation. It is front-loaded with the core function and maintains clarity without unnecessary verbosity.

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 optional parameters, no output schema, and no annotations, the description covers the main context well: what the tool does, how to use it, what it returns, and how to interpret the verdicts. It could mention edge cases like passing no parameters or invalid ranges, but overall it is solid.

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 conveys that parameters are design metrics (px, ms) and provides examples, but it doesn't enumerate or explain each of the 7 parameters. The parameter names in the schema are self-explanatory, but the description doesn't fully detail units or typical ranges 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's function: 'Grade YOUR design values against the measured corpus' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on validation/checking design metrics against real product data, not fetching or comparing 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?

Explicit use case is provided: 'Use this to anti-slop-check your own output BEFORE shipping'. It also explains how to interpret results (p25-p75 normal, sub-p10/over-p90 needs reason), giving clear guidance on when and how to leverage the tool.

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