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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavioral context: it is a validation gate over declared contrast promises, and undeclared pairings are not guaranteed. It stops short of describing the exact output/report format, but the build-gate framing makes the pass/fail nature clear.

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. The core action is front-loaded, followed by when to use it, then the important contract warning. Every sentence 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?

With optional parameters, full schema coverage, and read-only annotations, the definition covers the essential operational context. An explicit description of what the tool returns on success/failure is missing, but 'build gate' and 'failuresOnly' make the expected behavior reasonably inferable.

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 are already fully documented. The description reinforces the 'one theme or all four' scope but adds no new parameter-level detail, matching the baseline for schema-covered 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 uses a specific verb and resource: it runs every contrast promise in the design system against one theme or all four. This clearly differentiates audit_theme from a single-pairing check like check_contrast, leaving no doubt about scope.

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 tool is explicitly positioned as 'the build gate' with a directive to run it after any palette change, giving clear usage context. It does not explicitly name alternatives or when not to use it, but the intended workflow is well communicated.

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 only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them, namely the compositing order (background over an explicit opaque backdrop or the theme base, then foreground over that) and acceptance of transparent values. It does not disclose rate limits or the returned pass/fail shape, so it falls short of 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 sentences, front-loaded with the core purpose and standard, followed by supported formats and the compositing rule. No filler, no repetition of the title, and each sentence carries distinct information.

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

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

With annotations covering safety, full schema coverage, and no output schema, the description covers purpose, formats, and compositing adequately. The one gap is that it never says what the call returns (contrast ratio, pass/fail against the threshold) despite no output schema existing to carry that burden.

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 all five parameters are already documented, including the enum-driven thresholds and the backdrop default. The description's format list (hex, transparent, rgb(), token names) largely restates the schema, so the baseline 3 is appropriate.

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

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

States a specific verb (check) and resource (contrast of a foreground/background pair) against a named standard, WCAG 2.2, which is far more concrete than the title alone. It never names a sibling, so an agent must infer that audit_theme is the bulk-audit counterpart rather than being told.

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 `use` parameter and the compositing behavior imply the context (checking a single rendered pair rather than auditing a whole theme), but there is no explicit when-to-use/when-not or pointer to audit_theme/suggest_token as alternatives. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that. It adds genuine context that output varies by format in supported scopes, projections and consumer verification obligations (e.g., native compilation is consumer-owned), but it never states what the call actually returns or whether anything is written to disk despite the word "emit".

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 the action and followed by the one useful framing fact about format heterogeneity. The middle clause ("projections and consumer verification obligations") is jargon-heavy but does convey that formats differ in fidelity.

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 11 output formats, the description should say what an export returns (a string, a file set, per-theme artefacts) and whether theme is required or ignored per format. The theme constraint lives only in the schema, leaving a real gap for a tool whose whole purpose is producing differently shaped output.

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

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

Schema description coverage is 100% and the format enum descriptions are unusually rich, so the schema already carries the parameter semantics. The description adds only a framing claim that each format documents its own scope; it contributes no meaning about format values or the theme parameter beyond what the schema states.

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

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

"Emit tokens in a consumable format" gives a specific verb (emit/export) and resource (tokens/design tokens), and the title clarifies it is a build-format export. It does not name the closely related sibling get_tokens or get_stylesheet, so an agent must infer the boundary between raw token retrieval and export.

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: "CSS is the complete runtime token artifact" and the schema's note that everything else exists "for tooling that cannot consume CSS" suggest css as the default and other formats as targeted alternatives. There is no explicit statement of when to call this instead of get_tokens, nor any prerequisite or selection rule in the description itself.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful scope context about what content is included (events, cleanup, responsibilities), but says nothing about response size, pagination, or truncation for what may be a large declaration dump.

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

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

Two sentences, front-loaded with what the tool returns before the filtering mechanics. The trailing content enumeration is slightly run-on but every clause adds identifying detail rather than 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?

An output schema exists, so return values need not be explained, and annotations cover the read-only nature. The description supplies scope and filtering behavior adequately, with the only real gap being lack of differentiation from sibling content tools.

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

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

Schema coverage is 0% and the schema only says id is a non-empty string. The description compensates by explaining that id accepts either a component id or an exported API name, and that omitting it returns the full catalogue — real meaning the schema does not supply.

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 ('public behavior API') and enumerates the content it returns (TypeScript declarations, automatic selectors, manual initialization, cleanup, events, application responsibilities). This is concrete and differentiable, but it never names which sibling it should be preferred over (e.g. get_component_code or get_component), leaving the boundary implicit.

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?

