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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine value beyond them by itemizing the returned content (props, variants, dependencies, installed files, usage example, a11y/responsive notes), which matters since no output schema exists. It does not mention behavior on an unknown slug, which is a minor gap.

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 front-loaded sentence that moves immediately from scope ('everything about one component') to the excluded portion and then the content list. No filler; the enumeration is dense but each item is informative.

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 single-parameter read tool with full annotation coverage and a fully described schema, the description carries the remaining burden of describing the return payload, which it does thoroughly. Missing only edge-case behavior (invalid slug) and any pagination/size caveats.

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?

Single required 'slug' parameter with 100% schema description coverage, including a concrete example ("data-table"). The description adds nothing about naming conventions or lookup behavior beyond what the schema already provides, 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+resource (retrieves one component's metadata) and enumerates exactly what it returns. The phrase 'except its source' implicitly distinguishes it from get_component_code, but no sibling is named explicitly, keeping it 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 only implied: the 'except its source' qualifier hints that get_component_code is the alternative for source code, but there is no explicit when-to-use/when-not guidance or named alternative. Adequate minimum-viable framing, no routing instruction.

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