create_render_target_2d

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

Goes beyond the annotations (which only cover readOnly/destructive/openWorld/idempotent flags) by disclosing behavior: a black clear color, that the asset is saved, the already-exists short-circuit that ignores width/height/format, and a format-fallback path surfaced via format_warning plus a save_error field. This is substantial behavioral detail a caller needs; the idempotency-shaped repeat behavior is not reconciled with idempotentHint:false but it is not a direct contradiction.

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 first sentence front-loads the action, path, and options, and the already-exists rule follows immediately. The prose 'Returns asset_path, width, height, format and pixel_format' is then duplicated by the full inline Returns block, a small redundancy that keeps it just short of a 5.

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?

Although no formal output schema exists, the description inlines the complete return shape (created, already_exists, saved, width/height/format, pixel_format, format_warning, save_error), covering success, no-op, and failure cases. Combined with annotations covering the safety profile, an agent has everything needed to invoke and interpret the call.

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%, so each parameter (name, width, height, format with its full enum-like list, package_path) is already documented, and the baseline for full coverage is 3. The description adds only the black clear color default and the package_path/name composition, which is marginal additional meaning over the schema.

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 precise verb and resource ('Create a UTextureRenderTarget2D asset') plus the exact target location (package_path/name) and configuration (size, format, black clear color). The '2D' qualifier, combined with sibling tools like create_render_target_2d_array and create_render_target_cube, makes the specific target type unambiguous 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?

Provides meaningful context: it explains that an existing target at that path is returned unchanged with already_exists:true and that width/height/format are then ignored, which tells the agent what happens on repeat calls. It does not, however, name alternatives such as create_render_target_cube or create_render_target_2d_array to route non-2D cases, so no exclusions or sibling comparisons are given.

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