export_obj

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic operation and lists some option keys, but does not mention side effects such as overwriting an existing file, file-system permission needs, required garment state, or what the tool returns after export.

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 short and front-loaded with the core action, followed by a compact Args section. There is no filler or repetition of schema fields, and every sentence contributes useful 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 simple export tool with two parameters this is minimally adequate: the required file_path is defined and the optional options are introduced. But the options object remains under-specified, and with no output schema or annotations, there is no information about return behavior or side effects.

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 0%, so the description must compensate. It usefully defines file_path as an absolute path for the .obj file, and it lists example option keys (bExportGarment, bExportAvatar, bThin, scale). However, it does not explain the types, accepted values, or meaning of those options, so an agent cannot confidently construct a correct options object.

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 states a specific verb and resource: 'Export the garment as an OBJ file.' The OBJ format clearly distinguishes it from sibling export tools like export_fbx, export_glb, and export_gltf, so an agent can identify the intended output without inspecting schemas.

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 intended use is implied by the format name: use this tool when an OBJ export is needed. However, the description gives no explicit guidance about when not to use it or how it compares to the many other export siblings, so the agent must infer the selection criteria from context.

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