search_assets

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

readOnlyHint=true already declares the safety profile, so the description's job is to add context beyond that. It does contribute real behavioral detail — CC0 licensing, all-words-must-match query semantics, and the fact that min_size_m applies only to models and textures — but says nothing about result ordering, pagination, or what an empty result means.

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 lead sentence establishes purpose, followed by a compact per-parameter list; every clause carries information and nothing is repeated from the schema or annotations. The most decision-relevant fact, the library and its content types, is front-loaded.

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 six parameters, zero schema coverage, and an output schema that removes the need to describe return values, the description covers the parameters an agent is most likely to get wrong. The unexplained limit and source fields are a modest remaining gap, especially source whose default 'polyhaven' is not clarified.

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 burden, and it explains four of six parameters meaningfully: the asset_type enum values, what query matches against, the taxonomy-path format for category with concrete examples, and the units and applicability of min_size_m. The limit and source parameters receive no explanation in either the schema or the description.

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 opens with a specific verb and resource ("Search the Poly Haven library") and names the content domain (free CC0 models, HDRIs, textures), so an agent knows exactly what it retrieves. It stops short of differentiating itself from sibling tools such as import_asset, which likely consumes these results, so it lands at clear-but-not-disambiguated.

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 implied by the parameter explanations — an agent can infer this is the discovery step before importing — but there is no explicit when-to-use, when-not-to-use, or reference to a follow-on tool. No exclusions or prerequisites are stated, so the agent must infer the workflow position.

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