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

With no annotations, the description carries the full behavioral burden. It usefully discloses the Pro-key authentication requirement and describes what is returned (source plus shared helpers), but it omits error behavior, rate limits, and whether the operation has any side effects.

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

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

The description is two tight sentences with no wasted language. The purpose and examples are front-loaded, and the licensing and discovery notes follow naturally.

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 three-parameter read tool with no annotations or output schema, the description covers purpose, authentication, parameter examples, and what is returned. It could clarify the return shape or format, but 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 description coverage is 0%, so the description must compensate. It does so by explaining all three parameters semantically: category and block with examples, and screen as optional. It could specify allowed values more fully, but the registry URL helps.

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 a specific verb and resource: retrieving the React source of a UI block, optionally for one screen, plus shared helpers. It gives concrete examples ('category app', 'block billing'), making the tool's output clear. However, it does not explicitly differentiate from siblings like get_component or list_components.

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

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

It states a prerequisite (WunderUI Pro key in WUNDERUI_LICENSE_KEY) and points to a registry index URL for discovering blocks, which implies usage. But it gives no guidance on when to use this tool versus alternatives, and no exclusions or conditions are stated.

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 behavioral burden. It does useful work by disclosing the breadth of what is looked up — the argument also resolves hooks, providers and utilities (useToast, ThemeProvider), not just components — and it implies a read-only retrieval. It does not say what happens on an unknown name (error vs empty result) or whether results are cached/versioned.

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 purpose is front-loaded in the first clause and the rest is a dense but scannable inventory of return contents. It is a long single sentence, but with no output schema the inventory earns its space; only minor tightening is possible.

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?

Because there is no output schema, the description must describe return shape, and it does so thoroughly (props table fields, anatomy, CSS variables, import line, docs link). The remaining gap is behavioral rather than structural: no error/miss handling and no guidance relative to list_components.

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 'name' accepted formats (export name, slug, title) are already documented in the schema and the description adds nothing there. It does slightly extend the semantics by revealing that the identifier can also target hooks, providers and utilities, which the schema does not say.

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 opening clause 'Everything needed to use one component correctly' plus the enumeration (exported names, prop signature, anatomy, CSS variables, import line) makes it unambiguous that this is a per-component documentation lookup. It is distinguishable from list_components by implication, but the description never names the sibling or states the contrast explicitly.

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 only implied: an agent infers 'call this when you already know which component you want.' There is no explicit when-to-use, no when-not-to-use, and no reference to list_components as the discovery path before calling this one.

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 does disclose the read-only, single-document nature and that the output is a markdown doc, but says nothing about size/verbosity, whether the full document is large, cost, or that a targeted section is cheaper — relevant for a document this broad.

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 tight sentences, content list first, trigger second — well front-loaded with no filler. Slightly overlong on the enumeration, but every item 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 zero-required-param, no-output-schema tool, the description tells the agent what the returned document contains and when to fetch it, which is most of what is needed. The missing piece is that the document can be requested per-section and how this aggregate relates to the granular sibling tools.

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 documents the single `section` parameter at 100% coverage with a thorough enum description, so the baseline is 3. The description never mentions sectioning at all and in fact frames the tool as returning "the complete design context as one markdown document," which nudges an agent away from the cheaper partial fetch.

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?

States a specific resource (the complete DESIGN.md) and enumerates its contents — install steps, rules, tokens, component inventory with props, starters — so an agent knows exactly what it gets back. It is implicitly the aggregate counterpart to list_components/get_tokens/get_instructions, though it never names those to draw the distinction explicitly.

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?

"Pull this once at the start of a build" gives a clear trigger and implies idempotence, which is useful. But it offers no exclusions and no routing against siblings (get_instructions, get_tokens, list_components, get_component) — an agent cannot tell from this description why it would ever pick the narrow tools instead, or vice versa.

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 disclosure burden. It does communicate that this is a short, curated text payload meant to be pasted into an agent config file, which tells the agent what it will get back and how to use it. It stops short of stating the exact return format (markdown vs plain text) or length, but for a zero-parameter read this is largely covered.

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 filler, with the core purpose and the ordering instruction front-loaded before the alternative. Every clause (content areas, CLAUDE.md destination, sibling pointer) carries 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-param, read-only retrieval tool with no output schema, the description covers what the content is and when to call it. The only gap is not characterizing the response format or size, which would help an agent decide whether to load it into context.

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

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

The tool takes no parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies no arguments are needed by framing the call as a simple 'read this first'.

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?

