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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the lower bar applies. Beyond them, the description adds genuinely useful behavioral facts: results are license-reviewed, every set permits commercial use and redistribution, and the license notice must be retained with copied icons. It does not mention rate limits or caching, but the licensing/pinning context is substantive.

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 the verb and lookup key, then the payload list, then the licensing obligation, then the parameter tip. Three sentences and no filler. Slightly dense in the payload enumeration, but every clause carries information an agent needs.

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?

There is no output schema, so the description correctly compensates by listing the returned fields, and there is no pagination or auth concern to document for a read-only, idempotent lookup. The only shortfall is that the language parameter's effect on the returned prompt is left implicit, so an agent must infer it from the schema enum.

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 0%, so the description must carry the parameter burden, and it does for two of three: 'id' is defined as a search result id and include_source is given a concrete semantic (false = metadata only). The language parameter is only obliquely referenced via 'Chinese/English integration prompt' and never stated as a selectable zh/en output-language switch, leaving that one gap.

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 precise verb (Retrieve) and resource (reviewed SVG icon) and pins the lookup key ('by its search result id'), which cleanly separates it from the sibling list-style tool search_ui_icons. It also enumerates the returned payload (svg source, SHA-256 hash, revision, author, license, prompt), so an agent knows exactly what comes back before opening the 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?

'by its search result id' establishes the precondition that this tool follows a search step, which is the key routing signal. It also gives an explicit mode switch ('Set include_source=false for metadata only'). It never names search_ui_icons directly or states when not to use this tool, so it stops short of full when/when-not guidance.

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