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

Annotations already declare readOnly, non-destructive, non-open-world, so the safety profile needs no restating, and the description instead spends its words on useful behavior: the shape of the returned content and what happens when a pair is not offered (it reports the miss and suggests the nearest alternatives). Minor gap is that it does not say whether the notes are static curated docs or derived per request, which affects how much trust an agent places in the 'limits' section.

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?

It is a single dense sentence pair whose very first clause is the actionable constraint ('Before uploading anything'), so the agent gets the trigger before the payload description. The parenthetical enumeration of preserved attributes is efficient, though the middle clause is long enough that the 'page for that pair' return value is easy to skim past.

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 no output schema, the description carries the burden of describing returns and does so adequately: surviving features, losses, limits, a page reference, plus the negative case. What remains unstated is the response shape (prose vs structured) and whether the 'page' is a URL the agent can surface, which is a modest gap for a two-parameter read-only lookup.

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%, with the 'from' enum vocabulary and the 'to' vocabulary both documented in the schema itself. The description adds a concrete worked example (fbx to glb) that anchors the argument order, but nothing about normalization, casing, or unsupported target strings beyond the general 'not offered' behavior, so it sits at the baseline for a fully described schema.

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 makes clear this is a reference/lookup tool keyed on a source-target format pair, returning what survives (skeleton, shape keys, materials, vertex colours), what is lost, format limits, and a documentation page. That is a specific and distinct resource from the sibling convert_file, which actually performs conversions, though the description never names that sibling to make the contrast explicit.

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?

'Before uploading anything' gives a concrete trigger point that tells the agent to call this prior to a conversion attempt, and the unsupported-pair clause signals it is safe to probe pairs speculatively. It stops short of explicitly stating 'then use convert_file to perform the conversion', so the routing to the actual conversion sibling is left to inference.

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