States a specific resource (short, always-on WunderUI rules) and enumerates its content scope (components, tokens, motion, copy), plus names the intended destination file (CLAUDE.md / AGENTS.md). This makes it instantly distinguishable from get_design_md, which it explicitly identifies as the fuller version.

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 'Read this first' and names the alternative and the condition that selects it ('use get_design_md for the full context'). Ordering guidance plus the sibling routing is exactly what an agent needs.

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 and no output schema, the description carries the full burden, and it does disclose the shape of the response (fields and counts) — the single most useful behavioral fact here. It does not say the tool is side-effect free, takes no arguments, or is cheap to call, but for a zero-param getter the risk surface is small.

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

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

A single sentence with no filler, and the most important facts (name, version, install commands) lead. It is a noun-phrase inventory rather than an action statement, which slightly weakens the front-loading of purpose.

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

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

Because no output schema exists, the description must stand in for return-value documentation, and it does so at a high level (which fields come back, including counts). It stops short of describing the format of install commands or framing this as the recommended first call, leaving gaps an agent may care about.

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 zero properties, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the call needs no input.

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 enumerates exactly what the tool surfaces: package name/version, install commands, underlying stack, and counts of components, categories and templates. Combined with the name get_library_info, an agent can tell this is a library-metadata read, and the field list separates it from list_components or get_component. It never states an explicit verb or names a sibling, so differentiation is inferential rather than stated.

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?

There is no statement of when to call this versus list_components, list_templates, get_instructions or get_starter. An agent must guess that this is the 'orientation/overview' tool rather than a counting tool for a specific resource type. No prerequisites or exclusions are given.

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

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

With no annotations, the description carries the safety/auth burden and does so partially: it discloses that Pro skills require a valid Pro key via WUNDERUI_LICENSE_KEY and that referenced scripts are not included. It does not say what happens on an unknown skill name or an invalid/missing key.

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 short sentences, front-loaded with the return value before the auth caveat and the scripts note. Slightly dense with parentheticals but every sentence contributes distinct 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 one-parameter read tool with no output schema, the description covers what is returned, the auth gate, and a key limitation. Only failure/error behavior for bad names or missing keys is left unstated.

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

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

Schema coverage is 100% and the single required `name` parameter already carries examples (wunderui-theme, wunderui-screen). The description adds no further naming syntax or constraints, so 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?

"Returns one skill's instructions (its SKILL.md)" gives a specific verb, resource, and source (wunderui.com), which is clear enough to pick apart from list_skills. It does not name the sibling explicitly, so an agent must infer that list_skills enumerates and get_skill fetches a single 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?

The phrase "so the agent can follow the workflow without installing the skill" states the situation that selects this tool over installing the skill. No explicit exclusions or alternative tool names are given, so it stops short of full when/when-not 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 present, the description carries the full load; it does disclose that the output is TSX already wired with the correct props, which is real behavioral context. However it says nothing about whether the snippet is read-only, how large it is, whether it spans multiple files, or any dependency on theming/tokens setup.

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?

One front-loaded sentence that states the deliverable first and then the supported variants; no filler or redundant restatement of the tool name.

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 no-annotation, no-output-schema tool whose entire value is the returned artifact, the description should say more about the shape of the return (single file? multiple files? does it reference tokens or imports?). It conveys what is returned conceptually but leaves an agent guessing about output structure.

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

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

Schema coverage is 0% for the single 'kind' parameter, and the description compensates by mapping each enum value to a natural-language composition (app shell, dashboard row, data grid, AI chat, theming pattern). The mapping is loose at points—'dashboard row' vs the enum 'dashboard' and 'data grid' vs 'table'—so it is helpful but not airtight.

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?

Uses a concrete verb+resource ('Copy-paste TSX for a common composition') and enumerates the five composition kinds it serves, so an agent can tell it produces ready-to-use code rather than a component listing. It stops short of explicitly contrasting itself with get_component or get_block_source, which occupy adjacent ground.

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 enumerated compositions imply when the tool applies, but there is no explicit when-to-use/when-not statement and no routing to obvious alternatives like get_component (single component) or get_block_source (block source). The agent must infer the boundary from sibling 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?

With no annotations, the description carries the full burden. It conveys that the tool is a pure read of theme constants and that the override model is how theming works, but says nothing about the shape of the returned token set, whether values are stable across versions, or how theme/format interact in output.

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 tightly packed sentences with the resource stated first and the usage directive second — no filler. The opening sentence is a fragment rather than a full clause, which slightly weakens front-loading of the action.

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

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

