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

Annotations only declare readOnlyHint and openWorldHint, so the description adds real context: the default return is one line per rule, that 61 rules exist, that full detail includes violation-detection guidance, and that rule texts are in German. A note on rate limits or ordering is absent, but this is substantive 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?

Front-loaded with purpose and the token-vs-rules distinction, then the invocation modes. It is a long single block and the 'Rule texts are in German' caveat and category enumeration are appended after the actionable content, but almost every sentence carries usable information.

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

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

With no output schema and no required parameters, the description carries the return-shape burden and does so: one line per rule by default, full text with detection guidance on request, plus the language of the content. An agent has everything needed to invoke it correctly on a first try.

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 category list, scope meaning, and the detail default ('Defaults to full when rules are given') are already stated in the schema. The description's parameter-adjacent content largely restates this, adding little syntax or semantic detail beyond the structured fields, 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 names a specific resource (universal design rules for building UI with design tokens) and enumerates the domains covered, then contrasts itself against the token tools: 'The tokens say which values exist; these rules say how to use them.' An agent can separate this from get_design_system without opening either schema.

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

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

It gives explicit timing guidance ('Call this before building or reviewing views') and explains the retrieval modes (no arguments = all 61 rules; rules/category with detail 'full' = complete text). It does not, however, state when to prefer the sibling token tools or any exclusion cases, so the guidance is clear but not exhaustive.

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