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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds genuinely useful behavior the annotations cannot convey: the default return set (import, summary, prop table) and the fact that extra sections are opt-in via `include`.

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

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

Two short sentences with no filler. The core return contract is front-loaded and the optional-extension hint follows it, so 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?

With no output schema, the description carries the burden of explaining returns and does so adequately by naming the three default sections and the optional ones. It is slightly thin on the shape of the response (e.g. how the import statement is formatted), but it is sufficient for correct 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 coverage is 100%, so both parameters are already documented, including the default `["props"]` and the example format for `name`. The description reinforces that `include` adds sections but adds no syntax or semantics beyond the schema, matching the baseline 3.

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

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

States a specific resource (one component) and enumerates the returned content (import statement, summary, prop table), which is more concrete than a bare 'get component'. It does not explicitly name siblings like get_props or get_examples, so the agent must infer that this is the aggregate entry point rather than a single-section tool.

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 second sentence tells how to widen the result via `include`, which implicitly signals this tool can subsume get_props/get_examples/get_css_variables. However, it never states when to prefer the narrower sibling tools or when to use this one over list_components, so usage is implied rather than directed.

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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety is covered. The description adds value beyond that by disclosing the return content (custom properties plus Sass names and defaults), which matters since no output schema exists. It does not mention result volume or ordering, hence not a 5.

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

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

Three short sentences, front-loaded with what is returned, then usage guidance and the parameter behavior note. Every sentence carries information; the 'reach for these before writing custom CSS' clause is mildly promotional but functions as guidance.

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

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

For a two-parameter read-only tool with no output schema, the description covers the returned data shape, the search scope, and the omit-to-search-all behavior. What remains unstated (query matching semantics beyond substring, result ordering) is minor.

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 50%: `query` is documented in the schema with an example, but `component` has no schema description. The description compensates for `component` by explaining that omitting it searches all components, but adds nothing about how `query` matches or how the two interact. Baseline 3 for partial coverage.

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

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

States a specific resource ('the --bulma-* custom properties a component reads, with their Sass names and defaults'), which is concrete and distinguishable from get_props and lookup_bulma_classes. It stops short of explicitly contrasting itself with those siblings, but the resource 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?