'Filter by component id or exported API name; omit id for the full catalogue' gives clear usage of the id, but there is no when-to-use guidance versus the many sibling tools that also return component material. Usage is implied rather than contrasted with alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful scope information (a single call is comprehensive across anatomy, a11y, tokens, content rules), telling the agent it need not chain other tools, but it discloses nothing about response shape or pagination.

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

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

A single sentence, front-loaded with the one-line purpose before an inventory of covered domains. The enumeration is long but each item signals real returned content; nothing is padded with filler or marketing language.

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 a readOnly annotation set and an output schema present, the description need not explain return values or safety, and it correctly focuses on what a single call covers. The remaining gap is sibling routing among the many get_* tools, which an agent would have to resolve on its own.

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?

There is a single required 'id' parameter with 100% schema description coverage, including examples ('button', 'table', 'combobox'). The description adds no additional meaning about the id format or lookup behaviour, so the baseline of 3 for schema-carried semantics is appropriate.

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

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

The description states a specific verb and resource ('The complete spec for one component') and enumerates the domains covered (anatomy, variants, accessibility, tokens), so its scope is unambiguous. It falls short of a 5 because it never distinguishes itself from near-neighbours like get_component_code, get_pattern, or get_behavior, which an agent must choose between.

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 rather than stated: an agent can infer it should call this when it needs a component's full specification, and the enumerated coverage acts as an implicit trigger. There is no explicit when-to-use, no prerequisites, and no routing to alternatives such as get_component_code for code samples or list_components for discovery.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: which outputs are reference vs production, that framework recipes are editable and include lifecycle wiring, and that implementation metadata should be inspected for dependencies/application responsibilities. It stops short of describing pagination or response shape, but for a read tool this is good added 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?

Three sentences, front-loaded with the core return value, then a per-format breakdown, then a follow-up instruction. Little waste, though the format breakdown overlaps with the framework enum descriptions.

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 an output schema present, the description needn't explain return values, yet it gives enough context to choose a framework and understand what each yields. Both required params are documented and the read-only nature is covered. Complete for an agent to invoke correctly; only the sibling-routing guidance is thin.

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%, including an extensive per-enum description for framework, so the schema carries the parameter burden and baseline is 3. The description's HTML/CSS/framework characterizations largely restate what the enum already documents, adding framing rather than new syntax or constraints.

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

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

The description clearly states the resource and scope: production/reference code for a component, parameterized by framework. It distinguishes the output flavors (HTML reference markup, CSS production stylesheet, framework recipes) so an agent knows what it gets. It does not, however, name or differentiate from the sibling get_component metadata tool, leaving that distinction to inference.

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: request this when you need paste-ready code for a given framework. There is no explicit when-to-use vs get_component, get_behavior, or get_pattern, and no stated prerequisites or exclusions. The per-framework output notes help an agent understand results but not tool selection.

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 and openWorldHint=false, so no safety contradiction exists. The description adds meaningful behavioral context beyond annotations: the server may be mounted under a path prefix, and the returned URLs are authoritative for this instance. This helps the agent understand why hardcoding paths is unsafe.

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

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

Two sentences with no wasted words. The first sentence front-loads what the tool returns, and the second provides the rationale for using it over assumptions. Every phrase 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 no-parameter, read-only endpoint discovery tool, the description is nearly complete: it lists the artefacts whose URLs are returned, explains why the tool exists, and clarifies the server-authoritative nature. It doesn't specify the exact response shape or keys, but the artefact list gives an agent sufficient expectation of what it will receive.

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 has zero parameters and schema coverage is 100% vacuously, so there is no parameter information missing. The description doesn't need to define inputs, and the baseline for zero-parameter tools is 4.

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

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

The description clearly states the tool returns absolute URLs for specific artefacts (stylesheet, token files, behaviours bundle, documentation site), which distinguishes it from siblings that fetch content or tokens. The verb is implicit but the resource scope is concrete and unambiguous.

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

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

