draw_material_to_render_target_region

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

Goes well beyond the annotations (which only say write/destructive/non-idempotent): it discloses that compositing happens via the material's blend mode, that nothing is cleared/saved/undoable, that render-target contents are GPU-only and need explicit persisting, and that missing targets or non-positive size cause an error with drawn=false. This is exactly the destructive-semantics context an agent needs before calling.

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 and is dense but nearly every clause carries new information (units, defaults, alternates, errors, persistence). It is slightly run-on across the single long sentence, and the Returns block, while useful given no output schema, duplicates part of the sentence.

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?

With no output schema, the description supplies the return shape, and it also covers error behavior, destructive semantics, persistence requirements, coordinate conventions, and sibling disambiguation. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: pixel units, top-left origin, size defaulting to the whole target, and 0-1 UVs. That said, the position/size string-encoding format is not clarified further than the schema already implies.

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?

Names a specific verb (draw) plus resource (a material, as a rectangle, onto a UTextureRenderTarget2D) and pins the scope ('in one canvas pass in the editor world'). It also explicitly distinguishes itself from draw_material_to_render_target (full-target) and draw_texture_to_render_target (texture), so an agent can route without opening any 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?

States the exact condition for choosing it (region pass with position/size) and names both alternatives with the condition that selects each ('For a full-target pass use...; for a texture, ...'). It also flags the persistence follow-ups (create_static_texture_from_render_target, export_render_target), leaving nothing to inference.

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