Standout

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

No annotations provided, so the description carries the burden. It conveys the tool assembles a kit from primitives, implying a constructive, non-destructive action. However, it doesn't detail side effects, authentication needs, or output format beyond the response_format parameter.

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 primary action and purpose. Every sentence adds value without redundancy or unnecessary detail.

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 7 well-described parameters and a clear purpose, the description is adequate. It explains what the tool builds and why to use it. Lacks explicit mention of return value behavior, but the response_format parameter covers that partially.

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 100% with clear parameter descriptions. The description adds context about the primitives but doesn't significantly enhance parameter understanding beyond what the schema provides. Baseline of 3 is appropriate.

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 'assemble' and specifies the resource: a coherent premium build kit from Standout-original primitives, listing specific components. It distinguishes from siblings by focusing on assembling from primitives, not building from references or generating 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?

The description explicitly says 'Use before building a luxury/high-end/Framer-like page' and explains the benefit. It doesn't explicitly mention when not to use or alternatives, but the context is clear.

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 that URLs are read server-side for semantic signals, that pixel-level palette/type extraction is not supported, and that matching is based on text/structure plus the curated library. This provides sufficient transparency 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 somewhat lengthy but front-loaded with a clear hook ('show me what you like, I'll build it'). Every sentence adds value, though minor redundancy could be trimmed. The structure is logical: purpose, then usage, then limitations and parameter guidance.

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 8 parameters, no output schema, and no annotations, the description covers all essential aspects: workflow, parameter roles, limitations, and expected outputs. It addresses potential confusion (e.g., distinguishing business from reference) and sets expectations for what is and isn't supported.

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 100%, and the description adds significant meaning beyond schema descriptions. It clarifies that 'business' means what the user is building (not the reference), explains how reference_url and reference_id interact, and notes the limitation on image extraction. This helps prevent misuse.

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: building from a reference (URL or library ID) rather than a text brief. It uses specific verbs ('build', 'give', 'get back') and distinguishes from text-only approaches by explicitly calling itself 'the front door for building from an 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?

The description explains when to use (when you have a reference), mentions limitations (no pixel-level extraction yet), and provides guidance on parameters (e.g., 'Pass reference_id to anchor on an exact curated reference'). It implicitly differentiates from text-only briefs but does not explicitly list when not to use or mention sibling 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, description carries full burden. It details the process: captures HTML/CSS signals, extracts Reference DNA, names what to borrow/avoid, gives similarity-risk guardrail, and returns a direction. Lacks disclosure on auth or side effects but appropriate for a read-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?

Description is moderately sized, front-loaded with purpose. Each sentence adds value, though slightly verbose. Could be trimmed without losing clarity.

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 8 parameters, no output schema, no annotations, the description covers core function and key parameters. Return value explained sufficiently ('reference-backed original build direction'). Missing details on error handling but acceptable.

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 100%, and description adds meaning beyond schema. Explains 'favorite_bits' as inspiration tokens not copied components, and gives examples for 'business' and 'favorite_bits'.

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 the tool's action: 'build from a site you like without cloning it'. Uses specific verb 'build' and resource 'reference-backed original build direction'. Distinguishes from siblings by mentioning it's for when user says they like a site but don't want to steal it.

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 provides when to use: 'the right tool when the user says I like this site but don't want to steal it'. Does not mention when not to use or alternatives explicitly, but the scenario is clear.

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 full burden. It details report contents but does not disclose if the tool creates a resource (e.g., stored report) or only returns data. It also omits any side effects or permissions needed, leaving some ambiguity for a generation 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 a single, well-structured paragraph with no wasted words. It front-loads the purpose, then explains optional parameters, and ends with white-labeling. Every sentence earns its place, making it highly 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?

The description adequately covers the tool's inputs and output contents for a moderate complexity (6 params, no output schema). However, it lacks explicit detail on the return format (e.g., URL to report, JSON structure, or file), which 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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how 'after_url' and 'after_source' enable before/after comparison with score improvement, and how 'agency_name' enables white-labeling. This goes beyond the schema's basic descriptions.

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 a 'CLIENT-READY design audit report' with specific elements like Standout Score, issues, fixes, and screenshots. It distinguishes from sibling tools like critique_ui and critique_design by emphasizing client-ready, jargon-free language and white-labeling.

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 required 'url' and optional parameters 'after_url', 'after_source', and 'agency_name' for white-labeling. It explains when to use before/after comparison but does not explicitly state when not to use this tool or suggest 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 fully discloses key behaviors: it takes screenshots at two widths, saves an unlisted shareable score report, and expects the agent to examine visuals. No contradictions or hidden side effects are evident.

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 informative but verbose, especially the sentence about screenshots and reports. It is front-loaded with the core purpose, but could be more concise while retaining necessary details.

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 complexity (4 params, no annotations, no output schema), the description covers purpose, usage, behavior, and parameter guidance well. It lacks only minor specifics like output format or access requirements.

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 100% coverage with descriptions. The tool description adds crucial context: preferring URL over source, and always passing 'direction' when built from get_design_direction. This enhances schema information significantly.

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: providing a brutal, specific design critique with AI-slop detection and a fix list. It distinguishes from sibling critique tools (critique_similarity, critique_ui) by focusing on existing pages with screenshots and score reports.

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 advises preferring URL over raw source and includes a note about passing the direction parameter for design system consistency. However, it does not explicitly state when to avoid using this tool or compare it to alternatives beyond the sibling list.

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 provided, so description carries full burden. States it's an 'originality guardrail' but does not disclose whether it has side effects, access requirements, or what happens when similarities are found (e.g., returns a score, blocks output). Lacks behavioral details beyond core purpose.

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 with zero waste: first sentence defines purpose, second provides temporal placement. Front-loaded 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?

For a tool with 5 parameters and no output schema, the description fails to explain return format (flag vs score vs block) or behavior on failure/lack of similarity. Missing critical information for correct invocation and interpretation.

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 100% with good inline descriptions. Tool description adds no extra parameter clarification beyond saying 'built page/source/description' which maps to candidate_source and candidate_description. At baseline 3 because schema already handles param semantics well.

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 verb ('compare') and resource (built page vs reference site) with specific outcome ('flag shared recognizable fingerprints'). Distinct from sibling tools like critique_design by focusing on originality against a specific reference.

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 after build_from_reference_v2, before showing or publishing', giving clear context. Does not mention when not to use or alternatives, but context is sufficient.

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?

Describes the deterministic rulebook and enumerates checks (radius chaos, card-in-card, etc.). Explains extra theme-conformance pass when a theme is provided. Returns a score, verdict, and fix list. No annotations provided, but description is thorough.

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 purpose, includes key details without fluff. Every part earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description mentions return value (score, verdict, fix list). It covers both base and theme passes, usage guidance, and alternative tools. Complete for a tool of this complexity.

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 descriptions already cover all parameters (100% coverage). The description adds context about when the theme parameter triggers additional checks ('when a Standout app theme is installed, a theme-conformance pass'). This adds 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?

Clearly states it is a 'Deterministic critique for APPLICATION UI' and lists specific checks. It distinguishes itself from critique_design by saying 'For marketing/landing PAGES use critique_design instead.'

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 'Use after building every view; re-run until the score clears 85' and gives a clear alternative for other use cases: 'For marketing/landing PAGES use critique_design instead.'

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. It discloses that the theme is 'LOCKED' and 'contrast-checked', describes the structure (two radii, five-step type scale, etc.), and states that installing the theme once ensures all views match. It implies a read-only operation with no side effects, which is transparent enough for an AI 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 front-loaded with the core purpose and details. While it includes some fluff ('how a vibe-coded app stops looking AI-generated'), the essential information is presented efficiently. It is not excessively long and each sentence serves a purpose, though slight tightening could improve.

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 there is no output schema, the description adequately explains return values: a menu when browsing or the full token system when a theme id is provided. It lists the content of the theme (color, radii, type scale, etc.), which is sufficient for an agent to understand what it will receive. The tool is simple and the description covers the necessary 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?

The schema covers all parameters (100% description coverage). The description adds meaning beyond the schema: it explains that omitting the theme parameter provides a free menu, and gives examples of theme ids (e.g., 'graphite-ledger'). It does not add much to response_format beyond what the schema provides, but overall it supplements the parameter 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 returns a 'LOCKED design-token system for application UI' and enumerates its components (color roles, radii, type scale, etc.). It distinguishes itself from sibling tools like website direction tools by stating themes share brand DNA with site directions, making clear it is for app UI theming.

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 tells when to omit the theme parameter (to browse the menu for free) and when to provide a theme id (to receive the full system). It also mentions that themes maintain brand consistency with site directions, hinting at when this tool is appropriate versus sibling tools. However, it does not explicitly list alternatives or when not to use this 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 full burden for behavioral disclosure. It only lists output contents but fails to mention side effects (none expected), idempotency, authentication needs, rate limits, or return format. The description does not confirm whether the tool is read-only or if it performs any mutations.

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 packs many items, making it slightly dense. It is front-loaded with 'Ready-to-paste CSS' which is good, but the structure could be improved with bullet points or separate clauses for readability. Every word adds value, but conciseness is slightly compromised by the run-on nature.

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 2 optional parameters and no output schema, the description provides a reasonable overview of what is returned. However, it does not clarify the output format (e.g., string vs. file), whether it's a complete CSS file or snippets, or how the returned data integrates with other tools. It is adequate but not thorough.

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?

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'direction' and 'query'. It does not tie the listed output components to specific parameter values.

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

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

The description explicitly states the tool returns 'ready-to-paste CSS for a direction' and enumerates specific components (palette, fonts, treatments, texture, import, motion recipes). This clearly distinguishes it from sibling tools like get_design_direction or get_motion_recipes, which serve different purposes.

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 does not provide guidance on when to use this tool versus alternatives. It implies usage for obtaining CSS for a direction but lacks explicit context, when-not-to-use examples, or comparisons with sibling tools. The agent must infer the appropriate scenario.

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 must cover behavioral traits. It explains components are 'finished' with built-in states and that the agent 'wires data and content instead of inventing structure.' This provides some context but omits details on safety, permissions, or side effects.

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 4-5 sentences, front-loading the main purpose. It is concise without unnecessary words, though a more structured list could improve scanability.

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 optional params, no output schema), the description covers the key aspects: what is retrieved, the component types, built-in states, and a prerequisite. Missing explicit clarification of the return format (e.g., code string, file) but otherwise 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 coverage is 100%, but the description adds meaningful value by elaborating on the component IDs (e.g., 'app shell with sidebar/topbar,' 'stat row with mono tabular metrics'). This enriches the agent's understanding beyond the schema's brief descriptions.

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 finished application-UI components with specific types (app shell, stat row, data table, settings form). It distinguishes from general tools like get_app_theme, but does not explicitly contrast with similar siblings like get_premium_components or get_section_code.

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 usage when needing pre-built UI components and explicitly states a prerequisite ('Install the theme first via get_app_theme'). However, it lacks guidance on when not to use this tool or what alternatives exist among 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, the description carries full burden. It discloses that the catalog has 14 directions, that passing a current_site_url triggers server-side fetch and returns a content inventory, and that omitting business returns questions. However, it doesn't explicitly state side effects (e.g., no database writes) or rate limits, leaving minor gaps.

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 thorough but efficient, with each sentence adding value. It is front-loaded with the core purpose and then covers usage variants. While on the longer side, it is well-structured and avoids 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 7 parameters, no output schema, and complex behavior (catalog, redesigns, fallback questions), the description is remarkably complete. It explains error handling, redesign protocol, content inventory return, and how boldness unlocks components. No critical information seems missing.

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

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