The description explicitly says to use this tool instead of assuming paths, and explains why: the server may be mounted under a path prefix that only the server knows. It doesn't name sibling alternatives or give when-not-to-use conditions, but the context is clear enough for an agent to select it over content-fetching 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 and openWorldHint=false, so safety is covered. The description adds the workflow framing (read before implementing) but says nothing about the form of the returned content (markdown? length? sections?) or any constraints, so it adds only modest context beyond the annotations.

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 opening clause frames the content well, but the long comma-separated enumeration largely duplicates the schema enum and pads the description. The actionable instruction is buried at the end rather than front-loaded.

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

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

For a single-enum-parameter read tool with no output schema, the description conveys the topical scope but not the return shape or size, which is the main thing an agent cannot infer from the schema. Adequate but with a clear gap.

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

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

Schema coverage is 100% and the single enum parameter is fully documented in the schema. The description's topic list essentially restates the enum values rather than adding syntax, defaults, or selection guidance, so the 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 enumerates the subject matter ('principles, colour, dark mode, ... theming') which makes clear this returns a design-foundation document, and the closing sentence confirms the read-for-guidance intent. However, it never states the verb directly ('retrieves/returns the foundation doc for the given id') and does not differentiate itself from siblings like get_overview or get_primitives.

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?

'Read the relevant foundation before implementing in that area' gives a clear triggering condition tied to the implementation workflow. It stops short of naming alternatives or when-not-to-use cases (e.g. vs. get_overview or get_tokens), so it is context without routing.

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 mark the tool read-only and closed-world; the description adds useful behavioral context beyond that: returned recipes are flex-first, mostly avoid media queries, include accessibility and dark-mode obligations, and are paste-ready. No contradiction with annotations.

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: the first is front-loaded with what the tool returns, the second adds a useful style qualifier. Every word contributes, and there is no redundant restatement of 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?

For a read-only, one-parameter tool with an enum and no output schema, the description adequately covers the output contents and general style of the result. It does not describe the response envelope, but the simplicity of the input and annotations make this a minor gap.

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

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

The schema covers 100% of parameters, with the single id parameter fully described and an enum of valid layout ids. The description adds nothing about parameter selection, so the schema carries the burden as expected.

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 specifies a concrete deliverable – 'a complete page blueprint' – and enumerates its contents: regions, responsive strategy, accessibility obligations, dark-mode notes, and paste-ready markup plus CSS. This clearly identifies a full-layout resource and sets it apart from component/foundation-level sibling tools.

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 'complete page blueprint' phrasing implies this is the tool for whole-page layouts, and the flex-first note hints at general usage context. However, it never names alternatives like get_component or get_foundation nor says when not to use this tool, so guidance remains implied rather than explicit.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing what the guide contains (canonical plan, source-specific steps, rollout/rollback, compatibility baseline, optional legacy geometry CSS), giving the agent a clear picture of the read-only output it will get.

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 dense sentences, front-loaded with the upgrade scenario and output inventory before addressing parameters. The content list is long but each item is informative and earns its place; minor compression is possible.

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

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

With an output schema present, the description need not explain return values, yet it helpfully summarizes the guide's contents. Both parameters are addressed and the read-only nature is covered by annotations. Complete enough for correct invocation; only explicit alternative-tool routing 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?

Schema description coverage is 0%, so the description must carry the parameter meaning and it largely does: componentId 'filters behavior changes' and fromVersion 'selects the upgrade source while preserving the complete guide'. This clarifies the scope of each parameter's effect, though it could note format/syntax beyond the enum values already in 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 a specific verb and resource — it produces a migration/upgrade plan — and enumerates the concrete contents (source-specific steps, rollout/rollback, behavior changes, compatibility baseline). It does not explicitly differentiate itself from the sibling get_behavior, which overlaps on 'behavior changes', so it stops short of 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?

Usage context is implied by 'Upgrade to the current release from v2 or v3.0', which tells the agent the scenario in which to reach for it. However, there is no explicit when-to-use vs alternative, no mention of when this is the wrong tool versus get_behavior, and no prerequisites.

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, so the read-only nature is covered. The description adds no additional behavioral context such as rate limits or side effects, but is consistent with the annotation. With annotations present, the bar is lower and this meets the 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?

One efficient sentence, front-loaded with 'Start here', and lists the contents in a compact way. Every word earns its place.

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

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

For a zero-parameter overview tool, the description fully explains what is returned (map with categories and tool calls) and is sufficient for an agent to understand its role without an output 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?

