aura-components-mcp

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

With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: rebuild/refresh performs a 'bounded polite crawl' and the tool 'Never auto-crawls on startup'. But it does not say what status/lock means, whether rebuild destroys or replaces the corpus, whether resume requires a prior rebuild, or what permissions/environment are needed.

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?

It is compact and the enumerated action grouping is front-loaded, but the parenthetical shorthand ('counts/freshness/lock', 'studio/tag/url watches') is dense and cryptic, and the action-to-parameter mapping would benefit from a slightly more structured format.

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 5-parameter, 8-action tool with no annotations and no output schema, the description is too thin. It omits the relationship between actions and parameters, does not explain return shapes for status/new_winners, and does not warn about side effects of rebuild/resume/refresh on the local corpus.

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 should compensate. It mentions 'status (counts/freshness/lock)' and 'watch_add/list/remove (studio/tag/url watches)' which loosely map to the action enum and the kind enum, but it never explains award (sotd/developer/honorable), pattern, or maxPages, and does not clarify which params apply to which action.

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 a specific resource (local award corpus) and enumerates the operations it supports (status, rebuild/resume/refresh, new_winners, watch_*), which lets an agent infer the tool's domain well. Sibling differentiation against aura_award_search and aura_award_inspect is only implicit (the 'local corpus' framing hints at local state vs search), so it falls short of a clean 5.

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 through the action enumeration (e.g., 'baseline then delta' for new_winners, 'bounded polite crawl' for rebuild), but there is no explicit when-to-use/when-not guidance, no mention of when to prefer aura_award_search or aura_award_inspect, and no sequencing advice for the baseline-then-delta flow.

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. 'Inspect' implies a read-only lookup and it discloses mode-level behavior plus the notable rule that missing refs are 'marked unknown' in compare_sites, but it says nothing about permissions, rate limits, or what a failed lookup returns.

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 with nested parentheses that is front-loaded with the verb and mode list, so nothing is wasted. But the parenthetical stacking makes the mode-to-argument mapping hard to scan; a short bulleted list would serve an agent better.

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 and no annotations, so the description must carry the full burden for a 4-parameter, 4-mode tool. It describes roughly what each mode returns, which is the minimum viable, but leaves the slug/slugs/elementSlug mapping to inference.

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

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

Schema coverage is 0%, so the description must compensate, and it only partially does: it ties the four modes to meanings but never says which parameter each consumes (slug for site_details, slugs for compare_sites, elementSlug for element). It does confirm the 2-3 slug constraint for compare_sites, which is genuinely useful.

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?

Starts with a specific verb+resource ('Inspect award refs') and enumerates the four modes as different views of award data, which separates it from aura_award_search/aura_award_index. It never explicitly names those siblings, so the distinction is inferred 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?

The mode list implies when each mode applies (site-level vs element-level vs multi-site comparison), which is useful context. However, there is no guidance on when to reach for this tool versus aura_award_search or aura_award_index, and no prerequisites or 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 usefully discloses the local-index-first / single live-refresh-on-empty caching behavior, but says nothing about permission needs, rate limits, latency, or what distinguishes a live call from a cached one.

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?

Purpose is front-loaded, the mode list is compact, and the caching note closes efficiently. The mode enumeration is a dense run-on, but little 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 15-parameter, 0%-coverage tool with no output schema and no annotations, the description leaves most filters and their interactions undocumented. Mode is covered, but an agent cannot reliably invoke the filter parameters.

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

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

Schema coverage is 0% across 15 parameters, yet the description only addresses mode (whose enum values the schema already lists). Filters like award, color, tags, studio, library, category, technology, scrollModel, easing, limit, and offset are left entirely unexplained, so the description does not compensate for the coverage gap.

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 verb and resource ("Search award-winning website references (Awwwards)") and enumerates four modes with what each returns, which is rare specificity. It does not name its closest siblings (aura_award_inspect, aura_award_index) to disambiguate, so it stops short of 5.

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 mode breakdown gives clear selection context — an agent can tell which mode yields ranked site refs vs taxonomy vs element examples vs motion studies — plus the "local index first, one polite live refresh when empty" operational note. There are no explicit exclusions pointing to aura_award_inspect or aura_award_index for non-search operations.

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 it does disclose two meaningful behavioral traits the schema cannot convey: the 2-8 item batch bound and the partial-failure model ('Per-item errors never fail the batch'). It still omits safety profile and whether ids are resolved per-item or atomically.

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 with the core purpose front-loaded, then the alias note, then the failure semantics. No filler and nothing redundant.

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 2-param, no-annotation, no-output-schema tool, the description covers batching and error behavior but leaves the id format and the shape of a successful result unaddressed. It is adequate but has a clear gap in the one place an agent is most likely to guess wrong.

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 usefully constrains the `ids` array to 2-8 entries and echoes the `kind` enum values. However, it never explains what form an id takes (slug, uuid, name), which is the single most important thing for invoking this tool correctly.

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 concrete verb and resource (bulk-fetch 2-8 details) and scopes it to components, design_systems, or assets. Critically, it explicitly identifies itself as the alias of sibling tool aura_bundle, so an agent can tell the two apart without opening either schema.

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?

Gives a clear usage context (batch retrieval of 2-8 details in one call) and clarifies the relationship to aura_bundle as an equivalent alias, which is real routing information among 30+ siblings. It stops short of stating when to prefer a batch call over the individual get_* 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?

With no annotations, the description carries the burden. It helpfully discloses that per-item errors never fail the batch, which is a real behavioral trait. But it omits read-only nature (implied but unstated), what the response shape looks like, and id-vs-slug resolution 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?

One compact sentence that front-loads the key operation and the batch constraint. 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?