Schema coverage is 100% with good descriptions, but the tool description adds significant value: for 'boldness', it explains that safe never gets bold concepts and bold/experimental unlock set pieces; for 'current_site_url', it explains the redesign protocol; for 'business', it explains the fallback to intake questions. This goes well 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's purpose: 'Get a complete, distinctive, reference-backed art direction for a website.' It lists specific outputs (palette, type, layout DNA, etc.) and distinguishes from sibling tools by positioning as the first step before building and by mentioning the catalog of 14 directions. Unlike siblings like 'get_reference', this tool provides a complete direction.

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 FIRST, before building' and provides concrete scenarios: for new projects, pass tone; for redesigns, pass current_site_url; if only business name known, call anyway for intake questions. It also explains how boldness levels affect output. This gives clear when-to-use and when-not-to-use 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 for behavioral transparency. It describes the return content but does not disclose whether the tool is read-only, idempotent, or requires specific permissions. There is no mention of error conditions or rate limits.

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, well-structured sentence that efficiently communicates the tool's purpose and return content. Every component listed adds value, and there is no redundant or irrelevant 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 retrieval tool with no output schema or annotations, the description adequately specifies the return payload contents. However, it could be more complete by explicitly stating that the operation is read-only and non-destructive, which would help the agent understand behavior without requiring inference.

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 100%, so the baseline is 3. The description adds context about the overall return payload but does not add new information about the parameters themselves beyond what is already in the schema (e.g., flow_id comes from search_flows, response_format controls output 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 states the tool retrieves the full step-by-step payload for a user journey, listing specific components (problem, steps, user actions, etc.). It distinguishes from siblings like search_flows (which lists flows rather than detailed payloads) and get_design_direction (which returns design direction info).

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., needing a flow_id from search_flows). It simply describes what the tool does, leaving the agent to infer 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?

