get_material

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

With no annotations provided, the description must carry the full burden. The verb 'Read' conveys non-mutating behavior and 'explicit units' hints at return content, but the description does not disclose error behavior, path expectations, or any other side effects. This is adequate but minimal for a read-only tool.

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 description is a single focused sentence with no filler. It front-loads the action and resource while adding a useful qualifier about explicit units. Every word contributes meaning.

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 covers return values, and the description states the core purpose, but the overall entry is thin for a tool with three parameters and zero parameter documentation. It lacks guidance on material_path format or how this tool relates to nearby material-reading siblings, leaving some invocation decisions to inference.

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 does not explain any of the three parameters, including the required material_path. Although the name is somewhat self-explanatory, the description adds no meaning beyond the raw input schema and does not compensate for the missing schema descriptions.

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 uses a specific verb ('Read'), a clear resource ('PBR or physics material parameters'), and a distinctive qualifier ('explicit units'). This clearly distinguishes the tool from creation, binding, and binding-related siblings like create_material, apply_material, and get_material_binding.

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 implies a read/retrieval use case and identifies the material parameter scope, but it does not explicitly state when to choose this tool over related alternatives such as get_material_binding or get_prim_info. There is no when-not-to-use guidance or prerequisite context.

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