For a zero-required-parameter read tool with no output schema, the description covers purpose and usage but leaves the agent guessing at return structure (e.g. what a JSON token object looks like versus a CSS block) and at whether overriding tokens is done here or elsewhere. Adequate but with clear 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 description coverage is 50% — the 'format' enum is self-documented while 'theme' has no description in the schema. The description hints at both dimensions ('light and dark', 'in the format you need') but adds no detail on defaults or what 'both' yields, so it does not fully compensate for the coverage gap. 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 names the resource (design tokens) and its scope (light and dark themes, multiple output formats), which clearly separates it from sibling tools that deal with components, templates, and skills. It lacks an explicit verb and never names a sibling, but for a simple resource-fetch tool the resource identification is 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?

'Use these instead of hardcoding colours' gives a concrete directive for when to reach for this tool, and 'overriding them is how WunderUI is themed' explains the downstream workflow. No alternative sibling is mentioned, so it falls short of the explicit when/when-not standard.

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 full behavioral burden; it does disclose the returned field set and the plan-based licensing constraint, which is meaningful context. However, it says nothing about result volume, pagination, or whether the list is exhaustive — relevant for an unfiltered inventory call with zero required parameters.

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 short sentences, front-loaded with what the inventory is before the filters and the usage directive. Slight overlap with the schema's parameter descriptions, but nothing is padded or wasteful.

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 annotations and no output schema, the description does the needed work: it defines the result shape, the filterable dimensions, the recommended call ordering, and the license constraint. Only missing piece is any sense of result size or pagination for the unfiltered case.

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% and the enum for plan is documented in the schema, so the baseline is 3. The description restates the three filter axes (category, plan, query) and adds the free-plan filtering rule, but contributes no additional syntax or matching behavior 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 names the resource (the WunderUI component inventory) and enumerates the fields returned (name, category, plan, one-line description), so the agent knows exactly what a call produces. It does not explicitly distinguish itself from the sibling get_component (singular) or list_templates, leaving that differentiation implicit in the verb 'inventory/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?

It gives a concrete trigger: 'Call this first to find out whether a component already exists before building one by hand', which establishes ordering relative to hand-building. It also adds a conditional rule ('On the Free plan use only components with plan "free"'). It stops short of naming get_component as the follow-up alternative.

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

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

No annotations are supplied, but the description discloses the most important behavioral trait for this catalog: some skills are gated behind WUNDERUI_LICENSE_KEY while others are free. That access-condition context is exactly what annotations would otherwise have to carry; only the return shape is left unstated, which is minor for a zero-parameter list.

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?

One front-loaded sentence with no filler, though the long parenthetical catalog of skill types makes it denser than ideal. Every clause contributes content, but the list-within-parentheses could be trimmed.

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, no-output-schema catalog tool, the description covers what the tool surfaces and the licensing constraint an agent needs before proceeding. Only the shape of the returned entries is unspecified, which is a modest gap.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The sentence stays focused on what is listed rather than inventing parameter guidance.

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 names the resource (WunderUI agent skills) and enumerates the concrete capabilities covered — project setup, screen building, theming, migration, audits, Figma. It is not a tautology of the name, though it relies on the title for the 'list' verb and only implicitly contrasts with get_skill.

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 free-vs-Pro licensing note tells the agent when a skill will actually be usable, which is real usage guidance. However, it never states when to call this versus get_skill or get_instructions, so the browse-then-fetch workflow must be inferred from sibling 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 are supplied, so the description carries the full behavioral burden. It does disclose the content of what is returned (full-page templates built purely from WunderUI components), but never states that this is a read-only, side-effect-free listing, whether the four named items are exhaustive or illustrative, or what shape the results take (names vs. source).

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 short sentences with no filler; the content description leads and the actionable advice follows. Every clause carries information.

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

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

For a simple zero-parameter list tool, the description covers what the items are but not the return shape or the follow-up step for actually retrieving a chosen template (presumably get_starter or get_block_source). With no output schema and no annotations, that retrieval path should have been stated.

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 takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 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 names the resource precisely: "Full pages assembled only from WunderUI components," and gives four concrete examples (dashboard, settings page, AI inbox, sign-in screen). It doesn't explicitly state the verb "list" or differentiate itself from siblings like list_components or get_starter, so an agent must infer enumeration from the tool name.

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?

"Start from one of these instead of an empty file" implies the when-to-use case (scaffolding a new page). However, it names no exclusions or alternatives, and never tells the agent how this relates to list_components or get_starter, so the agent must guess which list tool to call.

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