Standout

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

With no annotations, the description carries full responsibility for behavioral disclosure. It does not state what the output looks like, how it processes inputs, whether it is read-only, or any side effects. The phrase 'real components instead of generic advice' hints at output but lacks detail, so transparency is inadequate.

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 main action, and every word earns its place. The component list is lengthy but necessary for specificity, and there is no redundant or filler content.

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

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

The tool lacks an output schema, so the description must explain return values. It mentions the kit includes certain primitives but not the format, structure, or how the agent should use the result. The usage line gives some context but leaves significant gaps, especially for a 7-parameter tool with varied optional inputs.

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 baseline is 3. The description adds no extra meaning about the parameters; it only lists output-like concepts (type scale, spacing) without linking them to inputs. Thus it does not exceed the schema's documentation value.

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

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

The description clearly states what the tool does: 'Assemble a coherent premium build kit' from specific primitives (type scale, spacing rhythm, hero background, etc.). It distinguishes itself from sibling tools by emphasizing the assembly aspect and lists concrete components, making its 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?

The description explicitly states when to use: 'Use before building a luxury/high-end/Framer-like page so the agent has real components instead of generic advice.' It provides clear context but does not mention when not to use or name alternative tools, so it stops short of full 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?

With no annotations provided, the description carries the full transparency burden and excels: it discloses server-side URL reading, the semantic signal used (title, headings, copy), and explicitly notes the limitation that pixel-level palette/type extraction is not yet supported (Phase 2 vision pass). This is rich, honest behavioral disclosure.

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

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

