apply_material

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

No annotations provided, so the description carries full burden. It mentions 'blend_file: Open this file first (forces headless)' and 'save_as: Save after applying', which gives some behavioral insight (side effects of file operations and forced headless). However, it doesn't disclose error behavior, return value, or that the tool modifies scene state (mutation). For a tool with no annotations, this leaves significant gaps.

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 one compact paragraph plus a bulleted list for parameters. Every line adds value. The purpose is front-loaded. The only slight inefficiency is the list format being slightly verbose for param descriptions, but it's well-organized and skimmable.

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?

Given 6 parameters, 0% schema coverage, no output schema, and no annotations, the description covers parameter semantics well but lacks behavioral details (e.g., what happens if object_name is missing or preset is invalid, what the return value is). It doesn't mention whether it works with existing materials or replaces them. For a mutation tool with no annotations, it's adequate but incomplete.

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 coverage is 0%, so the description must compensate entirely. It explains all 6 parameters with prose, including valid enum values ('metal, plastic, rubber, glass, wood') for preset, optional RGB/RGBA for color, and side-effect notes for blend_file and save_as. The target parameter is briefly described as '"auto", "live" or "headless"', echoing the schema but clarifying intent. It adds context beyond the schema's bare labels.

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 specific verbs and resources: 'Apply a procedural material preset (metal, plastic, rubber, glass, wood) to a mesh.' It clearly distinguishes from siblings like 'render', 'blender_status', or 'run_script' by focusing on material application. The listed presets also hint at how it differs from generic material 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 implies when to use (applying material preset to a mesh) but provides no explicit guidance on when not to use or alternatives. Siblings like 'run_script' or 'inspect_blend' are different domains, so some implicit differentiation exists, but a clear exclusion or context for choosing this over a more general material tool is missing.

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