get_material_function_inputs

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' is redundant but harmless. It adds useful behavioral context: the input must be a material function asset, not a function instance, and it documents the exact return payload, which is not covered by an output schema. It stops short of error behavior or rate limits, so not a 5.

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-loads the purpose and then adds the alternative and return shape; the Returns block is justified because no output schema exists. However, the first sentence's field enumeration is partly repeated in the Returns block, so it is efficient but not maximally tight.

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 one-parameter read-only inspection tool, the description supplies the missing return structure, names the sibling alternative, and states the input acceptance constraint. Annotations already cover safety, and nothing essential for calling it correctly appears absent.

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 100% for the single material_function_path parameter, so the schema already explains the expected asset path and example. The description adds no syntax, format, or validation semantics beyond that, so baseline 3 applies.

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 (List) and resource (FunctionInput/FunctionOutput nodes of a UMaterialFunction), enumerates the returned fields, and explicitly distinguishes itself from get_material_function_graph for the whole node graph. An agent can identify the tool without opening schemas.

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?

Explicitly says function instances are not accepted and routes whole-graph inspection to get_material_function_graph, naming the alternative and the condition that selects it. This leaves little to inference.

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