Export project JSON

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

Annotations only provide destructiveHint=false. The description adds valuable behavioral context: it writes to outPath or returns inline, and warns that inline JSON can get large. This goes beyond the minimal annotation and helps the agent anticipate size-related performance implications, though it does not disclose every edge case (e.g., overwrite behavior or exact JSON structure).

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 two sentences, front-loaded with the core action and scope, followed by the output-mode detail. Every phrase earns its place; the list of serialized components is concise but informative, and there is no fluff.

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 there is no output schema, the description does the work of explaining what the tool returns by listing serialized components and stating that JSON is returned inline when outPath is omitted. It also flags the potential for large outputs. It could specify the root JSON structure or error behavior, but for a complex export tool, this is a reasonably complete picture.

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% with detailed descriptions for both `pretty` and `outPath`. The tool description simply restates the outPath behavior ('Write to outPath or return inline') without adding new parameter semantics. Since the schema already explains defaults and behavior, the description adds no extra value, meeting the baseline for high schema coverage.

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 serializes the entire project to JSON with a specific list of included elements (folders, comps, layers, keyframes, effects, shapes, markers, time remap, solids, file refs). This is a specific verb+resource that distinguishes it from siblings like ae_project_info or ae_project_import_json.

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 clearly implies when to use this tool (for full project export) and explains the two output modes (write to path or inline). It does not explicitly name alternatives or state when not to use it, but the 'entire project' scope and inline warning provide sufficient contextual guidance relative to sibling tools.

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