Standout

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

With no annotations, the description fully handles behavioral disclosure—it explains the critique style, inclusion of live screenshots, and parameter preferences. It does not mention potential side effects or errors, but the behavior is clearly non-destructive.

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

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

The description is dense but well-organized, with the core purpose front-loaded and specific directives following. Every sentence adds value, though minor trimming could be possible without losing meaning.

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

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

Given the 4 parameters and lack of output schema, the description covers usage, parameter rationale, behavioral traits, and provides enough context for correct invocation. It does not explain the output format in detail, but the 'live screenshots' and 'prioritized fix list' are clearly mentioned.

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 covers all parameters, and the description adds valuable context: the 'url' is preferred, 'direction' is essential for design system alignment, and 'source' is an alternative. This enhances understanding beyond the 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 clearly states the tool's verb ('critique') and resource ('existing page'), and distinguishes it from sibling design tools like 'get_design_direction' and 'get_hero_concept' by focusing on feedback and AI-slop detection.

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 specific guidance on when to pass a URL vs. source, and stresses including the 'direction' parameter for pages built from 'get_design_direction', but does not explicitly state when not to use this tool or compare to alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only lists output contents but fails to mention side effects (none expected), idempotency, authentication needs, rate limits, or return format. The description does not confirm whether the tool is read-only or if it performs any mutations.

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

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

The description is a single sentence that packs many items, making it slightly dense. It is front-loaded with 'Ready-to-paste CSS' which is good, but the structure could be improved with bullet points or separate clauses for readability. Every word adds value, but conciseness is slightly compromised by the run-on nature.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description fully carries the transparency burden. It discloses the return structure (palette, type, layout, etc.), the catalog size (12 directions), tone filtering, interactive questioning when info is incomplete, and the redesign fetch behavior. It lacks mention of side effects or auth but covers the core workflow well.

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

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

The description is a single paragraph but packed with essential information. Every sentence adds value, covering purpose, usage, parameters, and edge cases. It could be more structured (e.g., bullet points) but remains concise and efficient.

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

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

Given 6 parameters, no output schema, and a complex tool, the description is remarkably complete. It explains the return format in detail, covers all parameter combinations, and addresses special scenarios (redesigns, unknown info). There are no obvious gaps for an agent to misuse 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% (all 6 parameters have descriptions). The description adds significant value beyond schema by explaining when to pass tone (to constrain the pool), how to handle minimal input (business name only), and the special redesign parameter (current_site_url). This contextual guidance is critical for correct tool use.

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

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

The description uses a specific verb ('Get') and resource ('art direction for a website'), listing many concrete deliverables. It clearly distinguishes from sibling tools by stating 'Use FIRST, before building' and by covering different aspects like redesigns and incomplete information.

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: 'Use FIRST, before building', explains tone selection, handles cases where only business name is known, and gives specific instructions for redesigns. It does not explicitly contrast with all siblings but is sufficiently directive.

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

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

No annotations are provided, so the description carries the full burden. It describes the return contents but does not mention read-only nature, auth requirements, or error cases. The listing of return data provides basic transparency.

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

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

The description is a single sentence that is front-loaded with the verb 'Get' and quickly lists key contents. No wasted words.

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

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

Given 100% schema coverage and no output schema, the description is sufficiently complete for a retrieval tool. It specifies what is returned, leaving no obvious gaps.

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

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

Schema coverage is 100%, with both parameters fully described. The description adds no additional meaning beyond the schema, so 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 clearly states the tool retrieves a full step-by-step payload for a user journey, listing specific contents (problem, steps, etc.), which distinguishes it from siblings like search_flows that return a list.

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 is implied: you need a flow_id from search_flows, but no explicit when-to-use or alternatives are provided. This is adequate but could be improved.

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

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

No annotations provided, so description carries full burden. It describes the output but does not mention behavioral traits like whether it modifies any state, requires authentication, or has side effects. It is adequate for a read-only concept generator but lacks depth.

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

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

