Front-End Checklist

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

Annotations already declare readOnly, idempotent, open-world, non-destructive behavior, and the description usefully adds scope limits: static-only analysis, refusal of private/localhost/HTTP targets, and an explicit non-exhaustive caveat. It does not disclose rate limits, payload size caps, or timeout/fetch-failure behavior, which matter for a live network fetch.

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 capability, then trigger, then boundaries. Every sentence carries distinct information 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?

An output schema exists, so return values need not be described. The description covers what the tool does, when to use it, what targets are refused, and what it explicitly does not measure — sufficient for an agent to call 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 all three parameters (url, focus, minPriority) are already fully documented with enum options and defaults. The description only restates the HTTPS-only constraint already present in the url schema, adding no new 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 and resource ('Fetches a public HTTPS page and performs a non-exhaustive static review of its HTML') plus the output shape ('prioritized issues and fix guidance'). This clearly separates it from the rule-lookup and reference siblings, which do not fetch or analyze live pages.

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 trigger ('when the user requests an audit of a deployed public page') and clear exclusions (no localhost, private networks, or plain HTTP; no execution, Core Web Vitals, or accessibility certification). It stops short of naming the overlapping sibling review_code as the alternative for local/source-level analysis.

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 safety is covered. The description adds meaningful behavioral context beyond those: it uses static heuristics, returns findings and verification guidance, and explicitly states that results do not establish rendered-state or runtime conformance. This is valuable limitation disclosure, though no auth or rate-limit context is provided.

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

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

Four sentences, each earning its place: the main operation, the no-code fallback, the usage condition, and the limitation. It is front-loaded with the core behavior and contains no filler or repetition.

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 rich annotation set, 100% schema description coverage, and an output schema that handles return values, the description is complete for correct invocation. It covers the main path, the no-code fallback, usage timing, and key limitations, leaving no critical gap for an agent deciding to call this tool.

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 documented in the schema, including the meaning of omitting code and the slug format. The description reinforces that the rule must be named and that code omission triggers manual guidance, but it adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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: checks a code snippet against one named frontend rule. The scope is tightly constrained to a single rule, which distinguishes it from broader sibling tools like review_code or audit_url. It also states the mechanism, static heuristics, making the purpose 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?

It gives a clear condition for use: when the user requests a check of a specific rule or a proposed fix. It also distinguishes the no-code path by returning manual verification guidance. However, it does not explicitly name alternatives or when not to use this tool versus siblings like review_code or audit_url.

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 value by clarifying that the tool returns explanation guidance rather than applying a fix, which tells the agent the output is advisory content, not a mutation or a remediation action.

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

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

Three short sentences, front-loaded with the core action, then usage, then output nature. Every sentence earns its place with no repetition of the name or 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?

With a full output schema present, the description does not need to explain return values, and annotations cover safety. It is complete for the core call, but the unresolved overlap with the get_rule sibling leaves a small ambiguity an agent must resolve elsewhere.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents the slug format and the catalogue constraint. The description adds nothing about the slug, which is the expected baseline when the schema does the work.

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

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

The description gives a specific verb and resource ('Explains one frontend rule') and enumerates the content it covers (background, user/business impact, related categories). It distinguishes itself from fix_rule by stating it returns explanation guidance rather than applying a fix, but it never clarifies how it differs from the sibling get_rule, which an agent can only infer.

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

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

It states a clear trigger condition: 'Use it when the user asks why a practice matters or requests educational context.' That is explicit when-to-use guidance. There is no when-not guidance beyond the implicit contrast with fix_rule, so it falls short of naming alternatives outright.

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. The description's added value is resolving the misleading 'fix_rule' name by stating explicitly that it 'does not edit files or apply changes' and that codeSnippet is context-only, which tells the agent this is purely advisory despite the mutation-flavored name.

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

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

Three short sentences with zero filler: purpose first, then the usage trigger, then the non-mutation boundary and optional parameter note. Every sentence earns its place and the key 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?

With a full output schema, complete annotations, and 100% parameter documentation, the description only needs to cover purpose, trigger, and the advisory-only nature, all of which it does. Minor gap: it does not mention the priority field's semantics or any catalogue-membership failure mode beyond the schema's slug note.

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 schema already documents slug (kebab-case catalogue ID) and codeSnippet (violating code for context). The description's note that codeSnippet is optional and provides context only restates 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 a specific verb and resource: it 'returns step-by-step remediation guidance and priority for one named frontend rule.' That output type (remediation steps + priority) is distinct from siblings like explain_rule (explanation), check_rule (evaluation), and get_rule (raw data), so an agent can route to it 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?