No annotations are provided, so the description carries full burden. It adds behavioral context: 'Free and unmetered; issuance is capped per network' and explains it returns key and instructions. It does not mention destructive actions, but the context is sufficient.

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, then usage condition, output, and caution. No wasted 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 0 parameters, no output schema, and no annotations, the description is mostly complete. It explains what it does, when to use, what it returns, and a caution. Minor gap: does not specify format of the key or instructions, but sufficient for a simple 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 tool has 0 parameters and 100% schema coverage. The description adds meaning beyond the schema by explaining the purpose and usage, earning a baseline 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?

The description clearly states the tool's purpose: 'Self-provision a free Standout trial key (25 calls, no signup) without leaving the conversation.' It uses specific verbs and resource, and it is distinct from sibling tools which are about design, assets, etc.

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: 'Call this when no license key is configured or your Standout calls return a license error' and 'never call it when you already have a working key.' This clearly indicates when to use and when not to.

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 provided; description discloses what is returned and a constraint (no cliches) but does not mention side effects, idempotency, prerequisites, or rate limits. Basic behavioral disclosure with gaps.

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 sentence efficiently conveys the tool's output components, including a specific exclusion. Front-loaded with the main action. 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?

Covers the primary purpose and output components but lacks details on return format or structure (e.g., how CSS is provided). No error handling or prerequisite info. Adequate for a generation tool but not fully 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 coverage is 100% with clear descriptions for both parameters. The tool description adds context about matching to design direction but does not provide additional semantic 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?