Single sentence front-loading the key action and deliverables. Every word adds value; no fluff. Concise and well-structured.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the core functionality well. It could specify output format (e.g., how CSS is delivered) or constraints (e.g., copy length). Still, it is fairly complete for a concept generation tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add deeper meaning beyond the schema; it only explains overall output. 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 'Get' and resource 'hero section concept', listing exact deliverables (headline, subline, CTA, background, CSS). It clearly distinguishes from sibling tools like get_design_direction which returns direction packs, and critique_design which critiques designs.

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

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

No guidance on when to use this tool versus alternatives like get_flow or get_motion_recipes. The description only states what it does, not the context or prerequisites for calling it.

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

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

No annotations are provided, so the description carries full burden. It discloses that snippets are production-ready, plain CSS/vanilla JS, and framework-agnostic. However, it does not mention potential limits, error handling, or what happens if no match is found, which is adequate for a simple retrieval tool but could be improved.

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

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

The description is concise: two sentences plus a list of examples. It is front-loaded with the main purpose and immediately useful information, with no wasted words.

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

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

Given the tool's low complexity (2 optional parameters, no output schema), the description covers the essential aspects: what it does, how to request items, and examples. It might lack details on the response format, but overall it's sufficiently complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two usage modes (by ids or query) and providing concrete examples, which helps the agent understand how to use the parameters beyond the 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 clearly states the tool provides 'production-ready motion and texture snippets' and lists specific types (staggered entrances, scroll reveals, etc.), making it easy to distinguish from sibling tools like critique_design, get_asset_pack, or get_flow.

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

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

The description explains that users can request by ids or describe what they need, with examples for both. While it doesn't explicitly state when not to use this tool, the context from sibling tools and the clear purpose provide sufficient guidance.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the tool is read-only, any required permissions, data freshness, rate limits, or side effects. The read-only nature is only implied by the verb 'Get', but not explicitly stated.

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

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

The description is a single, efficient sentence that front-loads the action and then lists the payload contents. It contains no filler, but could be improved by breaking the list into a more structured format or adding a second sentence for usage guidance.

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

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

Given the absence of an output schema, the description partially compensates by listing the fields in the payload. However, it does not describe the overall structure (flat, nested), any limitations (e.g., maximum size, field types), or error conditions. For a tool with moderate complexity, the description is adequate but not thorough.

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

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

Schema description coverage is 100%, so the schema itself adequately documents both parameters (reference_id from search_references, response_format as enum). The tool description adds context about the output (the fields in the payload) but does not clarify parameter semantics beyond what the schema provides. Baseline is 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 clearly states the tool retrieves the full structured payload for a single reference and enumerates all included fields (source URL, categories, tags, etc.). It distinguishes itself from sibling tools like search_references (which lists multiple) and synthesize_direction_from_references (which requires multiple references). The verb 'Get' and resource 'reference' are specific and 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 implies usage when needing complete details for one reference, but it does not explicitly state when to use this tool versus alternatives like get_similar_references or search_references, nor does it mention any prerequisites (e.g., 'use after search_references to get a reference_id'). Guidance is minimal.

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

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

No annotations provided, so the description carries the burden. It explains sections are composed by a designer, seeded to the business with accent and expression applied. Does not mention error handling or rate limits, but provides adequate context 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?

Concise and well-structured. The purpose is stated first, followed by usage order and constraints. Every sentence serves a purpose with no fluff.

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

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

For a tool with 3 parameters and no output schema, the description is fairly complete. It explains the relationship to get_design_direction, the seeding process, and the composition constraint. Minor gaps like error cases are acceptable for this complexity level.

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 reasonable descriptions. The main description adds value by linking direction to get_design_direction and listing section types, complementing the schema without redundancy.

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, listing specific section types. It distinguishes from sibling tools like get_design_direction and others.

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

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

Explicitly states 'Use AFTER get_design_direction' and instructs to replace only content, never composition. Provides clear when-to-use and what-not-to-do guidance, differentiating from other tools.

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

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

