Skip to main content
Glama

draw_texture_to_render_target

Destructive

Draw a texture as a tinted rectangle onto a UTextureRenderTarget2D in one editor canvas pass, alpha-blending over existing GPU pixels without clearing or saving.

Instructions

Draw a texture as a rectangle onto a UTextureRenderTarget2D asset in one canvas pass in the editor world: position and size in render-target pixels from the top-left (size defaults to the whole target), full 0-1 UVs, tinted by color. It alpha-blends over the existing pixels: nothing is cleared, saved or undoable, and render-target contents live on the GPU only, so keep them with create_static_texture_from_render_target or export_render_target. A missing render target or texture is an error; drawn is false, and the call fails, when a width or height that is not positive draws nothing. For a material use draw_material_to_render_target_region.

Returns: { render_target_path: string, texture_path: string, drawn: bool, position: [number], size: [number] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoOptional [w, h] destination size, defaults to render target dimensions
colorNoOptional [r, g, b, a] tint color, defaults to opaque white
positionNoOptional [x, y] destination position, default [0,0]
texture_pathYesAsset path of the UTexture to draw, e.g. /Engine/EngineResources/WhiteSquareTexture
render_target_pathYesAsset path of the destination render target

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: alpha-blend semantics over existing pixels, that nothing is cleared/saved/undoable, GPU-only lifetime, and concrete error/failure conditions (missing target or texture is an error; drawn is false and the call fails for non-positive width/height). None of this is in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, then behavior, then routing, then the return shape. Every clause carries information and there is no filler, though the failure clause ('drawn is false, and the call fails, when a width or height that is not positive draws nothing') is slightly tangled.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating render-target tool with no output schema, the definition supplies the return object shape inline plus error and failure semantics, and the annotations cover the safety profile. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 real meaning beyond the schema: position/size are in render-target pixels measured from the top-left, size defaults to the whole target, UVs are full 0-1, and color is a tint. These coordinate-origin and default semantics are not spelled out in the schema strings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb, resource and target: 'Draw a texture as a rectangle onto a UTextureRenderTarget2D asset in one canvas pass in the editor world.' It distinguishes itself from the material sibling by explicitly pointing to draw_material_to_render_target_region, so an agent can route without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear selection rule ('For a material use draw_material_to_render_target_region') and a workflow note about persisting GPU-only contents via create_static_texture_from_render_target or export_render_target. It does not cover when to prefer the line/text draw siblings, so it stops short of full when/when-not coverage.

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

Deploy Server

Other Tools