No annotations and no output schema mean the description must do more. It covers the core operation and partial-failure behavior but leaves return shape, id/slug combination semantics, and required-vs-optional handling unspecified.

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% and both parameters are undocumented in the schema. The description only hints at ids/slugs and the 2-8 constraint; it doesn't explain array formats, whether both can be combined, or whether any parameter is required (schema says none).

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 verb (bulk-fetch) and resource (component details), with the batch size (2-8) and inputs (ids or slugs) made explicit. It distinguishes itself reasonably from siblings like aura_get_component and aura_bulk_fetch, though it doesn't explicitly name the single-item sibling it replaces.

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 — fetch 2-8 items in one call — but there is no explicit guidance on when to prefer this over aura_get_component or aura_bulk_fetch, nor when to use ids vs slugs.

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 discloses the return cardinality (13 categories) and that counts are 'live', which is useful behavioral context. However, it says nothing about caching, rate limits, or how 'free counts' are scoped (per category vs. total).

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 crisp sentences with zero waste. The result shape is front-loaded and the follow-up action is stated immediately.

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?

Adequate for a zero-param discovery tool, but with no output schema and no annotations, the description should say a bit more about what each category entry contains or what 'free counts' means. Minor gap, not a blocker.

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?

Zero parameters, so baseline is 4. The description correctly implies a no-arg invocation, consistent with the empty schema.

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

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

States a specific resource (the 13 component categories) and the data returned (live free counts). Differentiates reasonably from siblings like aura_search_components by framing it as the entry point for category browsing, though it doesn't name a sibling 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?

Gives a clear workflow: 'Pick one, then search within it,' which implies this is a top-level browse tool preceding aura_search_components. No explicit when-not-to-use, but the sequencing guidance is 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 full burden, and it does disclose real behavior: free-only enforcement, failures marked unavailable, and a no-copy policy for third-party source. However it says nothing about determinism, error surfacing beyond 'unavailable', or how the versioned JSON is versioned, leaving meaningful behavioral 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?

It is a single front-loaded, telegraphic sentence that avoids filler, which is good, but the densely compressed style ('from 2-5 award refs + goal', 'free-only enforced') forces the reader to decode rather than read cleanly. Efficient but at the cost of parseability.

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?

This is a complex 7-parameter tool with no annotations, no output schema, and no parameter descriptions. The description names the two output artifacts (Markdown brief, versioned JSON), which helps, but it is not sufficient to call the tool correctly given five undocumented optional parameters.

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

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

Schema coverage is 0% across 7 parameters, so the description must compensate, and it only partly does: it constrains references to 2-5 award refs and identifies goal. The other five parameters (responsive, technology, constraints, visualDirection, includeStructure) and the fact that references are strings are left entirely undefined.

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 a specific deliverable: an 'Evidence-backed build plan' that outputs a 'Markdown brief + versioned JSON' mapped to real free Aura components. This is concrete verb+resource phrasing that lets an agent understand the output shape. It doesn't explicitly contrast with close siblings like aura_docs_plan or aura_bundle, so it falls just short of 5.

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 use this tool versus alternatives such as aura_docs_plan, aura_scaffold_page, or aura_bundle, and no exclusions or prerequisites. The 'from 2-5 award refs + goal' phrasing hints at the input situation but is really a parameter constraint, not usage context.

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

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

With no annotations, the description carries the full burden and adds useful traits: possible verdicts (current|needs-update), that fixes are look-preserving, and that version-pins yield needs_check. But it is ambiguous whether 'fixes' are returned or applied, and says nothing about permissions, side effects, or whether the tool mutates anything.

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 and the arrow notation compresses a lot into little space. But the compression veers into cryptic shorthand ('pure', 'version-pin needs_check') that costs more clarity than the words saved.

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

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

Given no output schema and no annotations, the description does convey the verdict vocabulary and the look-preserving-fix behavior, which is the bare minimum an agent needs. It still omits invocation details and the exact nature of the returned fixes.

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%, so the description must compensate, and it partially does: it ties 'library + code_excerpt' to the required inputs, adds a size constraint (under 20000 chars) and an excerpt-not-full-page rule, and marks docs_note as optional. The docs_note parameter's meaning is left unexplained.

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 verb and resource: 'Check pasted code against fresh docs.' An agent can tell it validates code against documentation. However, it does not differentiate itself from the sibling aura_docs_plan, and the '(pure)' tag is unexplained jargon.

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 guidance on when to use this versus alternatives. The obvious sibling, aura_docs_plan, is never mentioned, and no preconditions or scenarios for choosing this tool are given. The agent must infer usage from the name alone.

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, but it does disclose a key behavioral trait: it is 'pure, no fetch,' so the agent knows no network retrieval occurs and the tool only produces a plan. It also names a trusted library set (tailwind, gsap, lenis, iconify), which is useful context. It stops short of describing idempotency, side effects on Aura files, or the return format.

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?

It is short and front-loads the purpose, which is good. The telegraphic style ('library + need -> Context7 resolve/query plan') and jargon like 'docs stamp slot' trade clarity for brevity, so it is not maximally effective conciseness.

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 planning tool with no output schema, no annotations, and two undocumented parameters, the description should do more to describe the structure of the plan it returns. It gestures at return components but leaves 'docs stamp slot' and the apply-step format ambiguous.

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%, so both parameters are undocumented in the schema. The description maps 'library + need' to the two params and gives example library values, adding real value for 'library'. It adds essentially nothing for 'need' semantics, so it does not fully compensate for the coverage gap.

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 ('Plan a fresh-docs lookup') and clarifies it is a planning-only operation ('pure, no fetch'). It describes the output shape (Context7 resolve/query plan + apply steps for Aura files + docs stamp slot), though the differentiation from the sibling aura_docs_check is left implicit 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?

