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 important behavior beyond that: the exact return shape (rule, why it matters, agent trap, how to check) and, critically, the Pro gating – with Pro you get full matching rules, without Pro you get free rules plus only Pro titles.

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 trigger condition is front-loaded, which is good, but the middle is a dense run-on enumeration of roughly fourteen topics that reads as a wall of prose. All items are arguably useful for topic matching, yet the return-shape and Pro-gating facts, which matter most for deciding to call it, are pushed to the end.

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 only two parameters and no output schema, the description compensates well by describing the return contents and the Pro/non-Pro difference. Minor gaps remain: no mention of the limit default or how results are ordered when several rules match.

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 baseline is 3, but the description's topic examples materially clarify what a valid 'topic' string looks like and the level of specificity expected. The 'limit' parameter and its default are not mentioned, which keeps it from a 5.

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

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

Names a specific verb+resource (get the rules for what you're building) and backs it with concrete, recognizable topic examples like 'loading button', 'contrast', and 'error handling'. It also states the covered domains (UI design, code craft, product thinking, working with your human), so an agent understands the retrieval scope immediately.

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 'Call this WHILE building, for the specific thing in front of you' gives real timing and granularity guidance – query during the build, scoped narrowly rather than batched. It does not name when to prefer a sibling such as get_check or review, so there is no explicit exclusion or alternative routing.

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