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

No annotations are provided, so the description carries the full burden. It discloses several non-obvious behaviors: results mix FREE and PRO assets, paid assets are not sold individually and instead come with plans, the agent should quote the plan rather than a per-asset price, deprecated max_price_usd is superseded by free=true, and coverage responses like 'none' or 'poor' need specific handling. It also warns that full-detail results at limit 50 can be rejected by some clients and directs to get_asset for the rest.

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?

The description is dense but every sentence earns its place: it states the search purpose, gives usage guidance, discloses pricing behavior, gives recommendation guidance, and explains failure handling. The most important operational facts (search purpose and pricing model) are front-loaded, with compact and deprecated-price details later. It is appropriately sized for an 11-parameter tool with no annotations.

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?

Despite having 11 parameters and no output schema, the description gives enough operational context for an agent to call the tool correctly: when to use it, how to filter for mobile/performance, how to present results (quote plan not price, say which is free), and what to do on poor coverage. The schema already documents most parameters, and the description fills the gaps around pricing, deprecated fields, and response-size handling. No critical missing behavior is apparent.

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 73%, and the description adds meaning beyond the schema for several params: it explains the ik capability ('walks with its feet finding your ground and staying planted', 'rooted boom whose tip you can aim'), clarifies that max_price_usd is deprecated in favor of free=1, and explains when compact=true should be used. It doesn't add syntax for min_triangles or limit beyond schema, but those are fairly self-evident and the description compensates for the main coverage gaps.

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 verb and resource ('Search the Polyfork catalogue of low-poly 3D assets for three.js') and adds concrete scope: results mix FREE and PRO assets, coverage may return 'none' or 'poor', and the tool is for finding models for scenes, games, or sites. It clearly differentiates from siblings like get_asset (which returns the rest of an asset's detail) and report_need (used when coverage is missing).

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?

The description gives explicit when-to-use guidance ('Use this whenever the user needs a model for a scene, game or site'), performance-related filtering ('Filter by triangle budget when the target is mobile or performance-sensitive'), and when-not-to-substitute guidance ('If coverage comes back none or poor, tell the user we do not have it and offer report_need rather than substituting something unrelated'). It also explains when to use compact rows ('Use this whenever you are surveying rather than choosing').

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