The tool takes no parameters, so parameter explanation is unnecessary. Per rubric, 0 parameters yields a baseline of 4.

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

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

The description clearly states the tool returns a map of all available design system resources and includes the tool call for each. It distinguishes itself from specific siblings like get_foundation or list_components.

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

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

The phrase 'Start here' gives clear directive to use this tool first, but it does not explicitly name alternatives or state exclusions. The context is sufficient for a starting point, though not as explicit as naming alternative 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 and openWorldHint=false, so the safety profile is covered. The description adds genuine value by enumerating what the response contains (problem, solution, rules, accessibility obligations, anti-patterns), but it says nothing about invalid ids, error behavior, or whether the pattern set is closed (the enum implies it is, yet this is not stated).

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

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

One sentence, no filler, and the payload contents are front-loaded in a scannable list. It loses a point for spending its only clause on return contents rather than leading with the verb and purpose.

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

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

With no output schema, the description does the right thing by describing the returned sections, which is enough for an agent to know what it gets back. However, for a single-lookup tool in a large sibling set, it omits when to prefer it over get_behavior/get_foundation and omits any failure-mode context.

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

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

Schema coverage is 100% with a single enum-constrained 'id' parameter, so the schema already carries the semantics; baseline 3 applies. The description adds no information about valid ids, case sensitivity, or what happens for an id outside the enum.

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

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

The description clearly conveys the resource: a UX pattern record containing problem, solution, rules, accessibility obligations and anti-patterns. It is not a tautology of the name, but it uses a noun phrase with no verb ('retrieve/return') and never distinguishes this from siblings such as get_behavior or get_foundation, so an agent gets no explicit routing signal.

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

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

There is no statement of when to call this versus get_behavior, get_foundation, or search, and no prerequisites or exclusions. The only implicit hint is the word 'Sekura', which suggests a design-system reference lookup, but the agent must infer that.

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?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral context: primitives do not change between themes and therefore will not adapt to dark mode. This explains a key limitation of the data returned and helps the agent understand why these values should not be used directly in product code.

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, purposeful sentences: the first defines what the tool returns, the second states when to use it, and the third warns against misuse. There is no redundancy or filler, and the most important information is front-loaded.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, and a critical constraint. It does not explicitly state what happens if the optional ramp parameter is omitted, but the schema's description of the parameter and the overall simplicity of the tool make this a minor gap rather than a significant 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 coverage is 100% for the single optional 'ramp' parameter, and the schema already lists the valid ramp names. The description does not add additional parameter-level detail, but it doesn't need to because the schema fully documents the parameter. This matches the baseline for high 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?

The description uses a specific verb and resource: it returns 'raw colour ramps behind the semantic layer'. It clearly differentiates this from semantic-token tools by explaining that primitives are the underlying layer used to build semantic tokens, which distinguishes it from siblings like get_tokens and get_foundation.

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 gives explicit use cases: 'Use these to build new semantic tokens or to re-brand.' It also gives a strong when-not-to-use rule: never reference a primitive from product code because it won't adapt to dark mode. It does not name an alternative tool explicitly, but the context is clear enough to guide selection.

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?

The description adds a concrete behavioral constraint beyond the readOnly/openWorld annotations: the pre-paint theme script must be inline and synchronous or the page shows a flash of the wrong theme. This is actionable knowledge an agent would otherwise not have. There is no contradiction with the annotations.

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 sentence, front-loaded with the overall purpose, then a tightly packed list of contents. The parenthetical warning is dense but relevant and earns its place. No repetition or filler; it could be split for readability, but it is appropriately compact for the information it carries.

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 one optional enum parameter and no output schema, the description conveys both what is returned and a key integration constraint. It doesn't describe the exact return format or how the parts are delimited, which would be helpful, but for a simple get-setup tool this is sufficient. The main gap is no output-structure hints, and that gap is minor because the contents list already sets expectations.

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 describes `part` 100% with enum and a default note, so the baseline is 3. The description adds value by mapping enum values to friendlier terms (utility layer → utilities, theme control markup → theme-control, pre-paint theme script → theme-script), which helps an agent understand the semantic intent of each part. It doesn't explain the `all` default, but the schema already covers that.

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 defines a specific bundle: HTML scaffold, pre-paint theme script, reset, utility layer, prose styles, theme-control markup, framed as 'Everything needed to start'. This clearly distinguishes it from more targeted sibling geters like get_layout or get_tokens, though it doesn't mention any sibling by name. The verb is supplied by the tool name/title, but the resource and scope are 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?

