production.texture_inspect

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

The description does disclose valuable behavior: default is inspect/propose, writes are limited to 'owned candidate materials', and original slots, images, UVs, geometry and animation are untouched. However, this write-on-apply behavior contradicts readOnlyHint=true, so an agent trusting the annotation could pass apply=true believing the call is non-mutating. The disclosure is helpful in content but conflicts with the structured safety signal.

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?

Front-loaded with the tool name and the critical default/apply distinction, and the non-mutation scope is stated last. The middle sentence is a run-on list of advisories ('lifecycle calls, explicit channels/profiles, technical QA, controlled lighting...') that is dense but still short overall.

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 described. But for a 7-parameter, zero-coverage, dual-mode tool, the description leaves the identity parameters and the options/definition objects opaque, and the safety picture is internally inconsistent with readOnlyHint. An agent can call it only by guessing what material/object_name/definition should contain.

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 meaning. It explains only apply (default inspect vs. write) and gestures at 'profiles' and 'channels' in passing; options, definition, material, material_name and object_name are entirely unexplained, and it is unclear which of material/material_name/object_name selects the target.

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 (inspect textures, propose changes) and explicitly defines the read/write split: 'apply=true writes only owned candidate materials'. That is materially clearer than the bare tool name. It does not differentiate itself from near-siblings such as material_inspect, texture_validate_channels or texture_dependency_report, so it stops short of a 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?

Offers procedural guidance ('use material plan references for lifecycle calls, explicit channels/profiles, technical QA, controlled lighting and a real visual review before acceptance') which implies a workflow context. But it never says when to choose this tool over material_inspect or the texture_validate_* siblings, nor when not to use it. Usage is implied rather than decided.

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