production.material_validate_profile

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

The description explicitly states 'apply=true writes only owned candidate materials', which is a write operation, while the annotations declare readOnlyHint=true. That is a direct contradiction of the safety profile an agent relies on to decide whether a call is safe. The otherwise useful note that 'original slots, images, UVs, geometry and animation remain unchanged' cannot offset a contradictory read-only claim.

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 critical `apply=true` behavior is front-loaded, which is good, but the remainder is a run-on clause mixing abstraction levels ('material plan references for lifecycle calls, explicit channels/profiles, technical QA, controlled lighting and a real visual review'). The density obscures rather than conveys, and several phrases do not parse into actionable requirements.

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 no explanation, but with 7 undocumented parameters, no annotation trustworthiness, and no explanation of what a profile is or what validation produces, the description leaves an agent unable to call this correctly. The lifecycle/QA sentence reads as context for a human reviewer, not as operational guidance.

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% across 7 parameters, so the description must carry the burden and it does not. It clarifies only `apply` (writes candidate materials) and hints at `profile`/`material`; `options`, `definition`, `object_name`, and `material_name` are left entirely unexplained, as is what shape a 'profile' argument takes.

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 name implies validation against a profile, but the description only says 'inspect or propose by default; apply=true writes only owned candidate materials', which describes the mode rather than the validation action. It never states what a 'profile' is or what validation checks, and it does not distinguish this from siblings such as material_validate_pbr, material_validate_graph, or material_apply_profile.

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 second clause ('Use material plan references for lifecycle calls... before acceptance') gestures at workflow context but is a jargon list rather than a when-to-use rule. There is no guidance on when to pick this over material_apply_profile or the other material_validate_* tools, and no stated prerequisites or exclusions.

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