apply_material_to_blueprint

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

Annotations already declare destructive=true, readOnly=false, idempotent=false, but the description adds genuinely non-obvious traits: it does NOT compile and does NOT save (so the agent knows it must persist separately), and already-placed level actors retain their serialized material. It also clarifies that success:true in the echo only means the material loaded and SetMaterial was called, which is exactly the kind of semantics an agent needs.

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 core action, then scopes, caveats, and returns in logical order with useful emphasis markup. It is dense but every sentence carries information; the returns echo could be tightened slightly but is not wasteful.

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 mutation tool with no output schema, the description covers the critical gaps: what the return object contains, what success actually guarantees, that persistence requires a separate save, and how to verify with the sibling getter. Combined with the fully-covered schema and annotations, an agent has everything needed to invoke it correctly.

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%, and the schema itself richly documents each parameter (force's PIE-refusal logic, the blueprint_path alias, slot range-check caveat). The description adds only the 'one slot' framing and otherwise defers to the schema, so the baseline 3 is appropriate.

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 (assign), resource (a material ASSET), and precise scope (one slot of a Blueprint component TEMPLATE, an OWN SCS node, not a placed actor). It explicitly distinguishes itself from the sibling set_mesh_material_color by naming it and clarifying the persistent-vs-runtime distinction, so an agent can tell the two apart without opening either schema.

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?

Names the alternative (set_mesh_material_color) and the condition that separates them (persistent template edit vs runtime dynamic instance), and routes the agent to get_blueprint_material_info for readback. It gives clear positive context but never states an explicit 'do not use this when' case, so it falls just short of a full 5.

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