production.udim_apply_plan

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

Annotations declare readOnly=false, idempotent=false, destructive=false, and the description supports that by saying assignments are applied to a NEW Candidate and that geometry/weights/morphs/materials are verified as preserved. It adds useful behavior beyond annotations: bounded packing, pixel padding, rotation policy, and an immutability/verification emphasis. It could still clarify whether analysis-only mode exists and what exactly changes in the scene.

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?

It is a single dense sentence with little filler, and the core action and verification clause are front-loaded. The overloaded 'proposal/application' wording and semicolon-joined verification phrase reduce immediate parseability, but it avoids repetition.

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 output schema exists, so return values needn't be described, and annotations already cover the safety profile. However, for a five-parameter mutation-style tool with 0% schema description coverage, the description omits mode/analyze-vs-apply behavior and any parameter mapping, leaving material gaps for correct invocation.

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%, and the description never mentions the five parameters (mode, options, operation, operation_id, relationship). Terms like bounded packing, pixel padding, and rotation likely live inside 'options', but the mapping is left to inference, so the description does not compensate for the undocumented schema.

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 names a specific resource and action: applying explicit tile assignments with bounded packing, pixel padding, and rotation policy to a NEW Candidate, then verifying preservation of geometry/weights/morphs/materials. It clearly conveys the outcome is a new candidate, though it does not explicitly distinguish itself from sibling production.udim_plan and the phrase 'proposal/application' is somewhat ambiguous about whether it plans or mutates.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The mode parameter defaults to 'analyze', but the description does not explain analyze-versus-apply behavior or route agents from udim_plan/uv_pack to this tool; only the words 'proposal/application' imply the context.

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