Clearly states the tool returns a complete hero section concept with specific components (headline, subline, CTA, background, motion CSS) and explicitly excludes marketing cliches. Distinct from sibling tools like get_design_direction or get_section_code.

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?

Description implies usage context (matched to design direction) but does not explicitly state when to use this tool vs alternatives like get_motion_recipes or get_flow. No exclusions or when-not-to-use 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 full burden. It mentions the output includes recipes and shader code, but does not disclose behavioral traits like side effects, rate limits, or required permissions. The tool appears read-only, but that is not explicitly stated.

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 informative and front-loaded with the main value proposition. It lists examples concisely, though it could be slightly shorter without losing clarity. Every sentence adds useful information, balancing detail and brevity.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should explain the return format. It implies output is code (recipes, shaders) but does not specify structure (e.g., JSON object, string, array). It also could clarify whether multiple items are returned or how to handle multiple requests. This is a gap for an otherwise good description.

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 100% with three parameters. The description adds concrete examples for each parameter (e.g., ids: ['gradient-mesh-flow','fade-rise-stagger'], query: 'webgl hero shader', direction: 'coastal-film') and explains how direction affects output (fills palette). This adds meaning beyond the schema's basic descriptions.

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 motion recipes for CSS/vanilla-JS and shader-grade ambient pieces, with specific examples (staggered entrances, scroll reveals, etc.). It distinguishes from sibling tools focused on other UI components (e.g., get_component_code, get_section_code) by being uniquely about motion animations.

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 clear usage instructions: request by IDs or describe your need, and optionally pass a direction pack for palette-filled shader code. It does not explicitly mention when not to use this tool or compare to siblings, but the context makes its purpose clear.

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?

Discloses output format (HTML/CSS/vanilla JS with reduced-motion fallbacks) which adds value beyond the schema. No annotations provided, so description carries full burden. Does not mention rate limits or auth, but for a retrieval tool this is adequate.

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 efficiently convey purpose and usage. Front-loaded with what the tool returns, followed by when to use. 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?

