blender_export_asset

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

Annotations already signal a non-read-only, world-opening operation. The description adds valuable behavior beyond annotations: per-format processing details (fbx bakes modifiers and embeds materials, glTF exports textures, obj preserves normals/UVs) and an explicit guarantee to fail rather than falsely report success when no file appears. It does not discuss file overwriting or permissions, but the bar is lower given annotations cover the safety profile.

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 three sentences, each earning its place. Purpose is front-loaded, format defaults are compactly summarized, and the failure behavior is a single efficient sentence. There is no repetition or filler.

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 tool with five parameters and a nested export_options object, the description covers the main purpose and format nuances but leaves gaps. It does not distinguish from the sibling blender_export_model, does not explain the required path parameter, and, with no output schema, does not describe what the response contains. These are meaningful omissions for a moderately complex tool.

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 80%, so the baseline is 3. The description adds meaningful meaning for the format parameter by explaining what each exporter does by default, and it clarifies the objects parameter's scope. There is a slight mismatch where it says 'scene or a named set' while the schema says the default for objects is the selection, but overall it still adds value beyond the 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 opens with a specific verb, 'Export,' and identifies both the resource (scene or a named set of objects) and the outcome (a model file). This clearly distinguishes it from import-oriented tools. However, it does not differentiate it from the closely named sibling blender_export_model, so it falls short of a 5.

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 implies the tool should be used when exporting a scene or selected objects to a model file, giving clear context. It offers format-level defaults that shape behavior, but it provides no explicit when-to-use/when-not-to-use guidance and never mentions alternatives such as blender_export_model.

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