No annotations provided, so description carries full burden. Discloses matching criteria (tags, categories, use cases, direction ids). Does not discuss auth, rate limits, or error behavior, but for a read-only tool this is adequate.

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

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

Two sentences, first states purpose, second gives usage guidance. No extraneous text, front-loaded and efficient.

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

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

With no output schema, description doesn't explain return format, but input schema includes response_format parameter. Tool complexity is low; overall enough for agent to use. Could mention output format for completeness.

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

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

Schema coverage is 100% with descriptions for all three parameters. Description adds no extra parameter-level detail beyond what schema provides, so 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?

Specifies verb 'find' and resource 'similar references' with explicit matching criteria (shared tags, categories, use cases, StandOut direction ids). Clearly distinguishes from sibling search_references by stating it broadens evidence after finding one strong 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?

States when to use ('after finding one strong reference to broaden the evidence set') and implies purpose. Does not explicitly list when not to use or alternative tools, but the context is sufficient.

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

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

No annotations are provided, so the description must carry behavioral transparency. It only describes the purpose and usage, but does not disclose side effects, auth requirements, rate limits, or any other behavioral traits beyond the basic function.

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

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

Two sentences, front-loaded with examples and usage guidance. Every phrase earns its place with no redundancy.

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

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

With 5 parameters and no output schema or annotations, the description covers purpose and usage but omits behavioral details, return format (though implied by response_format parameter), and how results are structured. Adequate but not complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds example search terms ('api key onboarding', 'pricing') that provide context beyond the schema, but does not significantly enhance understanding of parameters like 'category' or 'direction'.

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

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

The description clearly states it searches for reference-backed user journeys and provides concrete examples like 'API key onboarding' and 'pricing selection'. It also distinguishes from visual screens, which helps differentiate from siblings like search_references.

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

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

Explicitly states when to use: 'Use when the page is part of a multi-step task, not just a visual screen.' No explicit when-not-to-use, but the context implies alternatives.

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

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

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

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

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

Two sentences with no wasted words. The first sentence defines the tool's action and output, the second gives usage guidance. Information is front-loaded and every word earns its place.

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

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

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

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

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

All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by providing example query terms ('developer tool pricing', 'api key dashboard') and context for 'direction' (StandOut direction id), enhancing understanding beyond schema.

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

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

The description clearly states 'Search Standout's curated reference library' with a specific verb and resource, and lists what it returns (style, screen, component patterns). It does not explicitly differentiate from sibling tools like get_reference or get_similar_references, but the verb 'search' implies a broad retrieval vs. specific get.

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

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

The description explicitly says 'Use before or during a build when you need evidence-backed visual patterns,' providing clear when-to-use context. It does not mention when not to use or suggest alternatives, but the context is sufficient.

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

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

No annotations exist, so the description carries the full burden. It discloses the tool's transformative nature (synthesizing from references) and return fields, but does not clarify whether it has side effects, requires specific permissions, or what 'implementation lock' entails. The description is adequate but lacks depth on behavioral boundaries.

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 concise sentences: the first defines the action and output, the second provides usage guidance. Every part is relevant and front-loaded.

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

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

Given the tool's complexity (8 parameters, no output schema), the description adequately covers its purpose and output. It could mention that reference_ids should be obtained from search_references beforehand, but overall it provides sufficient context 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 baseline is 3. The description adds value by stating that reference_ids come from search_references, but it does not elaborate on other parameters beyond their 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 uses specific verbs ('Turn', 'Returns') and clearly identifies the resource ('business brief plus optional reference ids') and the output ('reference-backed build direction'). It distinguishes from sibling tools by emphasizing evidence-based building over 'vibes', which contrasts with 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 phrase 'Use when you want the agent to build from evidence instead of vibes' provides clear context for when to employ the tool. However, it does not explicitly state when not to use it or mention alternatives like get_design_direction for cases without references.

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