With 9 optional parameters and no output schema, the description covers general purpose and return type well. It lacks details on parameter interactions but is sufficiently complete for a retrieval 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 100%, so baseline is 3. The description does not elaborate on parameter meanings beyond what schema provides, but the usage guidance gives context on when to use certain parameters implicitly.

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 premium primitives with specific examples and mentions output as HTML/CSS/JS snippets with reduced-motion fallbacks. It distinguishes from sibling tools by focusing on components rather than pages or designs.

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 provides when to use: 'Use when the user asks for premium, luxury, beautiful, wavy, Framer-like, glass, 3D controls, or high-end motion.' Does not include negative cases or alternatives, but the guidance is clear and actionable.

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

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

No annotations are present, so the description carries full burden. It describes what the tool returns but does not disclose behavioral traits like authorization requirements, rate limits, or side effects. The listing of payload contents is helpful but insufficient.

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, front-loaded sentence that efficiently lists the payload components. While slightly long due to the list, it is concise and every element 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?

The description explains the output components, compensating for the lack of an output schema. It covers the necessary information for a simple retrieval tool, though it could mention error handling or permissions.

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 100%, so the schema already documents both parameters. The description adds context about the payload but does not enhance parameter meaning beyond schema descriptions. Baseline 3 is appropriate.

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 the full structured payload for a reference, listing all included components. This distinguishes it from siblings like search_references (which searches) and get_similar_references (which finds similar ones).

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 no guidance on when to use this tool versus alternatives. It does not specify prerequisites or context, leaving the agent to infer usage from the name and sibling list.

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 provided, so description carries full burden. Says sections are 'finished, art-directed' and 'seeded to business', implying a read-only operation. However, does not explicitly state safety (e.g., no side effects) or mention any required permissions. Adequate but could be more explicit.

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 concise sentences covering purpose, usage order, and a key selling point. No fluff, though the last sentence is slightly promotional. Good front-loading of core 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?

No output schema, so description should explain return format. It says 'art-directed HTML/CSS page sections' but not structure (e.g., list of objects). For a tool producing code snippets, more detail on output form would improve completeness. Still adequate for basic use.

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 covers 100% of parameters with descriptions. Description adds value by explaining how parameters interact: 'business seeds expression', 'direction pack id', and 'signature_move orders and frames to concept'. This enhances understanding 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 returns 'Finished, art-directed HTML/CSS page sections' for a design direction, with specific section types listed. It distinguishes from sibling tool 'get_design_direction' by using 'AFTER get_design_direction', implying it provides the concrete output after direction is set.

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 AFTER get_design_direction' and advises to 'replace only the content (copy + images), never the composition'. While it doesn't contrast with all siblings, it gives clear context for when to use in the workflow.

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 provided, so description carries full burden. It explains behavior: browsing returns menu skeletons, technique id returns full skeleton with prompts. Mentions free browsing and built-in mobile/reduced-motion behavior. Adequate transparency for a retrieval 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 verbose, with a dense list of techniques that could be streamlined. Front-loads main idea but could be more concise to improve readability.

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, description adequately explains tool behavior and return types (menu vs full skeleton with prompts). Covers modes, technique details, and mentions mobile/reduced-motion features. Fairly complete for a retrieval tool with two parameters.

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 100%, so baseline 3. Description adds extra context (e.g., direction pack fills with hexes, technique options listed), but does not fundamentally enhance understanding beyond schema descriptions.

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 'finished showpiece skeletons' for premium pages, lists specific techniques, and differentiates from design directions as a tier above. It uses specific verbs and resources, making purpose unambiguous.

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 states when to use ('when the brief says wow, cinematic, premium beyond a normal landing page') and describes two modes (browse menu without technique, get skeleton with technique). Lacks explicit alternatives or when-not-to-use, but sibling tools are listed separately.

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 describes the function but does not disclose behavioral traits such as being read-only, destructive, or any side effects. It lacks information about authentication requirements or rate limits, but the description does not contradict any annotations.

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 extremely concise with two sentences that front-load the primary purpose and usage guide. Every sentence adds value with 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?

