unreal_blueprint_compile_targets

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

Annotations already mark readOnlyHint=true and destructiveHint=false, but the description goes beyond that by specifying exact behavioral constraints: it does not load or compile assets, it only lists aliases that are 'already loaded and listed by their project owner,' and it is disabled by default. These details materially change how an agent should interpret results and prerequisites. No contradiction with annotations.

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?

Three sentences with no filler. The primary action is front-loaded, followed by necessary caveats (disabled by default, eligibility constraints, no authorization). Every sentence earns its place; it is concise yet informative.

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 no-parameter listing tool, the description covers the key aspects: what it lists, that it is safe (no loading/compiling), prerequisites (configuration), and eligibility restrictions. It also hints at the separation between discovery and execution. Since an output schema exists, the description need not explain return values. Nothing essential 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?

The tool has zero parameters, so per the rubric the baseline is 4. There is nothing for the description to add about parameter meaning, and the schema is empty. The description correctly focuses on behavior rather than parameter details.

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 opens with a specific verb and resource: 'List project-approved Blueprint compile aliases' – it clearly states what the tool does and the scope (project-approved). It also distinguishes itself from siblings like unreal_blueprint_compile (which compiles) and unreal_blueprint_compile_preview by emphasizing 'without loading or compiling assets.' No ambiguity.

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 this tool: for discovery of compile aliases without side effects, and it explicitly states 'Discovery does not authorize execution,' hinting that a separate tool is needed for compilation. It also gives a prerequisite (configure locally if disabled). However, it does not name specific alternative tools, so it falls short of a 5.

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