baker_bake_to

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

Annotations already declare readOnlyHint=false with destructiveHint=false, and the description meaningfully supports that: it explains the project's settings and map switches are restored afterwards and that `settings` are temporary extras, which is exactly the non-destructive context an agent needs. It doesn't clarify what happens to the pre-existing target file on disk (overwrite?) or whether the output is registered into the project, which are the remaining behavioral gaps.

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?

Two dense sentences, front-loaded with the action and its output naming behavior, then the restoration guarantee, then the parameter nuance. The path example does real work rather than padding.

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?

An output schema exists, so return values need not be explained, and the description is adequate for a 7-parameter bake tool with only one required argument. The main shortfall is the undefined `baker` selector and no statement of failure modes (e.g. invalid path, unknown map name) before a potentially slow bake runs.

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 0%, so the description carries the burden and largely does: it documents `path` (with a worked example), `maps` with its default ['normals'], the size and `samples` intent, and `settings` with an inline example of {'smoothCage': false}. Only `baker` (integer-or-string selector) and the width/height split are left undiscussed.

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?

States a specific verb+resource: a 'trial bake of selected maps ... into a separate file', with a concrete path-transformation example ('C:/tmp/test.png' → 'C:/tmp/test_normals.png'). It is clear what the tool does, but it never names its nearest sibling (baker_bake) to explain why a caller would pick this over a normal bake, so sibling differentiation is left implicit.

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 word 'Trial' and the restoration guarantee imply this is a safe, non-committal way to preview baking before the real baker_bake, but that comparison is never stated explicitly. There are no exclusions, prerequisites, or named alternatives, so an agent must infer usage from the word 'trial'.

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