export_image

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

With no annotations present, the description carries the full burden of disclosing side effects and constraints. It explicitly says the working image is not changed, missing parent folders are created, paths outside allowed regions are refused, and bit-depth defaults vary by format. This is unusually transparent for a tool definition.

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 tight, front-loaded with the core purpose, and every sentence provides distinct value. It moves from the main action to path rules, format mapping, bit-depth defaults, and side effects without repetition or filler.

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?

The description covers path safety, supported formats, bit-depth behavior, and non-mutation of the working image, which is enough to invoke the tool correctly. It does not mention overwrite behavior or what happens on unsupported extensions or failures, and there is no output schema, so a small completeness gap remains.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains how relative file_path is resolved, what absolute paths are permitted, how the extension selects the format, and what bit-depth behavior applies per format. This far exceeds the baseline expected when the schema already documents each parameter.

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 opens with a concrete verb and resource: 'Write an image to a file in the workspace's output or state folder.' It clearly identifies the tool's purpose and even scopes where output may be written)Skip. It does not explicitly distinguish itself from sibling save_preview/save_and_show_preview tools, so it falls short of a full 5.

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 gives detailed path and format constraints but never states when to choose this tool over alternatives such as save_preview or save_and_show_preview. There is no when-to-use / when-not-to-use guidance, so an agent must infer usage from the name and general purpose.

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