Given no output schema and moderate complexity (3 parameters, no nesting), the description is fairly complete. It covers the tool's purpose, usage context, and parameter rationale. However, it does not describe the return format or structure of the similar references, which would be helpful.

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 100% with all parameters described (reference_id, limit, response_format). The description adds context about when to use reference_id ('from search_references' and 'after finding one strong reference'), but does not significantly enhance understanding of the parameters 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 verb 'Find' and the resource 'references similar to a known reference', listing the similarity criteria (tags, categories, use cases, StandOut direction ids). It distinguishes itself from siblings like get_reference (single reference) and search_references (broad search) by specifying the use case of broadening the evidence set.

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: 'Use after finding one strong reference to broaden the evidence set.' It tells the agent when to use the tool (after obtaining a reference), although it does not explicitly mention 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.

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

No annotations provided, but the description states that browsing does not consume a metered call, implying read-only and cost-free behavior. No contradictions.

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 well-structured sentences with front-loaded purpose, followed by usage instructions. Every sentence earns its place, no 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 fully explains what the tool returns (menu with taglines, vibe tags, best for). Complete context for a browse 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 100% but description adds meaning: 'light-base (9) or dark-base (5)' for tone, and explains response_format returns markdown (default) or JSON. Enhances parameter understanding.

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 browses the 'pick a vibe' menu listing 14 art directions (9 light-base, 5 dark-base) with taglines, vibe tags, and best uses. This specific verb+resource and scope distinguishes it from siblings like get_design_direction.

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 (user wants to choose) vs. when to use get_design_direction (auto-pick). Also instructs how to use the selected id with other tools (get_section_code, get_asset_pack, etc.). No ambiguity.

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 full burden. It discloses the tool is unmetered and lists only active watches, but does not mention authentication needs, rate limits, or any other behavioral characteristics beyond listing.

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?

A single sentence succinctly conveys the purpose and a key trait. No unnecessary words, and the crucial information 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?

Given zero parameters and no output schema, the description covers the basic function and hinted return fields. However, it does not describe the return format, pagination, or whether results are ordered, which would be needed for a complete 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?

The input schema has zero parameters with 100% coverage, so baseline is 4. The description adds value by specifying that the listing includes 'last known scores and check times', which is beyond the empty 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 verb 'List' and the resource 'active site watches', and specifies the information included (last known scores and check times). It distinguishes itself from sibling tools like 'watch_site' and 'unwatch_site' which are mutation 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?

The description includes 'Unmetered' as a usage hint indicating no cost, but lacks explicit guidance on when to use this tool versus alternatives or any prerequisites. For such a simple tool, the context is implied but not explicit.

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 transparency. It comprehensively explains the tool's actions: it takes a URL, source, or business description and performs classification, scoring, auditing, creative direction, layout, and returns a fully specified LLM-ready prompt along with a workflow and re-audit checklist. There is no contradiction or missing critical 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 lengthy but well-structured with numbered steps, making it easy to parse. It is front-loaded with the key phrase 'THE master tool' and clearly outlines the sequence of operations. While not maximally concise, the structure earns a 4.

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 complexity (7 parameters, no output schema, many sibling tools), the description covers the tool's purpose, inputs, and outputs well. It explains what the tool returns: an LLM-ready prompt, MCP workflow, and re-audit checklist. However, it does not detail the exact structure or format of the scoring or audit output, which would enhance 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by noting that 'url' enables live score and screenshots, and 'business' is used to classify and build from scratch when no URL/source is provided. This contextual value raises the score to 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?

The description clearly states that this is a master tool to transform any site, listing six specific steps: classification, scoring, auditing, creative direction, layout, and prompt generation. It explicitly distinguishes itself from sibling tools by indicating that this tool should be used when the user wants a complete client-ready transformation without knowing which individual tool to 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?

The description provides explicit guidance on when to use this tool: 'Use this when the user just wants their page made client-ready and shouldn't have to know which individual Standout tool to call.' This implies that for more specific tasks, the sibling tools (e.g., critique_design, get_design_direction) should be used instead.

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 must carry behavioral transparency. It only describes the purpose and usage, but does not disclose side effects, auth requirements, rate limits, or any other behavioral traits beyond the basic 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?

