material_create_master

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

With no annotations provided, the description carries the behavioral burden: it discloses what the generated graph contains, and the Args reveal side effects including overwrite deleting/recreating an existing asset, compile forcing a shader compile, and save persisting the package immediately. It does not state behavior when an asset already exists and overwrite=false, but the core behavioral profile is clear.

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 summary, tightly grouped Args with one-line semantics, a KB pointer, and an example. There is no filler or repetition of schema defaults, and the extra length is justified by zero schema descriptions.

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 12-parameter creation tool with no annotations and an output schema, the description is thorough: it covers generated graph nodes, texture wiring next steps, all parameter semantics, and an example. It is incomplete only in resolving the material_name-vs-folder_path path ambiguity and in differentiating itself from the sibling create_material tools.

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?

Because schema description coverage is 0%, the Args section compensates by adding semantic meaning to all 12 parameters: RGBA/scalar types, blend_mode allowed values, and side-effect flags. The only blemish is contradictory path guidance: material_name is described as a bare name while the example passes a full /Game path, which could confuse agents.

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 action ('Create'), a specific resource ('reusable master Material'), and enumerates the generated graph parameters (BaseColor, Metallic, Roughness, EmissiveColor, Opacity). The 'master' qualifier and the texture-wiring pointer distinguish it from generic material creation and instance tools.

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 description clearly anchors usage to creating reusable master materials and explicitly directs agents to material_wire_texture_set for wiring texture assets, which is a concrete alternative. It does not spell out when to prefer create_material or material_create_instance_from_master, so it stops short of full when/when-not coverage.

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