'Everything needed to start' gives clear situational context: call this tool when bootstrapping a project with the full setup. It doesn't name alternatives or state exclusions, so it stops short of a 5, but it still tells the agent when this tool is the right choice better than a purely generic description would.

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 signal read-only and closed-world behavior, so the description does not need safety disclosures. It adds value by describing the all-in-one-file behavior and the exact layers returned, going beyond the annotations.

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

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

Two sentences, no filler, with the central purpose and content scope front-loaded. Every sentence 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?

One optional parameter, fully schema-documented, and no output schema, so the description's enumeration of returned layers is sufficient context for an agent. It could mention the include filter explicitly, but that is already in the 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 100%, with the include parameter, its enum values, and default-all behavior all documented. The description does not need to repeat this, but it also adds no extra parameter 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?

States a specific verb (get) and resource (stylesheet), then spells out exact contents: tokens for four themes and three densities, reset, prose, utilities, and every component. This clearly distinguishes it from sibling tools like get_tokens or get_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?

Explicitly frames the tool as 'the single artefact needed to render any Sekura interface,' giving a clear condition for use. It does not name when-not alternatives, but the resource scope makes the intended usage strong.

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, and the description builds on that by disclosing the resolved-value nature, the multi-theme output behavior, and the all-or-filtered scope. It doesn't contradict the annotations or claim side effects; the only minor gap is not stating output shape or limits, but the read-only and closed-world hints lower the burden.

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 main statement is front-loaded in one short sentence, followed by a compact summary of filters and output behavior. Every sentence earns its place, and no schema information is redundantly repeated.

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 four optional parameters with full schema descriptions, read-only annotations, and no output schema, the description covers the core behavioral expectations: what is returned, how filtering works, and the all-themes default. It could be slightly more explicit about when to choose this over sibling tools, 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?

Schema description coverage is 100%, so the schema already explains group, theme, filter, and includeScales. The description adds only a compact restatement ('filter by group, by name fragment, or return everything') and the default all-themes behavior, which is useful but not needed to understand the 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 names a specific resource ('resolved token values') and a clear action (return them), then distinguishes the tool's breadth: filters by group or name fragment, or returns everything. It also adds the cross-theme viewing behavior, which separates it from related tools like get_primitives or export_tokens without needing to open 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?

The description effectively gives usage context: use this for resolved tokens, optionally scoped by group, theme, or name fragment, and compare theme values side by side. It doesn't name sibling alternatives or give when-not conditions, but the intended invocation context is clear from the filtering options and 'resolved' wording.

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 and openWorldHint=false, so the read-only, closed-world nature is covered. The description adds that this is a complete catalogue with optional filters, but does not disclose ordering, pagination, or default inclusion of deprecated items. This is adequate given the annotation coverage, but not rich.

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

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

The description is one short sentence: 'The component catalogue, optionally filtered by category or status.' It is front-loaded with the core noun phrase, adds the conditional filter clause, and contains no redundant or filler words. Every word earns its place.

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

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

For a simple read-only listing tool with two optional enum parameters and no required fields, the description covers the essential what (component catalogue) and how (optional filters). It does not describe the return shape or pagination, but the tool name and 'catalogue' imply a list, and readOnlyHint covers safety. A bit more detail about what each catalogue entry includes would push it higher.

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%: both status and category have clear descriptions ('Filter by maturity.' and 'Filter by category.') and enums. The description merely paraphrases the schema with 'filtered by category or status', adding no new semantic meaning, so it stays at 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?

The description clearly identifies the resource ('the component catalogue') and implies the listing operation, distinguishing it from single-item siblings like get_component. It does not use an explicit active verb beyond the title, and it does not name a specific sibling alternative, so it stops short of 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?

The description offers no guidance on when to use this tool versus search, get_component, or get_layout. 'Optionally filtered by category or status' implies flexibility but not a selection criterion. No alternatives or exclusions are mentioned.

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 and openWorldHint=false, so the safety profile is covered. The description adds the search scope but says nothing about ranking, result ordering, or how the limit interacts with results, so it contributes limited behavioral context beyond the structured fields.

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, with the scope statement front-loaded ahead of the usage condition. 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, the description could say something about result shape or ordering, and it does not. However, the annotations, complete schema coverage and default-limit documentation mean an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so query, kinds and limit are already documented in the schema. The description's domain list loosely maps to the kinds enum but adds no syntax or format guidance beyond it; 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?

