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

With no annotations, the description discloses the side effect of writing a file when save_to_project is set and specifies the file path. However, it does not detail overwrite behavior, error handling, or permission requirements, 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?

Two concise sentences: first states purpose and content, second adds conditional behavior. No superfluous information, efficiently communicates core functionality.

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 two parameters and no output schema, the description explains the main action and optional save. It could mention that it generates a document without modifying the original style, but overall it is sufficient for an agent to understand what the tool does.

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 100% coverage with clear descriptions. The tool description adds context by explaining the file path construction from save_to_project, going beyond the schema. Good addition but not essential.

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 renders a Refero style as a DESIGN.md file with specified contents (frontmatter, north star, etc.) and optionally writes it to a project folder. This distinguishes it from sibling tools that retrieve, list, or search styles.

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 what the tool does but lacks explicit guidance on when to use it over alternatives like refero_get or refero_search. No when/ when-not or comparison to siblings is provided.

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 fuzzy matching behavior and acceptable input types. It does not explicitly state the tool is read-only or describe failure modes (e.g., no match found), but the intention is clear and no contradictions exist.

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, no redundancy, front-loaded with the primary action. Every word adds value—first sentence states purpose, second sentence details input flexibility and matching algorithm.

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 could mention what the tool returns (e.g., JSON object of the design system), but for a simple fetch operation, the description is sufficiently complete. The context of sibling tools helps, and the tool is straightforward.

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 the 'identifier' parameter as 'uuid, hostname/URL, or site name' (100% coverage). The description adds value by explaining fuzzy matching (Levenshtein distance 2) and giving an example, which goes beyond the schema's basic description.

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

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

The description clearly states the tool fetches "the full design system for a single style," specifying the verb 'Fetch' and the resource 'full design system for a single style'. It distinguishes itself from sibling tools like refero_list (list all), refero_search (search), and refero_similar (find similar), which have 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 explicitly lists acceptable input formats (uuid, hostname/URL, site name) and provides an example ("Cursor"). It also mentions fuzzy matching with Levenshtein distance 2, giving clear guidance on how the identifier will be resolved, which helps the agent choose correct inputs.

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

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

No annotations provided, so description must cover behavior. It mentions read-like operation ('browse') and stable ordering, but does not disclose caching, rate limits, or whether the mirror is synced. Adequate but minimal.

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, no wasted words. Purpose and key details are front-loaded, making it easy to parse.

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

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

Covers pagination, ordering, and filters. No output schema exists, but description could mention return structure. Still, given the tool's simplicity and thorough schema descriptions, it is largely 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 already describes all 4 parameters with 100% coverage. Description adds no additional meaning beyond restating 'optional theme/tag filters' and pagination. 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?

Description clearly states the tool browses a catalog mirror with optional filters and pagination. Verb 'browse' and resource 'local catalog mirror' are specific, and the ordering detail distinguishes it from sibling tools like refero_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?

Implies usage for browsing/filtering the catalog, but does not explicitly compare with alternatives (e.g., refero_search for full-text search, refero_similar for similar sites). No guidance on when not to use.

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

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

Discloses destructive behavior (overwrite local mirror) but lacks details on authorization, side effects, rate limits, or synchronous/asynchronous nature. No annotations to supplement.

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 efficient sentences: first states action, second provides use case. No fluff, perfectly front-loaded.

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

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

Given zero parameters and no output schema, description adequately explains purpose and when to use. Lacks mention of return value or sync/async but sufficient for a simple refresh.

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 has zero parameters, so description doesn't need to document any. Schema coverage is 100%. Baseline 4 for no 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?

Clearly states the action: force full re-fetch and overwrite local mirror. Specifies the resource (styles.refero.design catalog) and implies the verb 'refresh'.

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 when-to-use: after catalog changes and wanting to avoid 24h TTL. Implies alternative is waiting or using other tools like refero_get for normal reads.

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

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

No annotations provided, but the description discloses the search mechanism (embedding or BM25 fallback), caching behavior (mirrored on first call), and refresh policy (every 24 hours). This explains backend behavior adequately for a read-only search tool, though no side effects are mentioned.

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

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

Three concise sentences covering purpose, algorithm, and caching. No redundant information; all sentences earn their 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?

Without an output schema, the description does not specify the structure of returned results (e.g., fields like name, tags, thumbnail). Also lacks details on how tag filtering interacts with the search. Adequate but has 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 clear parameter descriptions. The description does not repeat parameter details but adds context about the search algorithm, which is separate from parameter definitions. 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?

Clearly identifies the tool as a natural-language search over a specific catalog (styles.refero.design). It distinguishes from siblings like refero_list (listing) and refero_similar (similarity search) by emphasizing vibe-based search. The mention of embedding vs BM25 fallback adds specificity.

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?

Implies use for natural-language queries but does not explicitly state when to avoid this tool or prefer siblings. No direct comparison with sibling tools, leaving the agent to infer context from names.

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

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

No annotations provided; description does not disclose read-only nature, required permissions, or any side effects. Minimal behavioral info beyond purpose.

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

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

Two concise sentences with no fluff. First sentence states purpose, second gives usage context.

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

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

No output schema; description does not hint at return format or pagination. However, tool is simple with good sibling context, so 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 covers both parameters with descriptions; description adds no extra meaning. Baseline 3 due to 100% schema coverage.

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 'recommendation list for a given style' and distinguishes from siblings by referencing refero_search as a precursor.

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

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

Explicitly says 'Useful for follow-up exploration once you've found a candidate via refero_search', which tells when to use it. Does not explicitly exclude alternatives, but context is sufficient.

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