The description is compact yet information-dense, front-loaded with a memorable hook ('show me what you like, I'll build it') and then logically covering inputs, process, outputs, and a limitation. Every sentence adds value, and no space is wasted on repetition of schema 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?

For a tool with 8 parameters, no output schema, and no annotations, the description is remarkably complete: it explains what the tool returns (direction, build plan, next call), how the reference is processed, what is not supported, and how to anchor on exact references. This gives an agent sufficient context 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 100%, so a baseline of 3 applies, but the description adds meaningful semantics beyond the schema: it clarifies that 'business' means what you are building (not the reference), that reference_id comes from search_references, and how reference_url is used server-side. This contextual glue improves parameter comprehension beyond the property 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 opens with a clear verb+resource: 'build' from a reference, and explicitly frames it as the 'front door for building from an EXAMPLE instead of a text brief.' It distinguishes itself from text-based builds and lists concrete outputs (direction, build plan, next call), making its purpose unmistakable even among siblings.

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

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

It states when to use it: when you have a reference example rather than a text brief, and gives guidance on choosing between reference_url and reference_id. It also tells users to pass reference_id to anchor on an exact curated reference, providing clear context though not explicitly naming alternatives like build_from_reference_v2.

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 internal process (captures server-readable HTML/CSS, extracts Reference DNA, names what to borrow/avoid, gives a similarity-risk guardrail) and sets an expectation of originality. It also hints at a constraint with 'server-readable.' It does not discuss failure modes or side effects, but for a generation 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?

The description is moderately sized with a clear structure: hook, input instructions, process, and when-to-use. Every sentence adds information, though it is somewhat dense. It earns a 4 for being efficient without being overlong.

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 provides a clear picture of the workflow and what the returned direction includes (borrow/avoid/guardrail). It does not detail the exact response structure, but response_format is in the schema. The tool's purpose, usage, and output components are covered well.

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 explaining favorite_bits as 'inspiration tokens, not copied components' and emphasizing that business is 'what YOU are building (not the reference).' This extra interpretation is valuable for the agent.

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 the tool builds a reference-backed original build direction from a site without cloning it, and outlines the process (captures HTML/CSS signals, extracts DNA, names borrow/avoid, gives similarity-risk guardrail). This is a specific verb+resource+outcome that distinguishes it from sibling tools like get_reference or synthesize_direction_from_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?

It provides an explicit use case: 'This is the right tool when the user says I like this site but don't want to steal it.' It also clarifies required inputs (reference_url, business) and optional favorite_bits. However, it does not explicitly list when not to use or name alternative tools, so it lacks exclusions.

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 the output is in plain language with no internal jargon, that the report is client-safe, that before/after includes both screenshots and score improvement, and that white-labeling affects both the report text and the public report page. It does not mention authentication, side effects, or exact return format, but the disclosed behavior 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 dense but well-structured: it front-loads the core outcome, then explains optional parameters and branding behavior. Each sentence earns its place; there is no filler or repeated schema 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?

The description covers the core purpose, output contents, parameter usage, and white-label behavior, which is sufficient for selection and invocation. Without an output schema or annotations, it does not fully specify return structure or operational constraints, but the description is strong enough for an agent to act confidently.

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 already describes all six parameters with 100% coverage, giving a baseline of 3. The description adds meaningful semantics: after_url and after_source are presented as alternatives enabling a true before/after with both screenshots and score improvement, and agency_name is explained as the white-label control for 'Prepared by X' on the report and public page.

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 ('Generate') and a specific deliverable ('CLIENT-READY design audit report'), then enumerates the contents: Standout Score, blockers, fixes, client-safe summary, and screenshots. It clearly differentiates from sibling critique/design tools by emphasizing the agency-to-client, white-label use case.

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 context for when to use the tool: for an agency sending a report to a client, with the current page URL, optionally an after_url/after_source for before/after comparisons, and agency_name for white-labeling. It does not explicitly contrast with sibling tools like critique_design or make_it_standout, nor does it 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?

With no annotations, the description carries the full burden. It discloses the side effect of saving an unlisted shareable score report, the inclusion of live screenshots, and the prioritized fix list. However, 'these reasons' for preferring URL is vague, and it doesn't clarify what happens if only source is passed, leaving a minor transparency gap.

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

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

The description is a single dense paragraph with three long sentences, including a run-on first sentence. It packs a lot of information but lacks visual structure (e.g., bullets or separators). It is not as concise as it could be for the amount of content.

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

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

Given the tool's complexity and no output schema, the description adequately explains the returns (fix list, screenshots, score report) and what to do with them. It misses explaining the direction parameter's role (though the schema covers it), but overall the critical contextual information is present.

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 value beyond the schema by prioritizing URL over source ('Always prefer passing the published URL') and indicating that screenshots occur when a URL is passed. This enriches understanding of the url and source 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 opens with 'Brutal, specific design critique of an existing page' — a clear verb+resource pairing. It distinguishes itself from sibling tools (critique_ui, critique_similarity) by detailing unique features: AI-slop detection, prioritized fix list, live screenshots, and a shareable score report.

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 operational guidance: 'Always prefer passing the published URL over raw source' and explains the URL triggers screenshots. It doesn't explicitly contrast with sibling tools or state when not to use this tool, but the context is clear enough for an agent to decide.

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 full burden. It explains the tool's role as an originality guardrail but does not disclose return format, side effects, or what 'flag' means in practice. The workflow context adds some transparency but leaves behavioral details unspecified.

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, front-loaded sentence that efficiently conveys both purpose and usage. Every word serves a function, with no redundant 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?

The tool lacks an output schema, and the description does not explain return values or how response_format affects output. It adequately covers when to use and overall purpose but omits behavioral completion details, leaving the agent to infer what 'flag' means.

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 value by linking candidate_source/candidate_description to the built page and tying favorite_bits to build_from_reference_v2, providing cross-tool context beyond the 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 compares a built page/source/description against a reference site and flags shared fingerprints. It distinguishes from siblings like critique_design by focusing on originality and specifies the workflow placement after build_from_reference_v2.

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 to use after build_from_reference_v2 and before showing or publishing, giving a clear trigger context. It lacks explicit exclusions or alternative names, but the usage timing is precise 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is 'deterministic', describes the two passes (rulebook and optional theme conformance), and lists the output (score, verdict, fix list). It does not mention side effects (e.g., whether source is stored or modified), but as a read-only critique tool the lack of side effects is implied. The conditional theme pass is clearly explained.

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-structured, with a purpose statement, a detailed rulebook list, an output summary, and usage guidance in only two sentences. Every clause adds useful information, though the parenthetical list makes it a bit heavy. It earns a 4 for being concise yet comprehensive.

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 fully covers the tool's purpose, inputs, behavioral details, return value, and usage threshold. It even names an alternative for a different use case. The only minor omissions are an explicit explanation of the 'ship verdict' contents and whether any setup or prerequisites are needed, but these are not essential 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 description coverage is 100% (3/3 params documented), so the baseline is 3. The description adds context about the theme parameter ('when a Standout app theme is installed') and specifies source as React/JSX/HTML, but it does not meaningfully augment the already-clear schema descriptions. No additional parameter syntax or constraints are provided.

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

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

The description opens with 'Deterministic critique for APPLICATION UI' and enumerates specific slop patterns (radius chaos, card-in-card, gray-on-gray text) that the rulebook checks. It further distinguishes itself from critique_design by explicitly targeting application UIs versus marketing pages, making the tool's purpose unmistakable and differentiated from siblings.

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 'Use after building every view; re-run until the score clears 85.' It also directs the agent to use critique_design for marketing/landing pages, providing a clear alternative. This is a textbook example of 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?

With no annotations, the description carries the transparency burden and does well: it discloses the output (locked tokens, contrast-checked, two radii, five-step type scale, usage law, slop rulebook) and the relationship to website directions. It doesn't mention error cases or rate limits, but for a 'get' tool this 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 front-loaded with the core noun and details, but it's a long block with redundancy (e.g., 'This is how a vibe-coded app stops looking AI-generated' and 'install the theme once and every view the agent builds matches' convey similar ideas). Some marketing language could be trimmed for tighter prose.

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 no output schema, the description thoroughly explains what will be returned (full token system, Tailwind v4 mapping, usage law, rulebook) and the interaction model (browse menu vs. fetch by id). It doesn't cover error handling, but given the tool's scope and good parameter documentation, it is reasonably 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%, so baseline is 3. The description adds value beyond the schema by explaining the 'theme' parameter with concrete examples (graphite-ledger, terminal-grade-ui) and clarifying that 'response_format' applies to menu browsing. This enriches the bare schema definitions.

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+resource: 'Get a LOCKED design-token system for application UI', enumerating exact contents (color roles, radii, type scale, spacing, elevation, motion tokens, Tailwind v4 mapping). This clearly distinguishes it from sibling tools like get_design_direction or get_asset_pack by focusing on 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 explains when to call with no theme to browse the menu (free) versus with a theme id to receive the full system. It implies usage for building app UIs and mentions brand DNA with website directions, but does not explicitly name alternative tools or exclusion criteria.

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 clearly indicates the output is ready-to-paste CSS, which implies a read/generation operation with no side effects, but it does not explicitly state that it is non-destructive, does not require special permissions, or describe any edge-case behavior (e.g., what happens with unknown direction IDs).

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 immediately states the core value proposition ('Ready-to-paste CSS for a direction') followed by a concise, organized list of included elements. Every clause adds useful detail, with no fluff 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?

The tool has only two parameters, both well-documented in the schema, and no output schema, so the description's detailed enumeration of the returned CSS elements provides good context. It could be more complete with an example or clarification of how 'query' and 'direction' interact, but for a low-complexity asset retrieval tool it is adequate.

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

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

The input schema already provides 100% descriptive coverage for both parameters ('direction' and 'query'), so the baseline is 3. The description adds no additional parameter-level meaning beyond noting the output is for a direction, which partially aligns with the 'direction' parameter but does not enhance the 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 identifies the tool as producing a ready-to-paste CSS asset pack for a given design direction, enumerating specific contents (custom properties, button/card/nav treatments, texture, fonts, motion recipe list). This distinguishes it from sibling tools that focus on individual components or generic design directions, though it lacks an explicit verb like 'get' or 'retrieve'.

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 phrase 'for a direction' implies the tool should be used when a complete CSS bundle for a specific design direction is needed. However, it does not state when to prefer this over sibling tools like get_component_code or get_motion_recipes, and provides no exclusions or alternative 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 provided, the description carries the full burden of behavioral disclosure. It adds meaningful context: components are finished, zero-dependency, written against semantic tokens, and include built-in states (loading, empty, error). It also notes reliance on installing the theme first. This goes well beyond a generic 'get' description and provides actionable behavioral expectations.

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 compact yet highly informative. It front-loads the primary action and resource, then efficiently enumerates the component types and adds the crucial prerequisite about installing the theme. Every clause contributes to understanding, with no redundant or filler content.

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

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

For a tool with no output schema and no annotations, the description covers the essential aspects: what the tool returns (finished components with built-in states), the tech stack (React + Tailwind), the theme dependency, and the valid component options. It could explicitly state the return format (e.g., source code string) or error behavior, but 'Get components' with React + Tailwind and the theme reference strongly implies code, making the description adequate for selection and 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 description coverage is 100%, so the schema already documents both parameters (theme and component). The description adds some context by linking theme to get_app_theme and listing the component ids, but this largely overlaps with the schema's parameter descriptions. It does not introduce significant new semantics, so the 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 specifies that the tool retrieves finished application-UI components built in React + Tailwind, enumerates the included component types (app shell, stat row, data table, settings form), and notes they are written against a theme's semantic tokens. This distinguishes it from sibling tools like get_section_code or get_premium_components by emphasizing the finished, token-bound nature.

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

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

The description provides clear usage context by instructing the agent to install the theme first via get_app_theme, and explains the workflow: components come with built-in states, so the agent only needs to wire data and content. It does not explicitly name alternatives or when-not-to-use scenarios, but the prerequisite and intended usage are evident.

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 and does so thoroughly: it discloses the catalog size (14 directions, 9 light/5 dark), the behavior when business is omitted (returns intake questions), and the server-side fetching for redesigns. Edge cases are explicitly covered, making the tool's behavior predictable.

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 dense paragraph that front-loads the purpose and deliverables, then flows through usage, fallback, and redesign specifics. Every sentence adds useful information without redundancy, and the structure is easy to parse despite the density.

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

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

The description covers the main success path, the minimal-info fallback, and the redesign workflow, all within a complex multi-parameter tool. It does not have an output schema, but it lists the response contents explicitly, providing enough detail for an agent to invoke and interpret 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 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: tone is tied to catalog counts, business omission triggers intake questions, and current_site_url triggers server-side fetch with content inventory. This enrichment lifts the score above baseline, though not all params get extra explanation.

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 gets a complete, distinctive, reference-backed art direction for a website, enumerating specific deliverables like palette, type pairing, layout DNA, and more. This distinguishes it from sibling tools that focus on individual components (hero, motion, section code), making its role 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?

Explicitly instructs to use FIRST, before building, and provides clear guidance for minimal-information scenarios (call anyway, ask questions) and redesigns (pass current_site_url). While it doesn't name alternative tools, it establishes precedence and gives concrete context for when to call 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?

With no annotations, the description carries the burden of disclosure. It explains the contents of the returned payload, which is useful behavioral context. However, it does not mention any limitations, side effects, or the impact of the response_format parameter (e.g., how output differs between 'md' and 'json'). This is adequate but not rich.

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

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

The description is a single, focused sentence that front-loads the core action ('Get the full step-by-step payload') and then lists the contents without wasted words. Every phrase 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 the tool's simplicity (2 params, no output schema), the description covers the essential context: what the tool returns and its scope ('one user journey'). It does not explain potential use cases or how to obtain flow_id, but this is partially covered by the schema. Overall, it is complete enough for a read-only getter.

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 schema already documents both flow_id and response_format thoroughly. The description adds no additional parameter-level meaning beyond what the schema provides. The baseline of 3 is appropriate when schema does the heavy lifting.

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 action ('Get') and the resource ('full step-by-step payload for one user journey'), listing specific content components (problem, steps, user actions, system responses, related direction ids, agent implementation notes). This distinguishes it from sibling tools like search_flows (which likely returns summaries or lists) and get_design_direction (which focuses on a specific 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?

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., search_flows, get_design_direction). It implies that the flow_id comes from search_flows (via the schema), but does not state it in the description. There is no 'use this when...' or 'instead of...' 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 fully discloses key behaviors: free and unmetered, capped per network, returns key plus reconnect instructions. It also informs about limitations (25 calls, no signup). No annotations to contradict.

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

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

The description is a compact paragraph with no filler. It front-loads the purpose, then gives usage conditions, return info, and a caution. Every sentence provides necessary 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 zero-parameter tool, the description comprehensively covers what it does, when to use it, when not to use it, what it returns, and limitations (capped per network). No output schema exists, but the return value is explicitly described.

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

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

The tool has zero parameters, so schema coverage is 100%. The description adds context about the return value and constraints, but since there are no inputs, it appropriately focuses on the output and usage conditions.

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 self-provisions a free Standout trial key with specifics (25 calls, no signup). It distinguishes itself from sibling tools by focusing on trial key provisioning for license errors, a unique action among the listed 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?

Explicit when to use: 'when no license key is configured or your Standout calls return a license error.' Also explicitly warns against calling when a working key exists, providing clear exclusion criteria.

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 explains the tool returns a concept with specific content components and includes quality constraints (e.g., 'no marketing cliches') and copy-paste CSS. While it doesn't mention rate limits or auth, the read-only nature is implicit in 'get'. This is adequate behavioral disclosure 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 a single, information-dense sentence that front-loads the main purpose and then lists deliverables in a clear sequence. Every phrase adds value 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?

Despite having no output schema or annotations, the description enumerates all key content of the output (headline, subline, CTA, background, motion CSS) and notes the dependency on design direction. It lacks explicit return structure, but for a concept generation tool it's sufficiently 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%, so the baseline is 3. The description adds a connection between the direction parameter and the output 'matched to the design direction,' but the schema already explains both parameters sufficiently. No substantial additional parameter semantics are introduced.

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

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

The description clearly states the tool retrieves a 'complete hero section concept' and enumerates specific deliverables (headline, subline copy, CTA labels, background treatment, ambient motion CSS). This distinguishes it from sibling tools like get_section_code or get_component_code by focusing on the full creative concept rather than just 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 after obtaining a design direction, and the direction parameter explicitly references get_design_direction as the source. It provides clear context on when to use this tool (to generate a hero concept tied to a design direction) but does not explicitly exclude alternatives. This is a clear context without exclusions.

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 tool's output categories and the effect of the 'direction' parameter (palette-filled shader code), but does not describe return format, whether multiple results are returned, or any limitations. This is adequate but not rich.

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

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

The description is a single, efficient paragraph packed with illustrative examples. It starts with the core value proposition and ends with usage instructions with no filler. The list of recipe types is long but necessary to convey scope.

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 (multiple types of motion, shader pieces) and no output schema, the description covers key aspects: what is provided, how to request, and how direction affects output. It lacks a mention of output format but does enough for an agent to select and 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?

Schema coverage is 100%, providing baseline 3. The description adds value by semantically tying the parameters to usage: 'Request by ids' (ids), 'describe what you need' (query), and 'pass direction for palette-filled shader code' (direction). It adds examples that enrich the 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 a specific verb+resource: 'Production-ready motion for any stack' with detailed examples of recipe types (CSS/vanilla-JS) and shader pieces (WebGL). It distinguishes itself from sibling tools by focusing exclusively on motion recipes, not generic components or 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 provides explicit usage context: 'Request by ids or describe what you need; pass direction for palette-filled shader code.' This tells the user how to invoke the tool, but it does not explicitly mention alternatives or when not to use it, though its unique motion-focused purpose makes it distinct.

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 transparency burden. It discloses that the tool returns copy-paste snippets with reduced-motion fallbacks, which is a useful behavioral detail. However, it does not mention any side effects, dependencies, or limitations, and as a simple retrieval tool, this level of disclosure is adequate but not rich.

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

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

The description is two sentences: the first lists example primitives, the second states the return format and usage context. It is front-loaded with a clear identifier and every sentence serves a purpose, though the enumeration is slightly lengthy.

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 9 parameters, no output schema, and no annotations. The description gives the return type and usage cue, but it does not explain how the many filters interact, what a typical response contains, or how the tool behaves with no parameters. It is sufficient for a basic understanding but leaves room for ambiguity.

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 example keywords like 'premium' and 'luxury' that overlap with the query parameter's description, but does not provide meaningful new insight into any specific parameter beyond what the schema already states.

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 premium UI primitives (hero backgrounds, Framer-style dials/gauges, glass cards, etc.) as copy-paste HTML/CSS/vanilla JS snippets. The verb 'Returns' specifies the action, and the specific examples of primitives distinguish it from sibling tools like get_component_code or get_motion_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 when to use the tool: 'Use when the user asks for premium, luxury, beautiful, wavy, Framer-like, glass, 3D controls, or high-end motion.' This provides clear, actionable guidance for selecting this tool over 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 present, so the description carries the burden. It clearly implies a read-only retrieval and lists the return contents, which is helpful. However, it does not mention the default response format (md vs json) or any error/edge-case behavior, leaving some ambiguity beyond the schema.

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 dense sentence communicates a lot of information without fluff. The long list of payload contents could be slightly more scannable, but each item earns its place and there is 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?

The description adequately explains what the tool returns and the parameters are well-documented in the schema. For a simple get operation, it covers the essentials, though it lacks an explicit note about response_format defaults and how this fits into the overall workflow with siblings.

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 (reference_id, response_format). The description adds no extra parameter semantics beyond what the schema already states, so the baseline 3 applies.

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 the specific verb 'Get' with a clear resource ('full structured payload for one reference') and enumerates the exact contents (source URL, categories, colors, etc.). This distinguishes it from siblings like search_references or get_similar_references, which likely return lists or summaries.

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

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

Usage context is implied (e.g., after search_references, as the schema notes reference_id comes from there), but the description gives no explicit when-to-use/not-to-use guidance or names alternatives. It simply says what the tool does without exclusions.

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 transparency burden. It discloses that sections are pre-seeded with accent/expression, composed by a designer, and should not be recomposed. It lacks specifics like return format or side effects, but for a read-oriented code retrieval tool, the description 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 three sentences: the first front-loads the core function, the second provides usage instructions, and the third adds a value proposition. Every sentence earns its place with no fluff 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?

The tool has no output schema, so the description should explain return values. It does say 'HTML/CSS page sections' and implies assembly. It also covers dependencies (direction, signature_move). It could detail the output structure more precisely, but it gives a sufficient mental model for an 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the 'business' parameter seeds the expression, and elaborates on 'signature_move' by stating it 'ORDERED and FRAMED to that concept' and leads with Creative Spine, Memorable Move, and Differentiation Rules. It also implicitly ties the 'sections' parameter to the listed section types.

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 'Finished, art-directed HTML/CSS page sections for a design direction' and lists specific section types (nav, hero, offer, image band, story, footer). It distinguishes itself from siblings by emphasizing the designer-composed, production-ready nature and its role after 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?

The description gives explicit usage guidance: 'Use AFTER get_design_direction' and instructs to 'assemble the sections and replace only the content (copy + images), never the composition.' This provides a clear workflow and when to use the tool, though it does not name alternative tools for exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses that browsing without a technique is free/unmetered, and mentions built-in features like contrast scrims, mobile behavior, and reduced-motion. It does not describe the output format or failure modes, but it covers several behavioral aspects beyond a simple '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 a dense paragraph but front-loaded with the tier comparison and packed with specific technique names, features, and usage instructions. Every clause provides useful information, though it reads as a wall of text. It earns its length for a complex tool.

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 complex tool with no output schema and no annotations, the description explains techniques and included assets but lacks details on what the 'full skeleton' output actually looks like (e.g., HTML, code, visual template) and does not mention prerequisites or behavior when direction is omitted. This leaves significant gaps for an agent to fully anticipate the tool's return.

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% since both params have descriptions. The description adds value by explaining the browse-vs-full-skeleton semantics of the `technique` param and that `direction` fills the skeleton with the pack's hexes, enriching the parameter meaning beyond the schema.

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

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

The description clearly states the tool's purpose: providing 'finished showpiece skeletons for scene-led, art-directed pages' and enumerates specific techniques (world hero, video world hero, type-scene interlock, etc.). It also explicitly distinguishes itself as 'the tier ABOVE the design directions', differentiating it from the sibling tool 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?

The description provides explicit when-to-use guidance: 'Use when the brief says wow, cinematic, premium beyond a normal landing page.' It also contrasts with design directions as a higher tier, and explains the invocation pattern: browse menu without a technique (free), get full skeleton with a technique id. This 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?

With no annotations, the description carries the burden of disclosing behavior. It usefully explains the similarity criteria (tags, categories, use cases, direction ids), which is beyond the schema. However, it does not describe the output shape, result limits, or any side effects, leaving some behavioral ambiguity.

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 core function, and every clause adds value. The usage guidance is integrated 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 tool's moderate complexity, the schema covers all parameters, and the description provides the key purpose and usage context. However, with no output schema and no annotations, a note about the return format would have made it 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?

The schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds no parameter-specific details, but the schema already fully documents reference_id, limit, and response_format.

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 ('Find') and identifies a clear resource ('references similar to a known reference') with explicit matching criteria (shared tags, categories, use cases, StandOut direction ids). This distinguishes it from siblings like search_references or get_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?

The description provides a clear contextual trigger: 'Use after finding one strong reference to broaden the evidence set.' This tells the agent when it is appropriate, though it does not explicitly name alternatives or 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds the non-obvious fact that 'Browsing the menu does not consume a metered call,' and implies a read-only operation via 'Browse.' It does not explicitly state return format details, but the schema covers response_format. This goes beyond a simple purpose statement, though it could be more explicit about output structure.

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 organized and front-loaded with purpose in the first sentence. The following sentences provide usage guidelines, downstream integration, and a behavioral note. Each sentence earns its place, though it is longer than necessary due to the downstream tool references. Still, it remains skimmable 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?

Given the tool's simplicity (two optional enum params, no output schema), the description is sufficiently complete. It explains the output content (taglines, vibe tags, best-for), hints at id availability, and covers the non-metered aspect. It does not explicitly describe the JSON structure, but response_format is in the schema, and the description provides enough context for an agent to understand what to expect.

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% description coverage for both parameters (tone and response_format), each with enums and descriptions. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate. It mentions ids and downstream usage but does not elaborate on the parameters themselves.

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: 'Browse the full pick a vibe menu' and lists the specific content (14 named art directions with taglines, vibe tags, and best-for). It distinguishes itself from sibling get_design_direction by explicitly saying it is for when the user wants to SEE directions rather than have the tool auto-pick.

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: 'Use when the user wants to SEE the available directions and choose one themselves, rather than have get_design_direction auto-pick.' It also describes how to use the output by passing an id to four sibling tools, making the usage context very 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 the burden. It adds useful context ('active', 'last known scores and check times', 'Unmetered') but does not disclose authentication needs, rate limits beyond unmetered, or error/empty-list behavior. It gives a moderate level of transparency, 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?

The description is a single concise sentence that front-loads the verb and resource, then adds the output fields and an 'Unmetered' note. Every word earns its place; no fluff 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?

For a simple 0-param list tool with no output schema, the description adequately explains what is returned and the unmetered nature. It lacks details on pagination or empty results, but given the low complexity, it is sufficiently complete. A small gap remains around ordering or potential large data, so not a full 5.

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, which sets a baseline of 4. The description adds no parameter details (none are needed) but does clarify the license scope, which is a contextual bonus. No gaps exist since there are no parameters to describe.

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 the specific verb 'List' and names the resource: 'active site watches' with 'last known scores and check times.' This clearly distinguishes it from siblings like watch_site and unwatch_site, which perform different actions.

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 context by scoping to 'this license's active site watches' and indicating a list operation. While it does not explicitly name alternatives or when-not-to-use conditions, the activity is self-evident and complements sibling tools that create or remove watches.

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 discloses that the tool emits analysis artifacts (scores, patches, creative direction, implementation prompt) rather than directly mutating the site. This implies a read-only/planning behavior, which is a meaningful behavioral trait. It does not mention rate limits, auth, or side effects, but for a planning tool that produces outputs, the description is adequately 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?

Three sentences, front-loaded with the tool's purpose ('Detailed transformation plan for power users'), then an alternative directive, then a list of concrete outputs. Every sentence contributes distinct information 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?

The description explains the tool's key outputs (scores, fix patches, creative direction, implementation prompt) and its scope relative to polish_and_prove. It does not describe the exact output structure or parameter interactions, but the absence of an output schema and the presence of detailed parameter descriptions mean the description is sufficient for a qualified 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?

The input schema already provides a description for all 7 parameters, giving 100% coverage. The description does not add semantic detail beyond the schema—it never mentions url, source, vibe, etc.—so a baseline score 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 states exactly what the tool does with specific verbs: 'classifies and scores a site, returns exact fix patches, chooses a creative spine and direction, and emits a paste-ready implementation prompt.' It also distinguishes itself from the sibling polish_and_prove by explicitly pointing to that tool for the full workflow, making its own scope clear.

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 an explicit alternative directive: 'prefer polish_and_prove' for the complete inspect/fix/rerender/client-proof workflow, implying this tool is for a narrower transformation-plan use case. It also identifies the audience as 'power users' and describes the tool as a 'detailed transformation plan,' giving context on when it's appropriate. It stops short of enumerating all exclusions from the many siblings, but the single alternative 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 the full disclosure burden. It explains that the tool captures a baseline, scores renders, chooses direction, returns an implementation contract, and compares before/after for a report. It explicitly states the agent must apply fixes in the repository, which is a notable behavioral expectation. It does not mention permissions or side effects, but the core workflow behavior is well disclosed.

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 more verbose than the minimal example, but it is well-structured with 'First call' and 'Final call' phases and front-loads the primary use case. It is dense with necessary instructions; the repetition of 'Standout' is slightly redundant but does not obscure meaning. Every sentence contributes to understanding the workflow.

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

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

Given no output schema, the description explains key return artifacts: the exact implementation contract, a client-safe before-and-after report, and a share link. It covers both phases of the workflow, the required inputs for each, and the final outcome expectation. For a complex tool with 10 parameters and no formal output schema, this description is remarkably 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 the baseline is 3. The description adds significant semantic value by mapping parameters to workflow phases: url/source/business for the first call, and after_url/after_source for proof mode. This explains relationships between parameters beyond the schema's individual field descriptions, though not every parameter is explicitly discussed.

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 this as 'THE PRIMARY STANDOUT WORKFLOW' and states it is for making an AI-built website client-ready without choosing individual design tools. It distinguishes itself from sibling tools by framing a two-phase workflow (polish then prove) with explicit deliverables, so the agent knows exactly what the tool accomplishes.

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 when-to-use guidance: 'Use this when a user wants an AI-built website made client-ready without choosing individual design tools.' It also instructs on first and final call usage, including which parameters to pass, and adds a clear directive: 'Do not stop after returning advice; the completed outcome is fix, rerender, prove.' This leaves no ambiguity about when to invoke this workflow versus 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 present, so the description carries the full burden. It states the search action and gives examples, but it does not describe return format, pagination, or whether results are markdown/JSON (leaving that to the response_format param). Since search is inherently read-only, the risk is low, but the description lacks explicit behavioral detail beyond the action.

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 exactly two sentences with no filler. The first sentence front-loads the core action and examples; the second adds a crisp usage guideline. 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 a thorough schema, the description gives essential purpose and a clear usage signal. It doesn't explain return value shape, but the response_format param hints at md/json options, and no output schema exists. The examples give a solid mental model of what 'flows' means, making it adequately complete for selecting and invoking the 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% with descriptions for all 5 parameters, so the baseline is 3. The description adds context for query term examples like 'api key onboarding' and 'pricing', but does not elaborate on limit, category, direction, or response_format beyond what the schema already states. The added value is marginal.

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 reference-backed user journeys' and provides concrete examples (API key onboarding, pricing selection, hospitality booking). The closing clause 'Use when the page is part of a multi-step task, not just a visual screen' distinguishes it from siblings like search_references, giving the tool a clear identity.

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 a usage condition: 'Use when the page is part of a multi-step task, not just a visual screen.' This tells the agent when to invoke it, though it doesn't name alternatives or exclusions, so it stops short of a perfect score.

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?

Without annotations, the description carries the burden, and it clearly describes the search behavior and the nature of results (real public-product patterns). It does not mention side effects, auth, or rate limits, but for a read-only search tool this is not a major gap; still, it could explicitly state non-destructive 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?

Two sentences, front-loaded with the action and resource, no redundancy. Every clause adds 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 search tool with no output schema, the description effectively communicates the scope of the library and the shape of results (source URLs, color roles, etc.), covers when to use it, and lets the rich schema handle parameter details.

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

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

Schema description coverage is 100%, so the schema naturally documents all 6 parameters. The description adds no extra parameter-level detail beyond listing content categories, which mirrors the existing schema. 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 uses a specific verb 'Search' and identifies the exact resource 'Standout's curated reference library', listing the types of patterns included (style, screen, component). This clearly distinguishes it from sibling tools like get_reference (specific retrieval) and search_flows (flow search).

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?

States explicitly to 'Use before or during a build when you need evidence-backed visual patterns,' giving clear timing and intent. However, it does not name alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description must fully disclose behavior. It does explain the output payload and the evidence-based decision logic, but it fails to mention whether the tool has side effects (e.g., whether 'implementation lock' mutates any state) or requires prerequisites. This is a moderate transparency gap.

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

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

The description is two sentences: the first front-loads the core function and return set, the second adds usage guidance. Every clause contributes meaningful information, and there is no redundant or filler 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?

Given the tool's complexity (8 parameters, no output schema), the description adequately covers purpose, return values, and usage context. It falls slightly short by not explaining how references are selected when reference_ids are omitted (the query parameter behavior) and leaving 'implementation lock' undocumented, but the overall picture is reasonably 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 covers all 8 parameters with descriptions (100% coverage), so the description is not required to add parameter details. While 'business brief' and 'optional reference ids' align with schema, no additional semantic meaning is provided beyond the schema, meriting the baseline 3.

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 ('Turn') with a clear resource ('business brief plus optional reference ids') and states the outcome ('reference-backed build direction'). It enumerates distinct deliverables (chosen direction, references, flow patterns, build plan, implementation lock, next calls), which clearly distinguishes it from siblings like build_from_reference or 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?

The sentence 'Use when you want the agent to build from evidence instead of vibes' supplies a clear context for use. However, it does not explicitly name alternative tools or provide when-not-to-use conditions, so it stops short of a 5.

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

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

With no annotations provided, the description carries full burden. It discloses the one-time nature, the in-place upgrade, that it is free and unmetered, and the critical constraint that email must be explicitly provided by the user. Although it doesn't describe return values, the tool's side effects and safety boundaries are clearly 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?

Four succinct sentences, each serving a distinct purpose: what it does, when to call, a critical safety rule, and a reassurance about the in-place upgrade. No fluff, no repetition, and the key 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?

The tool is simple—one required parameter, no output schema, no annotations. The description covers the action, trigger condition, constraints, and post-condition, making it self-sufficient for an agent to invoke correctly. Given the low complexity, this 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 already has a clear description for the email parameter (100% coverage). The tool description adds extra meaning by emphasizing the prohibition against guessing or reusing emails and tying the email to the 'exactly as given' requirement. This goes beyond the schema's own wording, though only modestly.

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 action: 'Unlock 10 bonus calls on this trial key, one time only, in exchange for the user's email address.' It clearly identifies the resource (trial key), the condition (one time), and the exchange (email address). This distinguishes it from sibling tools like get_free_trial_key, which issue a trial key rather than adding bonus calls to an existing one.

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 usage trigger provided: 'Call this when the trial limit is reached and the USER has chosen the free-bonus option and given you their email in this conversation.' It also gives a strong exclusion ('NEVER guess, invent, or reuse an email...') and clarifies that the key is upgraded in place with nothing to reconfigure. This leaves no ambiguity about when to invoke 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 exist, so the description carries the burden. It adds 'Unmetered,' a useful behavioral detail beyond the schema. However, it does not disclose whether the operation is idempotent, what happens if the URL isn't watched, or any side effects, leaving some transparency 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 two sentences, front-loaded with the primary purpose, and includes only necessary extra details ('Unmetered'). No word is wasted.

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

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

For a single-parameter tool with no output schema, the description covers purpose, parameter guidance, and pricing behavior. It lacks error-case details, but these are not critical given the tool's simplicity and the schema's full coverage.

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 already provides a clear description of the url parameter (100% coverage). The description adds valuable context by specifying that the same URL as watch_site should be used, which clarifies the expected value beyond the schema's generic wording.

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 starts with 'Stop watching a site's design score,' which clearly states the verb and resource. It directly contrasts with the sibling tool watch_site, making its 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?

It instructs to pass the same URL given to watch_site, establishing a clear usage context and connection to the companion tool. It lacks explicit exclusion criteria but is sufficient for a simple inverse operation.

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 delivers: it discloses the audit frequency ('about once a day'), the exact alert triggers ('drop of more than 5 points, or falling below the 85 client-ready bar'), and the alert method ('emails'). This is exceptionally transparent for a watch-creation 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, front-loaded with the primary action, then key behavior, then a concrete use case and limit. Every sentence adds value and there is no repetition 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?

The description covers the purpose, usage scenario, behavioral details, and constraints (Pro requirement, limit of 10). With no output schema and simple parameters, this is complete enough for an agent to decide when to invoke and what to expect.

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%, with both 'url' and 'email' having clear descriptions. The tool description adds no additional parameter-level details, so the baseline of 3 is appropriate. It does not need to compensate for schema gaps.

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: 'Watch a live site's design score' and explains the monitoring behavior (re-audits daily, emails on regression). This distinguishes it from siblings like list_watches and unwatch_site, and the specific thresholds make it 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?

The description provides explicit usage context: 'Use it right after shipping a client site so a broken deploy is caught before the client sees it.' It also notes the license limit of 10 active watches. It does not explicitly mention alternative tools or when not to use it, 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.