Two sentences, front-loaded with examples and usage guidance. Every phrase earns its place with no 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 5 parameters and no output schema or annotations, the description covers purpose and usage but omits behavioral details, return format (though implied by response_format parameter), and how results are structured. Adequate but not 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 100%, so baseline is 3. The description adds example search terms ('api key onboarding', 'pricing') that provide context beyond the schema, but does not significantly enhance understanding of parameters like 'category' or 'direction'.

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 searches for reference-backed user journeys and provides concrete examples like 'API key onboarding' and 'pricing selection'. It also distinguishes from visual screens, which helps differentiate from siblings like search_references.

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 states when to use: 'Use when the page is part of a multi-step task, not just a visual screen.' No explicit when-not-to-use, but the context implies 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?

No annotations are provided, so the description carries full behavioral burden. It lists output contents but does not disclose behavioral traits like rate limits, ordering, or result limits beyond what the parameter 'limit' implies. It is adequate but not comprehensive.

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 with no wasted words. The first sentence defines the tool's action and output, the second gives usage guidance. Information is front-loaded and every word earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema, the description explains what the tool returns (real patterns with source URLs, notes, etc.) and when to use it. It covers purpose, usage, and param hints adequately. Minor omission: no mention of ordering or pagination, but limit is provided.

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?

All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by providing example query terms ('developer tool pricing', 'api key dashboard') and context for 'direction' (StandOut direction id), enhancing understanding 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 'Search Standout's curated reference library' with a specific verb and resource, and lists what it returns (style, screen, component patterns). It does not explicitly differentiate from sibling tools like get_reference or get_similar_references, but the verb 'search' implies a broad retrieval vs. specific get.

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 or during a build when you need evidence-backed visual patterns,' providing clear when-to-use context. It does not mention when not to use or suggest alternatives, but the context is sufficient.

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 for behavioral transparency. It lists outputs and implies a generative action, but does not disclose potential side effects, required permissions, or whether the operation is destructive or idempotent.

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 well-structured sentences. The first sentence states the core transformation and outputs; the second sentence adds usage guidance. Every word is purposeful, and it is front-loaded with the most critical 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?

Given 8 parameters and no output schema, the description outlines outputs but lacks detail on their structure or format. For example, 'next tool calls' is vague. It is adequate but could provide more specifics about the returned data shape.

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 100% with parameter descriptions, so baseline is 3. The description adds value by explaining the overall purpose and how parameters fit together (e.g., 'business brief plus optional reference ids'), enhancing understanding beyond the isolated 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 turns a business brief and optional references into a reference-backed build direction, listing specific outputs. It distinguishes from sibling tools like search_references (which only search) or get_design_direction (which likely retrieves an existing direction) by focusing on synthesis.

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 when you want the agent to build from evidence instead of vibes,' providing a clear usage context. However, it does not explicitly mention when not to use this tool or provide direct comparisons to sibling 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?

No annotations provided, so description must disclose behavior. It mentions 'Unmetered' suggesting no rate limits, but lacks details on idempotency, what happens if URL not watched, or other traits.

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 concise sentences with no superfluous information. Every word 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 tool with one parameter and no output schema, the description provides enough context for correct invocation.

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

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

Schema has 100% coverage with description for url. The description adds value by specifying it must be the same URL as from watch_site, which is not in 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?

Directly states it stops watching a site's design score, with clear verb and resource. Distinct from sibling watch_site as it is the inverse operation.

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 to pass the same URL as given to watch_site, providing clear contextual usage. Does not discuss when not to use, but sufficient given the inverse relationship.

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 provided, so description carries full burden. It explains re-auditing frequency (~1/day), alert mechanism (email), and limits (10 active watches). Missing details on auth or failure behavior, but adequate for a monitoring 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?

Three sentences with no waste: first sentence states the action, second explains when to use, third adds a constraint. Every sentence earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description explains triggers, constraints, and usage context. It's fairly complete for a simple monitoring tool, though could mention how to stop watching (handled by sibling).

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 100% with both parameters described. The description adds value by explaining the email defaults to the license-bound email, beyond the schema's description.

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 watches a live site's design score, with specific triggers for re-auditing (drop >5 points or below 85). It uses a specific verb+resource and distinguishes itself from siblings like list_watches and unwatch_site.

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 context: 'Use it right after shipping a client site so a broken deploy is caught before the client sees it.' Lacks explicit when-not or alternatives, but the scenario is clear enough.

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