create_checkpoint

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

With no annotations provided, the description carries the full burden, and it does so well by disclosing the write location, filename format, and the key safety guarantee that the user's own .blend file is not modified or re-targeted. It doesn't discuss overwrite or disk cleanup behavior, but the main behavioral risk is covered.

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 every sentence earns its place: purpose, mechanics, safety, usage timing, and automatic alternative. The most important information is front-loaded and there is no 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?

For a tool with one optional parameter and no output schema, this description is nearly complete: it explains what happens, where, why, and when to use it. It could mention how to verify or restore a checkpoint, but that is reasonably handled by sibling tools like list_checkpoints and restore_checkpoint.

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% for the single label parameter, but the description adds real meaning by showing the label is embedded into the checkpoint filename as <timestamp>_<label>.blend. This connects the parameter to the observable artifact beyond the schema's generic 'Short description' wording.

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 clear verb and resource: save a timestamped checkpoint copy into workspace/checkpoints. It also distinguishes itself from save/save_as by explicitly saying the user's .blend file is never touched or re-targeted, so an agent can tell what this tool is and is not for.

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 gives explicit when-to-use guidance: before applying modifiers, deleting objects, or any multi-step change you might need to back out of. It also names an alternative/automatic path, 'begin_operation makes one automatically', which helps the agent avoid redundant checkpoints.

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