ae_prepare_blender_3d_job

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

With no annotations, the description carries the behavioral disclosure burden. It reveals key side effects: creating an exchange folder, returning paths and Blender Python, requiring a transparent PNG sequence, and the AE limitation regarding .blend meshes. It clearly communicates the sequential workflow and dependencies, making the behavior transparent enough for an agent.

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 compact and front-loads the most important guidance ('MANDATORY first step'). Each sentence adds operational value: key constraint, exchange folder outputs, AE limitation, and the follow-up call. Minor redundancy exists but overall it is focused and structured clearly.

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 this is a preparation tool with no output schema, the description supplies essential workflow context: the exchange folder, the returned artifacts, the AE/Blender limitation, and the required next step. It doesn't detail the exact return structure, but the description gives enough for an agent to understand the tool's role in the larger 3D pipeline.

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 40% (job_name and object_name have descriptions; fps, frames, and resolution do not). The description does not add meaning for those undocumented parameters or explain how they affect the generated Blender Python. Since coverage is low, the description should compensate, but it doesn't address any of the individual parameters.

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 uses a specific verb ('prepare') and resource ('Blender 3D job'), and clearly distinguishes this tool from siblings like ae_import_3d_from_blender and ae_verify_blender_job by framing it as the mandatory first step. It explains the tool's exact job: create an exchange folder and return paths plus Blender Python code.

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?

It explicitly states when to use the tool: as a mandatory first step when the user asks for REAL 3D models in AE. It also gives a clear condition for the next step, calling ae_import_3d_from_blender after Blender finishes. However, it doesn't explicitly mention alternatives or when not to use it, though this is a relatively unique workflow step.

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