It implies the workflow with 'The agent calls Context7, Aura shapes the rest,' giving a sense of division of labor. However, it never states when to use this vs aura_docs_check or when it should be avoided, leaving the agent to infer the routing condition.

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 disclose the return payload (source, preview image, URL) plus a genuinely useful behavioral rule: full:true overrides chunk. However it says nothing about failure modes when neither id nor slug is supplied, whether id/slug are mutually exclusive or preferential, or any auth/quota constraint.

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 the payoff (what you get back), then parameters. Telegraphic style wastes nothing, though the fragment 'Numeric id or slug' is terse to the point of being slightly clipped.

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 schema descriptions, no annotations, and no output schema, the description covers the essentials — return contents and all four parameters. It still leaves an agent guessing about identifier precedence and error behavior for a tool that is clearly the payload-heavy terminal step of a search-then-fetch flow.

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%, so the description must compensate, and it does: all four parameters get meaning (id numeric, slug string, chunk pages large code, full returns everything and ignores chunk). The gap is that it never states whether id and slug are alternatives, which one wins, or what units chunk uses.

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 retrieval resource and enumerates what comes back: HTML/Tailwind source, preview image, and page URL. It is clearly a 'fetch the full detail for one component' tool, distinct from aura_search_components by virtue of returning source. It does not, however, explicitly name a sibling it supersedes or is superseded by.

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 this is the detail-fetch following a search, and the chunk/full notes hint at when to page vs. pull everything. There is no explicit 'use this instead of X when Y' and no statement of prerequisites such as needing a valid id or slug obtained elsewhere.

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 at all, the description carries the full disclosure burden. It does add genuine behavioral value by describing the return payload ('Full free DESIGN.md content plus preview_html, tokens, and page URL') and by noting that chunk pages large preview_html, but says nothing about auth, rate limits, or what happens when neither id nor slug is supplied.

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 tight fragments, front-loaded with the returned payload, with zero filler. It is slightly too telegraphic and the dangling '(see preview_info)' reference costs a point.

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 3-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is thin: it never says what happens if id and slug are both omitted, gives no value format for chunk, and cites a preview_info token not present in the provided schema.

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% across 3 parameters, so the description must compensate. It clarifies that id and slug are interchangeable identifiers and that chunk controls paging of preview_html, which is real added meaning, but it leaves the chunk value format/limits undefined and points at an undefined 'preview_info' reference.

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 verb+resource (get design system) and enumerates the payload it returns (DESIGN.md content, preview_html, tokens, page URL), which separates it from the search-oriented siblings like aura_search_design_systems. It never names a sibling explicitly, so the 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 when-to-use guidance and no mention of alternatives such as aura_use_design_system or aura_search_design_systems; the agent must infer that this is the retrieval step. 'System id or slug' tells you how to address the target but not under what circumstances to choose this tool.

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

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

No annotations, so the description carries the full burden, but it does disclose the return shape (SKILL.md body, source_url, page URL) and that large bodies are paginated via chunk. It omits auth/cost assumptions beyond the word 'free' and gives no rate-limit or error context.

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?

Front-loads the return contents, which is good, but it is written as three telegraphic fragments rather than sentences, and the dangling '(see content_info)' reference adds confusion rather than 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?

With no output schema, no annotations, and 0% parameter coverage, the description is the sole source of information, and it leaves chunk semantics, expected id format, and the referenced content_info unexplained. Inadequate for an agent to invoke 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?

Schema coverage is 0% for 2 params. The description only labels 'id' as 'Skill id' and vaguely calls chunk a paging mechanism while deferring to a 'content_info' field that is not present anywhere in the schema, so it fails to compensate for the coverage gap.

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 verb+resource: fetching full agent-skill content (SKILL.md body) with source_url and page URL. An agent can distinguish it from aura_search_skills and aura_install_skill, though the verb 'get' is only implied by the name rather than the prose.

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 when-to-use guidance and no named alternative. It never says to call this after aura_search_skills to retrieve a full body, nor when to prefer this over installing the skill, leaving routing entirely to inference.

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, and it does disclose meaningful traits: auto-fallback across styles then libraries, mandatory CC BY 4.0 credit on every hit, a bundled font/CSS alternative, and a 24h cache. Error behavior and rate limits are not covered, but the return-content and caching context 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 definition is dense and front-loaded, leading with the verb and the concrete deliverable (ready-to-paste SVG) before drilling into parameters and behavior. Nearly every clause carries information, though the enum re-listing is marginally redundant given the schema.

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

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

There is no output schema or annotation coverage, so the description must stand alone, and it does describe the returned artifact (SVG plus license/credit and a font/CSS alternative) and caching. For a 3-parameter fetch tool this is nearly complete, with only failure/timeout behavior left unaddressed.

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 add the meaning. It contributes the kebab-case format with concrete examples (bolt, arrow-down) and explains that "auto" resolves by falling back styles-then-libraries, which is genuinely new. It does not explain what each source/style option actually yields, and the bare enum listing largely restates 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 gives a specific verb and resource ("Fetch one free icon as ready-to-paste SVG") plus the output format, so the agent can tell this is a single-icon retrieval tool rather than a search. It does not name or contrast any sibling (e.g. aura_search_assets, aura_get_component), so differentiation is implicit 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?

Usage is only implied through parameter hints such as the auto-fallback behavior and the enumerated source/style values. There is no explicit when-to-use-this-vs-an-alternative guidance and no exclusions, so the agent must infer that this is the tool for grabbing one concrete icon rather than searching.

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 burden. It does disclose the return payload ('inspo.compare call + closest Aura system/component queries'), which is useful. But it says nothing about side effects, permissions, or what 'pure'/'no autopsy' operationally restrict.

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?