It gives a clear positive trigger ('when the user requests implementation or fix instructions for a known issue') and an implicit exclusion ('for a known issue' implies this is not for discovery). No sibling is named as an alternative, so it falls short of the explicit when/when-not/alternative bar.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety bar is met. The description still adds real context: the optional includeContent flag pulls long-form bodies and is explicitly flagged as large, which is a useful performance cue the annotations don't 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?

Front-loads the return contract well, but the final sentence re-lists all twelve checklist slugs verbatim from the schema enum, which is pure duplication that consumes roughly half the text. The parameter behavior sentence earns its place; the slug list does not.

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 explanation is not strictly required, yet the description usefully summarizes the payload shape and the includeContent tradeoff. A two-parameter, enum-constrained read tool needs little more; only the sibling routing detail 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 both parameters are already documented in the schema, making 3 the baseline. The description restates includeContent's behavior ('optionally adds each rule's long-form body') without adding format, size, or default nuance beyond what the schema says.

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 (returns) plus the resource (rules in a curated checklist) and enumerates the returned fields (titles, priorities, verification/remediation prompts). The 'every rule in an entire checklist' scope implicitly separates it from singular siblings like get_rule or check_rule, but no sibling is named explicitly, 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?

Gives a clear activation condition: 'Use it when the user requests guidance for an entire checklist.' That cleanly implies the bulk-listing case, but it names no alternative (e.g., get_rule for a single rule, search_rules for filtering) or exclusion, so it stops at 4 rather than 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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds useful behavior context by naming the three output formats and the default priority filtering, but says nothing about size limits, pagination, or what happens for an unknown category.

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 padding, with the core capability front-loaded and the usage condition second. 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?

With a 3-parameter schema fully documented, enums on two params, and an output schema handling return values, the description only needs to frame purpose and usage. It does that adequately, with the sole omission being differentiation from the similar checklist sibling.

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 every parameter including the two enums is already documented in the schema with defaults and usage hints. The description's mention of format and priority adds no meaning beyond that, so the baseline of 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 and resource ('Returns a compact checklist for one frontend category') plus the filtering and formatting dimensions, so the agent knows exactly what it produces. It does not, however, distinguish itself from the sibling get_checklist_rules, which sounds like an overlapping capability.

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

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

It gives a usage context ('when the user requests a concise checklist for a deployment, review, or team handoff'), which is real guidance. But it offers no when-not guidance and never mentions the near-identical sibling get_checklist_rules, leaving the agent to guess which of the two checklist tools to pick.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: unknown slugs do not fail but return similar suggestions, and it enumerates the response payload's content areas. It says nothing about rate limits or response size, but for a read-only lookup that gap is minor.

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 the payload contents and followed by the usage condition. The first sentence's long enumeration is justified because it is the main differentiator from lookup/validation siblings, though it is list-heavy and could be tightened.

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 in detail, and it correctly focuses on scope, usage condition and the unknown-slug fallback. The one missing element is explicit routing among the many rule-related siblings, which matters given ten peer 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 100% and both parameters are documented there, including the kebab-case slug format and the includeUrl default, so the schema does the heavy lifting. The description only reinforces 'one known rule slug' and the unknown-slug fallback, adding marginal semantics. Baseline 3 applies when the schema is complete.

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 ('Returns complete guidance for one known rule slug') and enumerates exactly what is returned: requirements, rationale, verification/remediation prompts, code examples, sources, related rules. It is clearly not a discovery or validation tool. However, it never differentiates itself from close siblings like explain_rule or check_rule, so the agent must infer the boundary.

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

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

'Use it when the user requests detailed guidance for a specific frontend rule' gives a clear triggering condition and implicitly covers the 'known slug' prerequisite. It offers no when-not guidance and does not route the agent to search_rules (for discovery) or explain_rule (for a lighter explanation), leaving sibling disambiguation to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only that the returned steps are ordered and carry priorities/categories, which is thin beyond what the schema and annotations supply.

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 first two sentences are tight and front-loaded, but the third sentence redundantly restates the entire enum already present in the input schema, which is wasted space and offers no new 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 an output schema present, the description need not explain return values, and the workflow-name list duplicated from the schema is harmless. What is missing is any guidance on choosing among the twelve workflows, but the tool is otherwise adequately described.

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

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

