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

With no annotations, the description carries the full burden, and it does disclose genuinely useful behavior: the $0.50 USDC x402 price and that billing occurs only on success. However, for a transform tool it omits whether the source GLB is mutated, expected processing time, failure/refund behavior, and the output format, leaving meaningful operational gaps.

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 lead sentence is front-loaded and useful, but the trailing 'Part of GLB optimizer...' sentence restates the same pipeline (dedup, simplify, meshopt/draco) and the same 'web or mobile' framing almost verbatim, consuming space without adding information.

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?

For a 7-parameter tool with zero required params, no output schema, and no annotations, the description covers the core operation and cost but leaves the agent guessing which input field to supply, what the result looks like, and how the non-enum parameters (maxTextureSize) behave. Adequate but with clear gaps.

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 only 29% (glb and simplifyRatio documented), so the description must compensate. It partially does by mapping pipeline terms to parameters ('WebP textures' → textureFormat, 'meshopt or Draco' → compression, 'web or mobile' → preset, 'simplify' → simplifyRatio), but maxTextureSize and the glb vs. glbUrl choice remain unexplained in both places.

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 specific verb and resource ('Shrink a large GLB (up to 50 MB) for web or mobile') and enumerates the actual pipeline steps, so an agent knows exactly what happens. It references the sibling 'optimize' as the same pipeline, implying this is the large-file variant, but never states plainly how it differs from glb_optimizer_optimize beyond the 50 MB cap.

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 context is only implied: 'for web or mobile' and the 50 MB ceiling suggest when the tool fits, but there is no explicit when-to-use vs. optimize/convert/lod guidance and no prerequisites (e.g. that glb or glbUrl must be supplied). The agent must infer routing from the size cap alone.

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