export_fbx

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions defaults ('Defaults to meshes/empties/armatures with modifiers applied') and return values ('Returns the absolute path, file size and the triangle count'). However, it does not explicitly state that the tool writes a file to disk, potential overwriting behavior (though the overwrite parameter exists in schema), or any side effects on the scene. This is adequate but not rich.

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 concise and well-structured, consisting of two sentences. The first sentence states the primary purpose, and the second provides key defaults and return information. There is no redundancy or extraneous detail, and the most critical information is front-loaded.

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?

Given 15 parameters, no output schema, and no annotations, the description is moderately complete. It provides purpose, defaults, and return values, but does not explain all parameters or the file-writing process. Some parameters have schema descriptions (objects, path_mode, etc.), which helps, but the overall guidance for an agent to confidently call the tool is still incomplete, especially for nuances like axis orientation and smooth type.

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 only 33%, so the description must compensate. It adds value by clarifying defaults for object_types and apply_modifiers ('Defaults to meshes/empties/armatures with modifiers applied'). However, it does not explain the meaning of many other parameters like axis_up, axis_forward, or mesh_smooth_type, relying on the schema's enum names and defaults. The description partially bridges the coverage gap but leaves significant parameters unexplained.

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 clearly states the tool's purpose: 'Export to .fbx for Unreal or Unity pipelines.' It specifies the exact output format (.fbx) and target engine pipelines, which distinguishes it from sibling export tools like export_glb, export_gltf, and export_obj. The verb 'Export' is specific, and the resource is unambiguous.

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 provides a clear usage context by stating it is for Unreal or Unity pipelines, which tells an agent when to prefer this tool over other exporters. However, it does not explicitly mention alternatives or when not to use it, such as for web or other engines. This is a useful but not exhaustive guideline.

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