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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds that the payload is documentation-style content and that 'core' returns raw SVG/JavaScript rather than a framework wrapper, but since an output schema exists, the enumerated return contents largely restate structured data.

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 front-loaded clause enumerates the returned artifacts and closes with the alternative parameter meaning — no filler. It is a noun phrase rather than a sentence, but structurally efficient.

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 fully documented enum parameter, full annotation coverage, and an output schema, the description only needs to convey what kind of content comes back and what 'core' means — both are present. The missing piece is explicit routing versus the sibling 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 the enum plus its per-field description already document the framework ids and the 'core' option. The description adds only a small amount of meaning by clarifying that 'core' yields raw SVG and JavaScript instead of a package-specific snippet, 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 names a specific resource — install command, import example, dynamic icon API, and docs link — for a framework package, which is distinct from what get_icon or search_icons return. It does not explicitly name the siblings it differs from, so the agent must infer the boundary 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?

Usage is only implied: an agent can deduce this is the follow-up step after locating an icon, but the description never states when to call this versus get_icon, nor any prerequisites. The one piece of selection guidance given is which parameter value to pick ('core' for raw SVG and JavaScript).

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