'This is how you restyle bestax — reach for these before writing custom CSS' gives a clear when-to-use context, and 'Omit `component` to search across all of them' explains the broad-search case. No alternative sibling is named for when NOT to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: examples are executed on the docs site and compile against the current version, which tells the agent the return quality and validity.

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 compact sentences with no filler. The most useful information—that examples are executed and version-compatible—is front-loaded after the resource statement.

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 read tool with no output schema, the description is adequate at a high level, but it leaves parameter semantics to a schema that is only 33% documented. An agent still lacks explicit guidance on required fields, filtering, and limits, so it is not fully complete 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 only 33%, with limit and component undocumented in the schema. The description does not compensate: it never mentions the required component parameter, the limit cap, or the query filter. It only implies a component via 'the component's documentation page', which is insufficient for correct invocation.

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 resource ('working examples from the component's documentation page') and adds that they are executed and version-matched. It clearly identifies the tool as retrieving examples, but does not differentiate from siblings like get_props or get_component beyond the implicit resource 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?

There is no explicit when-to-use guidance, no conditions for selecting this over alternatives, and no stated prerequisites. The closest signal is 'from the component's documentation page', which implies usage but leaves the agent to infer when this tool is appropriate versus get_props or get_component.

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?

Annotations already declare readOnly=true, idempotent=true, destructive=false and closed-world, so the safety profile is fully covered. The description adds one useful behavioral constraint — the library's idiom that styling should go through props rather than inline styles — but says nothing about the shape or size of the returned prop set.

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

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

Two sentences, zero filler. The scope statement comes first and the actionable instruction ('call this BEFORE...') is front-loaded before the rationale.

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 read-only lookup tool with annotations covering safety and no output schema, the definition is nearly complete: it says what is returned and when to call it. Minor gap is that it does not hint at how large/structured the returned prop list is or whether results are grouped.

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

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

Schema coverage is 100% and the single optional 'group' param is already documented with examples, so the baseline is 3. The description goes further by enumerating the areas (spacing, colour, typography, flexbox, visibility) that correspond to the group filter, reinforcing the valid filter vocabulary.

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: it returns the helper props every bestax component accepts plus their valid values, with concrete categories (spacing, colour, typography, flexbox, visibility). It is clear on its own, but it does not explicitly differentiate itself from close sibling names like get_props or get_css_variables.

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 triggering condition: call this BEFORE writing an inline style or utility class by hand, because the library expects those to be props. That is strong context, but it never names an alternative tool (e.g. get_css_variables or lookup_bulma_classes) for agents that genuinely need raw CSS/classes.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds a cost/efficiency trait ("cheaper than get_component"), which is genuinely useful context an annotation cannot express. It does not describe output shape or behavior for invalid dot-paths.

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

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

Two short sentences, no filler, with the resource scope front-loaded and the comparative cost note placed last. 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 simple two-parameter read tool with no output schema, the description covers what is returned (the prop table), the subcomponent addressing mode, and the reason to prefer it. Missing only the relationship to get_helper_props.

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

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

Schema description coverage is 100% and both parameters are documented there, including the same "Navbar.Brand" example. The description reinforces the dot-path concept for compound families but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description states the specific resource (the prop table) and its scope (whole component or one part of a compound family), which is more precise than the title alone. It also names and contrasts with sibling get_component. It stops short of differentiating from the closely related get_helper_props, which is also a props-adjacent sibling.

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?

"Cheaper than get_component when the props are all you need" gives an explicit selection rule against an alternative. No exclusions beyond that, and get_helper_props is left unaddressed, so it is not fully complete.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the two-mode behavior (instructions vs. reference) but says nothing about content size, failure modes for unknown skill names, or prerequisites.

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

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

Two short sentences, front-loaded with what the tool returns before the sequencing advice. Every clause earns its place with no redundancy.

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

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

For a simple two-parameter read tool with no output schema and full annotation coverage, the description covers both invocation modes adequately. It stops short of explaining what a 'skill' is or how names resolve, which is a minor gap given the sibling list_skills.

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

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

Schema coverage is 100%, with examples for both 'name' and 'reference', so the schema does the heavy lifting. The description adds a usage nuance for 'reference' (pull only when depth is needed) but no format or syntax beyond the schema.

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

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

The description names the resource (a skill's instructions or one of its reference documents) and the retrieval mode, distinguishing it from list_skills which enumerates them. The verb is implied rather than stated ('A skill's instructions'), but an agent can still tell what it returns.

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

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

It gives explicit sequencing guidance ('Load the skill first') and a condition for the optional reference parameter ('only when you need that depth'). It does not name siblings like list_skills as alternatives, but the when/when-not advice for the two modes is clear.

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

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

Annotations already declare read-only, idempotent, non-destructive and closed-world behavior, so the safety burden is lifted. The description adds value annotations do not cover: cost ('Cheap') and output structure ('one-line purpose, grouped by category'). It stops short of mentioning result size or pagination, keeping it from a 5.

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

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

Two short sentences, zero filler. The output shape is front-loaded and the routing instruction follows immediately, so the agent gets the essential facts in the first read.

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

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

For a zero-required-parameter enumeration tool with no output schema, the description covers purpose, return shape and routing well. Minor omissions, such as roughly how many components come back or whether the result is exhaustive across categories, keep it just under a 5.

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

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

The single 'category' parameter is fully documented in the schema at 100% coverage, including the allowed values, so the schema does the heavy lifting. The description adds nothing about how grouping or filtering by category behaves, which is the baseline 3 case.

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 ('list components'), the scope ('every documented component'), and the return shape ('one-line purpose, grouped by category'). It also names the sibling it feeds into (get_component), so an agent can distinguish it from a detail-fetching call without opening a 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?

Prescribes the workflow explicitly: call this first to find the right name, then call get_component. It also gives a selection cost signal ('Cheap'), which is exactly the kind of routing guidance an agent needs when choosing among list_skills, search_bestax and the get_* detail 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds that entries are task-level guides read via get_skill, which is useful context, but says nothing about catalog size, grouping, or freshness that the structured fields don't already convey.

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

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

Two short sentences with zero waste: the resource and its categories come first, and the routing hint to get_skill follows. 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 parameterless, read-only catalog tool with no output schema, the description supplies enough to act: what the entries are, what topics they cover, and which tool consumes them. It could say more about how results are presented (grouped by category? one per skill?), but nothing needed to invoke 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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is a parameterless enumeration. Baseline 4 applies when there are no parameters to document.

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 the resource (bestax Agent Skills) and enumerates its scope (forms, theming, layout scaffolding, icons, custom components, migration, CSS size), so an agent knows this is a catalog of task-level guides. The listing verb is implied rather than stated, but the sibling routing ('Read one with get_skill') makes the distinction from get_skill 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?

Clearly states the follow-up workflow: browse this list, then call get_skill 'when a task matches'. It gives a clear context for use but never states when not to call it or how it relates to the other siblings (search_bestax, list_components).

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds value beyond them by disclosing the return shape ('one row per class'), which matters since there is no output schema, and by flagging the optional tag pass-through.

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 core behavior, then usage, then the tag hint; every sentence carries information. The inline class-string examples aid selection but make it slightly longer than strictly needed.

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 read-only lookup with a fully documented schema and annotations, the description supplies the missing return-format cue and the usage trigger. Nothing essential for correct invocation appears absent, though the row/field shape is only gestured at.

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

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

Schema description coverage is 100%, so both parameters (tag, classes) are already documented with format and examples in the schema. The description's 'pass the tag the classes sit on when there is one' hints that tag is contextually optional, but adds little beyond the schema baseline.

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: maps a Bulma class string to its bestax component and props, one row per class. The concrete examples ('button is-primary', 'columns is-mobile') and the class-string framing distinguish it from sibling lookups like get_component and get_props.

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 explicit when-to-use guidance: call BEFORE hand-writing a Bulma class, and when converting existing markup, plus to pass the tag when one exists. It does not name an alternative tool or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds one useful behavioral fact about results (each hit names the next tool), but with no output schema it leaves pagination, ranking, and result shape largely 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?

Two short sentences, front-loaded with what is searched and immediately followed by the routing role. No filler or restated name/title.

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

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

For a search tool with no output schema, the description usefully explains the return semantics (hits name the tool to call next). It is nearly complete, though it omits anything about result volume, limits, or ranking.

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 67% with 'kind' and 'query' described in-schema; the description adds no parameter-level detail beyond the schema, and 'limit' is undocumented entirely. This matches the baseline for high-but-incomplete schema coverage.

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

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

States a specific verb (search) and enumerates the resources covered (components, props, examples, CSS variables, skills). The phrase 'entry point — each hit names the tool to call for the full thing' cleanly differentiates it from siblings like get_component and get_props.

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 context ('The entry point') and an explicit directive ('Use this before guessing a component name'), which steers the agent to search-first behavior. It implies the follow-up routing but does not name specific alternatives or when-not conditions.

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