Projet After Effects

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It honestly lists the operation range, including suppression (deleteItems) and enregistrement (save), which signals destructiveness and persistent side effects. However, it does not warn that deletions are irreversible or describe side effects of save/set operations on the project state. Adequate but shallow for a tool that can mutate and destroy.

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?

One compact sentence that front-loads the purpose and enumerates the operation families without padding. For a tool spanning seven actions and 13 parameters, the brevity is appropriate and every listed item maps to a real operation in the schema.

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 the complexity (7 action variants, 13 params, no output schema, no annotations), the description is a serviceable high-level overview but lacks guidance on selecting among the actions (e.g., when to use import vs set vs moveItems) and gives no expectation of return values. An agent would need to consult the schema for each parameter but would still be guessing at action-selection criteria for a given user goal.

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 coverage is 100%, so the schema already documents all 13 parameters and their action-conditional meanings. The description adds marginal contextual value by noting that PSD/AI files import as comps and that 'reglages projet' corresponds to the set action — loose ties to the importAs and action enums. This meets the baseline 3 but does not exceed it, since the schema carries the substantive burden.

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 resource (project) and enumerates its operation families: inventory (get), import, folders, save, delete, settings. This gives a clear sense of scope and differentiates it from the sibling tools that target specific object types (ae_layer, ae_comp, ae_shape). It is slightly broad because it bundles seven actions into one tool, but the listed operations map directly to the action enum.

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 scope is implied by the enumerated operations — project-level management — but the description never names sibling tools or explains when to choose ae_project over ae_layer, ae_comp, or others. There is no explicit when-to-use/when-not-to-use guidance or exclusion criteria, so an agent must infer boundaries from the operation list alone.

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