Compact and roughly front-loaded with the action, but the density of undefined terms ('pure', 'autopsy', 'slim') means the brevity costs clarity rather than earning it.

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 nested-param tool with no annotations, no output schema, and 0% schema coverage, the description supplies the field shape and return format, which is meaningful. It still omits side-effect/permission context and leaves core terminology undefined, so completeness is only partial.

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% and the single evidence param is a bare object array, so the description must compensate — and it does partially by enumerating fields {slug, palette?, fonts?, macrostructure?, mode?} with optional markers. However, the meaning of each field and the 'slim keys only' constraint remain unexplained, leaving semantics incomplete.

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 core action is discernible: comparing 2-4 Inspo sites to derive a 'house style.' However, key terms ('slim', 'pure', 'house style', 'no autopsy', 'triangulate') are internal jargon with no gloss, so an agent cannot be fully confident what the operation yields versus siblings like aura_inspo_system or aura_inspo_recommend.

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 a usage constraint (2-4 sites, slim keys only) but never states when to choose this tool over aura_inspo_system, aura_inspo_recommend, or aura_inspo_reference. No exclusions or alternative routing is 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 full burden; it partially meets it by tagging the operation '(pure)' (implying no side effects) and enumerating what comes back (inspo.find_components call + aura_search + scaffold_hint, tokens first, weight s|m). It says nothing about authentication, rate limits, or failure behavior, so it is helpful but incomplete.

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?

