export_glb

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

Goes beyond the annotations by disclosing that the scene is restored after export, that the export scale is baked into top-object node scale, that images on disk are untouched, and that unknown options surface as ignored_options. It stops short of stating overwrite/auth semantics for the target path, but the non-destructive behavior is clearly confirmed against destructiveHint=false.

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-loads the core action and then attaches caveats to the parameters that need them; most sentences earn their place with concrete detail (25 MB for nine 2048 px maps). It is dense and occasionally run-on, but not padded.

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 10-parameter mutating export with no output schema, it covers the destructive/restorative behavior, the key option semantics, and even describes the returned 'textures' payload. The remaining gap is the undocumented boolean flags (skins, tangents, animations, apply_modifiers).

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?

With 0% schema coverage the description must carry the load and it does for the tricky parameters: draco (needs runtime decoder), influences (bones per vertex the engine reads), scale (with a concrete 0.1 m x 10 = 1 m example), and max_texture_size (with size/bytes guidance). skins, tangents, animations and apply_modifiers are left unexplained, so coverage is good but not complete.

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 ('Write a GLB') and immediately scopes it ('of the named objects (with children), or of all visible geometry'), which separates it from import_glb, inspect_glb, check_game_ready and save_blend. An agent knows exactly what artifact this produces and from which selection.

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 via the game-engine framing (Draco decoder, influences read by the engine, game-ready file sizes); there is no explicit statement of when to prefer export_glb over save_blend or run_spec. The reader must infer the alternatives.

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