Schema description coverage is 100% and the enum is fully documented in the schema, so the baseline is 3. The description merely re-lists the same twelve slugs with no added semantic guidance (e.g., which workflow suits which situation), so no credit above 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?

The first sentence names a specific verb and resource and enumerates what is returned (ordered steps, rule slugs, priorities, categories). An agent can distinguish it from rule-lookup siblings like get_rule or check_rule, though it never explicitly contrasts with get_checklist_rules, the closest 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?

It gives a clear trigger condition: 'Use it when the user requests a structured audit such as a pre-launch checklist.' This is a concrete usage context, but there is no when-not guidance or explicit routing away from the rule-level siblings.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds that descriptions and rule counts are returned, but an output schema exists, so this is largely redundant. No permission or pagination context is added.

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

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

Two tight sentences with the capability statement front-loaded and the usage condition second. No filler or 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?

A zero-parameter listing tool with a rich annotation set and an output schema needs only a clear statement of what it returns and when to reach for it; both are present. Nothing an agent needs 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, which sets the baseline at 4. There is nothing further for the description to clarify about inputs.

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 (Lists), resource (frontend rule categories), and the returned fields (descriptions, rule counts). This distinguishes it cleanly from the rule-level siblings like get_rule, search_rules, and check_rule.

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 it when the user asks what the checklist covers or needs valid category names" gives explicit trigger conditions, including the practical case of discovering valid category identifiers. It does not name alternative tools or exclusions, 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?

Goes well beyond the annotations by disclosing that the review is 'non-exhaustive' and that an empty issue list 'does not establish accessibility conformance or runtime correctness' — a meaningful limitation an agent must know before relaying results. Annotations already cover the safe-read profile, and the description adds substantive behavioral caveats.

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, front-loaded with the action and scope, followed by usage trigger and the critical non-exhaustiveness caveat. No filler.

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

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

An output schema exists, so return values need not be detailed, yet the description still summarizes them. With 100% schema coverage and clear annotations, nothing an agent needs to select or call this tool 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 documents code, focus, and minPriority including their defaults. The description adds no syntax, format, or interaction detail beyond the structured fields, so the baseline of 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 and resource ('static heuristic review of pasted HTML, CSS, or JavaScript') and names what it returns (prioritized issues, fix guidance, manual-verification suggestions). The word 'pasted' implicitly distinguishes it from audit_url, which operates on live URLs.

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 gives the trigger condition: 'Use it when the user requests a review, audit, or debugging of source code.' It does not, however, name the alternative for live pages (audit_url) or state when NOT to use it, so it falls short of full routing guidance.

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

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

Annotations already declare this a safe, idempotent, non-destructive, closed-world read, so the safety burden is covered. The description adds genuinely new behavioral context: results are paginated and are short summaries rather than full rule bodies, which tells the agent to follow up with get_rule for detail. It stops short of describing empty-result or cursor-expiry behavior.

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

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

Two sentences, zero filler. The capability and return shape come first, then the usage trigger, which is the right front-loading for an agent scanning for the right tool.

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

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

With an output schema present, return values need not be detailed, and the description still gives a useful summary of them. All five parameters are covered between schema and description. The only omission is routing guidance against the many similar-looking siblings, which is a minor gap for a search tool.

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 limit, query, cursor, categories and priorities are all already documented in the schema, including the note that query may be omitted to filter only. The description names the same three filter axes but adds no format or combination semantics beyond the schema; 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 (finds/searches) and resource (frontend rules) plus the filter dimensions (keywords, category, priority) and the shape of what comes back (paginated slugs, titles, short summaries). The mention of lightweight summary results implicitly distinguishes it from get_rule/explain_rule, but no sibling is named explicitly, 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?

"Use it when the user requests relevant practices for a technology, concern, or pattern, such as web fonts or accessible forms" gives a clear triggering condition with concrete examples. It does not, however, state when NOT to use it or name an alternative such as get_checklist_rules or get_quick_reference, which a crowded sibling set would benefit from.

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