Front-loaded with the mapping action, then the filter vocabulary, then the return payload — three compact sentences with no filler. The abbreviation-heavy style ('weight s|m', '(pure)') costs a little clarity but the size is appropriate for a two-parameter 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 nested-object tool with no output schema, the description usefully names the three return artifacts and the evidence filter vocabulary. It leaves the 'brief' input, the internal structure of the evidence object, and the meaning of style/macrostructure/mode unspecified, so an agent cannot construct a valid call with confidence.

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% and the evidence object is nested, so the description must compensate. It does list the accepted evidence.type values (hero, pricing, features, cta, nav, footer, testimonial, logo-cloud, faq, stat) plus style/macrostructure/mode, which is real added meaning, but the 'brief' parameter is never mentioned and the shape/optionality of those sub-fields remains undefined.

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 does state a verb+resource pairing ('Map an Inspo component filter onto Aura search'), plus the enumerated evidence.type values and the returned artifacts, so the core operation is identifiable. However, qualifiers like '(pure)' and 'scaffold_hint' are unexplained jargon, and nothing distinguishes this tool from the four other aura_inspo_* siblings (system, compare, recommend, 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?

There is no when-to-use or when-not-to-use guidance, no stated prerequisite or ordering relative to aura_inspo_system / aura_inspo_compare / aura_search_components, and no mention of what to do when no filter matches. The agent must infer from the name that this is the discovery/mapping step.

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, and it does disclose meaningful behavior: the strict macro gate, the need_macro:true failure shape, the fact that it performs no fetch, and the returned payload (inspo_call + 3 aura_calls + palette priority). It does not cover permissions, error modes, or determinism, but for a pure mapping tool this is substantial 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?

Three tight sentences with no filler, and the gating constraint is front-loaded before the success-path return shape. The telegraphic style borders on cryptic but 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?

With no output schema and no annotations, the description supplies the return structure and gating behavior an agent needs to invoke this correctly, which is the main completeness risk here. Residual gaps are the unexplained mode/vibe inputs and the exact identity of the tool to call first.

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 explains macrostructure's gating role and implies brand_hex through the 'brand > Inspo > Aura' palette priority. However, 'mode' and 'vibe' are never mentioned, and brief's expected content is only implied, leaving roughly half the parameters opaque.

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 verb and output ('Map a brief onto Inspo + Aura calls') and clarifies scope with '(pure, no fetch)', which separates it from network/fetch siblings. It is dense with internal jargon (Inspo, Aura calls, macrostructure) that a newcomer may not resolve, but the core action 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?

Gives an explicit prerequisite and a when-not rule: without macrostructure it returns need_macro:true and the agent must 'run inspo.recommend first, never scaffold generic.' That is real routing guidance, though the named 'inspo.recommend' does not exactly match any sibling tool name, leaving slight ambiguity about which tool to chain.

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 disclose return content ('inspo.get_reference_jsx + aura_get_component calls plus scoped adapt_plan') and the '(pure)' marker hints at a non-mutating planning operation, but it never states side effects, permissions, or whether anything is written.

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?

Dense, front-loaded, telegraphic statements with no filler; purpose leads, then params, then return shape. It borders on cryptic but 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?

No output schema and no annotations, with two nested-object params, so the description has a heavy load. It covers the return surface and rough param structure adequately, but leaves the nested objects' inner shape and any safety/permission context unspecified.

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% and both params are bare nested objects, so the description must compensate. It does partially by specifying 'evidence {type, id}' and 'aura_component {id|slug}', which is genuinely more than the schema offers, though the meaning of 'type' and the id-vs-slug choice remains unexplained.

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 verb (Adapt) and resource (one Inspo reference JSX onto one Aura component), with the parenthetical '(pure)' scoping it. However, it does not differentiate itself from adjacent Inspo siblings like aura_inspo_compare or aura_inspo_system, so an agent must infer the boundary.

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 when-to-use guidance, prerequisites, or named alternatives. 'Adapt one reference onto one component' implies a single-pair scope, but nothing tells the agent when this is preferable to aura_inspo_compare or the other inspo 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?

With no annotations, the description carries the full burden, and it does disclose the output shape (A/B/C options, a system_choice question payload with enum values, and a contrast warning). It says nothing about side effects, permissions, or whether anything is persisted, so it is partial but adds real behavioral value.

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?

Compact and information-dense with the primary purpose front-loaded, but riddled with unexplained abbreviations ('pure', 'C (blend)', 'question payload') that cost more in clarity than they save in length.

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 nested-input tool with no annotations, no output schema, and 0% documented parameters, the description covers the input shape and returned options but omits the aura_system contract and any error/edge behavior. 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 coverage is 0% (aura_system is an empty schema, inspo_tokens is a bare object), so the description must compensate. It usefully enumerates inspo_tokens sub-fields (palette, fonts, background?, text?, brand_hex?), but leaves the required aura_system slug format entirely unexplained.

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 verb ('Resolve') and the two resources being reconciled (Inspo tokens vs Aura DESIGN system), and outlines the returned option set. It is distinguishable from unrelated siblings but never names the close ones (aura_inspo_compare, aura_inspo_recommend, aura_inspo_reference), which would fully disambiguate.

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 only usage hint is the trailing 'Tokens first', which gives an argument ordering but not a when-to-use condition. There is no guidance on when to choose this over the near-identical aura_inspo_compare or aura_inspo_recommend siblings, so selection is left to inference.

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 usefully discloses the license posture (all-rights-reserved per Aura Terms §4) and implies the tool returns a plan rather than mutating state, but says nothing about auth requirements, whether anything is actually installed, or rate limits.

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

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

A single dense sentence that front-loads the core concept and lists return contents without padding. The 'Legal drop-in plan' phrasing is slightly jargon-heavy but not 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?

For a 1-parameter, no-annotation, no-output-schema tool, the description does describe the returned fields, which compensates for the missing output schema. However, it leaves the input parameter and the tool's side effects completely unexplained, so it is only partially 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 single required 'id' parameter has 0% schema description coverage, and the description never mentions it or explains what identifier is expected (asset id, slug, numeric key?). The one parameter that matters for invocation is left entirely undocumented.

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+resource ('install asset') and enumerates what the tool produces (download URL, preview URL, license, suggested file path), so the agent knows it returns an install plan rather than performing a raw download. It does not, however, differentiate itself from the nearby aura_install_component and aura_install_skill 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?

There is no explicit when-to-use guidance and no named alternative. The only conditional cue is a legal aside ('check page before commercial use'), which is a caution about licensing, not routing between 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?

With no annotations, the description carries the burden and does disclose the return shape (dependency list, setup steps, file map, fonts), which matters since there is no output schema. However it never resolves the central ambiguity of a tool named 'install': whether it writes anything, requires auth, or is purely read-only text retrieval.

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 with the payload front-loaded and no filler. The second sentence's competitive framing ('goes beyond the official Aura MCP') is marginally salesy but does convey a capability differentiator.

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 two-parameter tool with no annotations and no output schema, the description usefully enumerates the returned artifacts, partially offsetting the missing output schema. It still leaves identifier semantics and any side effects or prerequisites unaddressed.

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% and neither parameter is typed or documented in the schema. The description only implies that the id/slug refer to a 'free component' and adds no guidance on which identifier to supply or whether both are needed.

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 (a component) and enumerates the concrete payload (dependency list, setup steps, file map, fonts), so an agent knows what comes back. It does not differentiate from the closest sibling aura_get_component, and the name 'install' collides with the description's implication that this only returns paste-ready text.

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 only usage signal is the qualifier 'for a free component', which hints at a scope limit but never states it as a rule or names an alternative. Nothing tells the agent when to call this instead of aura_get_component or aura_install_skill.

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 of behavioral disclosure. It hints that the output is a file-placement plan (where to put SKILL.md per client plus upstream source), but says nothing about side effects, whether files are actually written, auth requirements, or reversibility.

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?

It is a single front-loaded sentence with no filler, which is structurally efficient. However, the awkward 'Save-and-load plan' framing trades clarity for brevity rather than genuinely earning its compactness.

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, no output schema, and an undocumented required parameter, the description is too thin to let an agent call the tool correctly. It should at minimum clarify the action performed, the meaning of 'id', and what the returned plan contains.

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 single required parameter 'id' has 0% schema description coverage and the description adds nothing about it. Worse, the description implies per-client variation, yet no client parameter exists, so the meaning of 'id' (skill id? client id?) is left ambiguous.

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 name says 'install_skill' but the description calls it a 'Save-and-load plan', leaving it unclear whether the tool performs the install or merely returns placement instructions. It does add resource detail (SKILL.md, per-client placement, upstream source) beyond the name, but the core action is vague and it never distinguishes itself from the sibling aura_install_component.

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 when-to-use guidance, no prerequisite, and no mention of alternatives such as aura_get_skill or aura_install_component. The agent is left to infer the entire usage context.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: record is bounded, produces .webm only when ffmpeg is present, and the tool 'never claims unobserved library state' (an honesty/no-hallucination constraint). It still omits permissions, where recorded artifacts are written, and whether inspect touches the live page.

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, front-loaded sentences with zero filler; the mode breakdown is the second sentence, right where an agent needs it. The dense parenthetical shorthand ('libs/easing/scroll') is efficient but mildly cryptic.

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 9-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description explains only the mode dimension. Most inputs and the entire return shape are undocumented, which is not enough for reliable 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 0% across 9 parameters, so the description must compensate. It hints at library/easing/scroll filtering and shows record studies frames, but url, frames, viewport, allowLocal, durationMs, and scrollModel remain entirely unexplained in either place.

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?

Names a specific resource (motion studies) and enumerates three modes with concrete scope for each: live runtime scan, bounded frame recording, and stored-study search. No sibling tool touches motion, so differentiation is implicit rather than stated, and the headline 'evidence-backed motion guidance' is somewhat abstract, keeping it below 5.

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 mode list functions as routing guidance: inspect for live runtime, record for capturing frames, search for stored studies. It clearly tells the agent which mode fits which intent, but offers no when-not conditions and does not compare against any sibling tool.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the two-pass structure, that Pass 1 emits a draft plus six questions, that the user must be asked via the native question UI, that Pass 2 emits final_prompt + plan order + suggested calls, and the confirm-before-scaffolding guardrail. Auth, rate limits, and error behavior remain unstated.

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?

Front-loads the core concept ('Need-based design prompt in 2 passes') and stays compact despite covering a two-pass workflow. The nested parenthetical is dense but every clause carries information, so little 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 complex, multi-pass tool with no output schema and no annotations, the description explains the workflow and both return payloads, which is the critical missing structured data. The gaps are the undocumented 'surfaces' parameter and the absence of any sibling-selection guidance.

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 explains goal (Pass 1 alone vs Pass 2 with answers), answers (Pass 2 only), and notes mode folds into theme, which is genuinely useful. But 'surfaces' and the enum values/format of 'system' are never addressed, leaving part of the surface undocumented.

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 verb and resource — a need-based design prompt generated in two passes — and describes both pass outputs. It distinguishes itself from the search/inspect siblings by routing the agent toward inspo.recommend, but does not contrast against planning siblings like aura_docs_plan or aura_design_blueprint.

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?

Gives clear in-tool workflow: call with goal only for Pass 1, then with goal + answers for Pass 2, and 'always confirm with user before scaffolding.' However, it never says when to choose this tool over the many planning/blueprint siblings, which is the harder selection decision.

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 it does disclose genuinely non-obvious behavior: the top-3-per-surface cap, commercial-use licensing note, slim row output, and the auto-retry-once-via-suggested_queries-then-editorial-picks fallback chain. It omits only minor traits like read-only confirmation and latency, which are low-stakes for a recommendation read.

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 tight sentences with no filler, front-loading the purpose before output details and fallback logic. Density occasionally tips into crypticism ('hits per surface'), but every clause 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 tool with five parameters (two enum-constrained), zero schema descriptions, no annotations, and no output schema, the description is insufficient: the parameter vocabulary is almost entirely undefined and the fallback/result semantics are only sketched. An agent could not confidently set theme, negative_theme, or min_views from this text.

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, but it only incidentally gestures at 'slim' (slim rows) and 'goal'. It says nothing about theme, negative_theme, or min_views, leaving three of five parameters with a name and type but no meaning.

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 communicates a specific purpose: it recommends a starter kit of top 3 free assets per surface for a goal, with page URLs and rationale, plus a fallback chain. However, it uses jargon ('surface', 'hits', 'starter kit') and never states a verb or distinguishes itself from near-siblings like aura_inspo_recommend or aura_related.

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 explicit when-to-use guidance, no prerequisites, and no exclusions. 'Starter kit for a goal' faintly implies an early-stage discovery context, but with 35 sibling tools the agent gets no help choosing this over aura_inspo_recommend or aura_search_all.

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 disclose two useful traits: the result count (exactly 3) and the ranking basis (tag + text overlap). It says nothing about permissions, error/empty behavior, or how results are ordered when overlap ties.

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 with the core concept ('More-like-this') and the return size stated immediately. 'Discovery never dead-ends' is mild marketing padding, but the overall entry is tight and earns nearly all of its space.

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 two-param read tool with no output schema, the description tells the agent what comes back (3 related items) and how they are chosen, which is the minimum an agent needs. It omits what to do with the returned ids, which would be expected of a discovery tool feeding other tools, and leaves the id parameter entirely unexplained.

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%, so the description must compensate. It conceptually maps 'kind' to the three catalog types, but that merely restates the schema's own enum values, and 'id' is never explained (format, whether it is a slug, or what it identifies). The compensation falls well short of what two undocumented params need.

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 capability ('more-like-this') with a bounded output ('3 related items') and names the exact resource domain (component/skill/design-system) plus the matching mechanism (tag + text overlap). It is clearly distinguishable from siblings like aura_search_components or aura_recommend, though it never names the alternatives it is distinct from.

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?

'Discovery never dead-ends' strongly implies the use case of finding related items when a direct search or lookup comes up short, but this is inference rather than explicit guidance. It does not say when to prefer this over aura_recommend, aura_search_all, or the individual search 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?

With no annotations, the description carries the full burden. It does disclose output content (dependency-ordered markup, combined deps, full bodies when full:true), which is genuinely useful. However, it never states whether the tool is read-only or has side effects, nor its permission/auth requirements — a notable gap for an operation named 'scaffold' that references 'install'.

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 lead clause front-loads the purpose, but the rest is a dense semicolon-chained run-on that mixes parameter docs, output shape, and sibling relationships in one breath. It is compact but harder to parse than necessary; every fragment carries information, yet structure is sacrificed.

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 4-parameter tool with no annotations and no output schema, the description leaves key agent questions unanswered: what 'goal' means, what 'system' selects, and crucially whether the tool mutates anything or requires authorization. Partial output and parameter coverage is not enough at 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 description coverage is 0%, so the description must compensate. It does well for components, specifying accepted ref types (string|number|{id}|{slug}) with concrete examples, and documents full:true. But the required 'goal' parameter and 'system' are entirely unexplained, leaving half the parameters undocumented.

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 phrase 'One ordered page build' names a specific action and explicitly enumerates its deliverables (DESIGN.md, tokens.css, system preview, component markup in dependency order). It also distinguishes itself from siblings by stating it 'merges install_* + use_* in a single turn.' The jargon density ('combined deps + files[]') slightly obscures the plain purpose, but the verb+resource are identifiable.

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 implication that this replaces separate install_*/use_* calls is a useful routing signal toward aura_install_component and aura_use_design_system, but it is stated as a capability rather than a directive ('use this instead of X when Y'). No explicit when-not guidance or preconditions 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 full behavioral burden and does well: it discloses the 'Free only' filter, the default slim/excerpt response shape with no blobs, and the per-surface fallback semantics with the instruction to read isFallback/no_match per surface rather than globally. That last point is unusually valuable operational context. It stops short of describing auth needs, rate limits, or result ordering.

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 dense, front-loaded sentences with no filler: purpose first, then scope constraint, then response-shape nuance, then the fallback caveat. The em-dash clause is information-dense, though the jargon ('honestly empty') is slightly informal for a spec.

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 and no annotations, so the description must cover both behavior and parameters. It handles the return-behavior nuances well (fallback, slim rows) but leaves all six non-slim parameters undefined and offers no explicit sibling routing. Adequate but with clear gaps given the tool's complexity.

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

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

Schema description coverage is 0% across 7 parameters, and the description explains almost none of them. It gestures at 'slim rows by default,' which partially maps to the slim flag, but limit, query, theme, negative_theme, min_views, and exact_match are left entirely undocumented in both schema and description. This is a significant gap for a 7-param tool.

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 action (one parallel search call) over four named resource types (components, skills, assets, design systems). It clearly distinguishes itself from the four sibling per-surface search tools by being the fan-out aggregate. An agent can tell what this does and when it would supersede the singleton searches.

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 'One call across... in parallel' implies the fan-out use case, and 'Free only' establishes a scope constraint, which is real guidance. However, it never explicitly says when to prefer this over aura_search_components/skills/assets/design_systems, or whether the narrower tools are cheaper/more precise. Usage is implied rather than routed.

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, but it does disclose two real behaviors: output is slimmed by default, and exact_match:true disables fallback broadening. It omits auth/licensing constraints, pagination behavior, and what happens when no match is found.

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?

Very short and front-loaded, with the purpose in the first fragment and behavioral caveats last. The telegraphic sentence fragments make it slightly harder to parse but nothing 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 an 8-parameter tool with no annotations and no output schema, the description is too thin: half the parameters (sort, limit, offset, commercial_ok) are undocumented anywhere, and there is no statement of the result shape an agent should 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 0% across 8 parameters, so the description must compensate and largely does not: sort, limit, offset, and commercial_ok get no explanation at all. It adds genuine meaning only for exact_match ('skips fallbacks') and slim ('default').

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 verb ('Search') and resource ('free Aura assets (images and video)'), and narrows the media types, so it is distinguishable from the many aura_search_* siblings. It stops short of naming a specific alternative (e.g. aura_search_all), so it earns a 4 rather than a 5.

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 when-to-use guidance is given; 'Keywords, media_type image or video' merely restates parameter shapes. There is no indication when this tool is preferable to aura_search_all or the component/skill/design-system search siblings, and no 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 behavioral burden and does well on the parts it covers: default slim rows return an excerpt plus a fetch pointer rather than full code, and exact_match truly skips fallbacks to yield an honest empty. It stops short of disclosing pagination behavior or any scoping/permission context, which keeps it out of the top band.

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 definition is a single dense paragraph with no filler, and the most important fact (what is searched and the default slim return) is front-loaded. The telegraphic clause-per-comma style is efficient, though the param-mode notes could be slightly better ordered.

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 10-parameter tool with no output schema and no annotations, the description covers what is searched, the filter surface, and the shape of the default result set. The missing pagination semantics for limit/offset are the main omission.

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 and largely does, explaining query text scope, category tag, theme filter, negative_theme exclusion, min_views floor, sort, slim, and exact_match. Only limit and offset are left undocumented, a small gap against 10 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 states a specific verb and resource ('Search free Aura UI components') and even quantifies the corpus (2,495), so the intent is unambiguous. It does not, however, distinguish itself from close siblings such as aura_search_all or aura_inspo_components, which an agent could easily confuse it with.

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 by the behavior notes ('slim:false for full', 'exact_match:true skips fallbacks'), which hint at when to use specific modes. There is no explicit when-to-use guidance versus alternative search tools, nor any stated prerequisites, so selection still requires inference.

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 at all, the description carries the full burden, and it does disclose real behavior: results are metadata + snippets, slim is the default, and exact_match:true suppresses fallbacks. That fallback disclosure is genuinely useful. However, it says nothing about pagination, default limit, auth, or rate limits for a 6-parameter search endpoint.

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 dense clauses, front-loaded with the verb+resource, then return shape, then the alternative, then the one non-obvious flag. No filler. The 'slim by default' fragment is slightly telegraphic but still parseable.

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

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

There is no output schema and no annotations, so the description must cover return semantics and safety. It does describe the return shape (metadata + snippets, slim default) and cross-references the content-retrieval sibling. It leaves pagination, default sort, and default limit unspecified, which matters for a 6-param search endpoint with zero schema documentation.

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, and it only explains two of six parameters (slim's default, exact_match's fallback-skipping). The remaining query, sort, limit, and offset are left to their names and the schema enum. Partial compensation, so a 3 rather than a 2.

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 verb and resource ('Search free Aura DESIGN.md systems'), with a concrete corpus size (725) and an explicit boundary against the sibling that retrieves content. It does not, however, distinguish itself from the other search_* siblings (aura_search_components, aura_search_skills, aura_search_assets, aura_search_all), so an agent must infer the difference from the resource name alone.

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?

Gives clear routing guidance: 'use aura_get_design_system for content,' which tells the agent this tool is a discovery step whose output is metadata and snippets. It also states the condition for exact_match. No explicit when-not (e.g., when to prefer aura_search_all) is offered.

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 disclose real behavior: results are metadata-only, slim is the default, and exact_match:true bypasses a fallback/lookup widening step. That fallback hint is genuinely useful. However, nothing is said about auth requirements, rate limits, pagination behavior, or what 'metadata' actually contains.

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 clauses, purpose front-loaded, zero filler. The compression is slightly self-defeating in the last clause ('skips fallbacks' is cryptic without knowing what fallbacks are), which keeps it from a 5, but the overall density and ordering are strong.

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 6-parameter search tool with no annotations and no output schema, the description covers the decision-critical facts (it is metadata-only; go elsewhere for full content) but leaves paging, sort semantics, and result shape unaddressed. Adequate to invoke correctly in the common case, incomplete for the edges.

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% across 6 parameters, so the description must compensate and largely does not. It clarifies only two of them (slim's default, exact_match's fallback-skipping); query, sort, limit, and offset are left entirely to inference, including how sort interacts with query and how paging works.

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 verb+resource ('Search free Aura agent skills'), quantifies the corpus (192), and constrains the return surface ('Metadata only, slim by default'). It also explicitly separates itself from the sibling that returns full content (aura_get_skill), so an agent can route without opening either schema.

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 names the alternative for the adjacent need ('use aura_get_skill for the full SKILL.md content') and states the condition that selects this tool (metadata is enough). No guidance is given for when to prefer this over other search siblings like aura_search_all or aura_search_components, so it stops short of full when/when-not coverage.

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?

There are no annotations, so the description carries the full burden, and it does disclose two useful operational traits: the counts are 'Free only' and it requires 'no login,' which is genuine auth/scope context. It stops short of describing return structure or rate limits, but for a zero-argument read tool the disclosure is solidly above baseline.

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 tight fragments with no filler, and the substantive content (what it returns) is front-loaded before the 'Start here' call to action. It is efficient, though the telegraphic phrasing is slightly less polished than a fully-formed sentence.

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 status tool with no output schema, the description conveys what the agent will get back (health plus free counts across four categories) and the no-login/free constraints. Nothing essential for invoking it correctly is missing, though it could say more about the shape of the health/free data.

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 per the rubric the baseline is 4. The description's enumeration of what counts are returned adds confirmation but there are no parameters whose semantics need explaining.

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 function ('catalogue health plus free counts') and enumerates the resource categories covered (components, skills, assets, design systems), which clearly separates it from the search/get/install siblings. It stops just short of a 5 because it doesn't explicitly contrast itself with those siblings by 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 here' is an explicit directive telling the agent this is the entry point, which is meaningful ordering guidance among 15 siblings. It does not, however, name any alternative or state when NOT to use it, so it falls short of full when/when-not coverage.

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 implies some deliverable ('token starter CSS plus copy order'), but does not say whether the tool is read-only or mutating, whether it writes files, whether it requires an id/slug, or what the response contains. For a tool whose name suggests an action ('use'), this is a meaningful 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?

A single compact sentence with the resource front-loaded after the verb. No filler, though the parenthetical 'tokens first, then markup' is cryptic rather than clarifying, slightly reducing its 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?

No output schema and no annotations, so the description should explain the return shape and the id/slug semantics; it does neither beyond a vague mention of 'token starter CSS'. An agent lacks enough to invoke this correctly with confidence.

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?

Two parameters (id, slug) exist with 0% schema description coverage, and the description mentions neither. It does not clarify how id and slug differ, whether either is required in practice (both optional per schema), or what happens if both are omitted — so it fails to compensate for the coverage gap.

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 a verb ('Apply') and a resource ('DESIGN.md system'), which is a step above a tautology, but 'apply' is ambiguous — an agent cannot tell whether this fetches/returns a design system, writes token CSS into a project, or scaffolds files. It does not clearly distinguish itself from the sibling aura_get_design_system, which likely retrieves the same artifact.

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 use this tool versus aura_get_design_system, aura_search_design_systems, or aura_install_component. The only hint is 'copy order (tokens first, then markup)', which hints at an output sequencing convention but is not framed as a usage condition.

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: it discloses caching ('live, hourly cache'), a non-failing contract ('Never fails'), the degraded-path return shape ('offline registries return latest:null'), and the response fields (update_available, notice). That is unusually complete behavioral context for a zero-parameter 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?

Four tight sentences, front-loaded with what is compared and how fresh it is, followed by the remediation command and the failure contract. No filler; every sentence adds an actionable fact.

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-param diagnostic with no output schema and no annotations, the description supplies the return fields, edge-case behavior, freshness, and the recommended follow-up action. Nothing needed to call it correctly is missing.

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

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

The schema has zero properties, so there is nothing for the description to clarify beyond confirming the tool takes no input. 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 states the resource precisely: a comparison of the running version against the npm-published version, with a live hourly cache. It is distinguishable from siblings by noting that aura_status already carries the same verdict, though it never gives an explicit leading verb like 'check' or 'compare'.

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?

'aura_status already carries this verdict on every call' is a clear signal that this tool is usually redundant, which functions as a when-not-to-use rule pointing to a specific sibling. It stops short of an explicit directive such as 'call this only when you don't already have a status payload'.

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 disclose non-obvious behavior: a hard Chrome dependency, the failure mode ('honest BROWSER_UNAVAILABLE'), and a network-security constraint ('Loopback only with allowLocal:true'). It does not state whether captures persist to disk or that the operation is non-mutating, which leaves some 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?

Three telegraphic sentences, front-loaded with the purpose and then the mode table, with prerequisites last. Dense but every clause carries information; no filler.

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

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

For an 8-parameter, three-mode tool with no output schema and no annotations, the description should explain which URL parameters belong to which mode and what the caller receives back. It covers prerequisites and one flag, leaving the majority of the parameter surface and all output expectations undescribed.

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% across 8 parameters, so the description must compensate and largely does not. Only allowLocal is given semantics ('Loopback only with allowLocal:true'), and 'live-dom or static-html' hints at a mode/workflow choice without mapping clearly to url/buildUrl/referenceUrl, waitStrategy, viewport, or settleMs.

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 a specific verb set (capture/analyze) and decomposes the tool into three named modes with glosses: capture = real browser screenshot, structure = section band map (live-dom or static-html), compare = reference vs build mismatches. That is concrete enough to know what each invocation does, though it does not distinguish itself from the similar-sounding sibling aura_inspo_compare.

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?

Mode names imply when each is used, and the Chrome/loopback conditions give real invocation prerequisites. However there is no explicit routing against the sibling compare tools (aura_inspo_compare, aura_award_inspect), so selection still requires inference.

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