States a specific verb (full-text search) and resource (the design-system corpus), and enumerates the content domains it covers. That enumeration plus the 'full-text' qualifier cleanly separates it from the get_*/list_* siblings, which retrieve a single known 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?

'Use when you know what you need but not where it lives' gives a clear, actionable selection condition. It implies rather than names the alternative (the direct get_component/get_tokens tools when you do know where it lives), so it falls just short of an explicit when-not/alternative statement.

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 declare the tool is read-only, and the description adds meaningful behavioral detail beyond that: it returns resolved values per theme and explains token selection with reasoning about neighboring tokens. This gives the agent a clear picture of the tool's output without contradicting any annotations.

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, both substantive: the first explains the tool's function and output, the second gives practical usage guidance. No filler or repetition of the 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 simple, read-only tool with only one required parameter and no output schema, the description covers the key context: how to phrase the input, what kind of results to expect, and when to prefer this tool over guessing. It could be slightly more complete by explicitly noting the optional limit parameter or naming a sibling alternative, but these are minor 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?

The description explains the intent parameter semantically ('Describe what you are styling in plain words') and the schema provides useful examples for intent. However, the optional 'limit' parameter is not mentioned in the description and has no schema description, so the semantics of that parameter are left entirely to inference from its name and min/max constraints.

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

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

The description uses a specific verb ('Describe... and get') with a clear resource ('semantic tokens') and states what is returned: resolved values per theme and a rationale comparing to neighboring tokens. This clearly distinguishes the tool from siblings like get_tokens or search, which retrieve tokens rather than recommend them from a natural-language intent.

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 instruction 'Use this instead of guessing a token name or reaching for a hex value' gives clear guidance on when this tool is appropriate. It does not explicitly name alternative sibling tools or state when not to use it, but the intended use case is unambiguous.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: it returns structured findings plus fixes, and explicitly does not execute callbacks — a meaningful side-effect boundary the annotations do not 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 tight sentences with no filler; the validated surface is front-loaded and the behavioral caveat follows. Efficient and well-ordered for its size.

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?

An output schema exists, so return value detail is not owed by the description, and the read-only nature is covered by annotations. However, the low parameter coverage and absence of any when-to-use/alternative routing leave gaps for an agent deciding whether to call this versus validate_markup.

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 13% across 8 parameters, so the description must compensate. It narratively covers markup, stylesheets, SVG symbols, ID references (externalIds), initialization, and handledEvents, but omits controllers and componentIds and gives no format/syntax detail. Partial compensation justifies a mid score.

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 (check) and enumerates exactly what is validated: markup, stylesheet dependencies, SVG symbols, ID references, initialization, and declared events. This is far more concrete than the title, though it never explicitly distinguishes itself from the sibling validate_markup beyond the implicit 'integration' scope.

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 the obvious sibling validate_markup, which an agent would need to choose between. The scope (integration-level) is only inferable from the name and the checklist of what it inspects.

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 and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond the annotations: the checks are scoped to shipping failures and the result is explicitly advisory, not a certification of accessibility — important for how the agent should phrase findings. It stops short of describing result format or coverage 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?

Front-loaded with the verb and resource, then a tight enumeration of concrete failure types, closed by a one-clause caveat. The long list is informative rather than padding — it defines the check surface with no redundant sentences.

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 lint tool with fully documented parameters, the description covers purpose, scope, and the crucial advisory semantics. The one gap is the return shape: there is no output schema and the description never indicates what a result contains (findings list? per-check messages?), which the agent would need to present results.

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 markup (with its size bound) and componentId are already documented in the schema. The description adds nothing about the parameters themselves, so the 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?

Specific verb ('Checks') plus concrete resource ('HTML or CSS') and an enumerated set of failure classes (accessible names, tabindex, focus outlines, live regions), so the agent knows exactly what linting surface this covers. It does not explicitly distinguish itself from the sibling check_contrast, which overlaps on the colour/dark-mode checks, so it falls short of 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?

Usage is implied by the check list ('the failures that actually ship'), but there is no explicit when-to-use statement and no routing to alternatives such as check_contrast for pure contrast questions or get_component for spec lookups. The advisory caveat addresses interpretation of results, not tool selection.

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