evaluate_chooser_table_multi

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses that this is a headless-safe pure runtime API requiring no PIE or render, that results are post-filtered with IsA against object_class, and that null entries the engine interleaves are skipped so result_count reflects only real results. These are exactly the behavioral quirks an agent must know to interpret output correctly.

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 key differentiator in the first clause before adding runtime qualifications. The density is high but each claim (headless-safe, IsA filtering, null skipping, defaults) carries information; the trailing 'Returns:' block is slightly verbose but justified since no output schema exists.

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 (table_path, evaluated, result_count, results with object and class paths, fallback_used, column_count), plus runtime requirements and the null/IsA filtering semantics. Nothing needed to call and interpret this tool 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 already 100%, so the baseline is 3, but the description adds real meaning: object_class defaults to /Script/CoreUObject.Object and is never null because results are filtered via IsA, and it explains the null-skipping behavior that affects how results are interpreted. context_object_path is not elaborated beyond its schema text.

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 and resource ('Actually RUN a UChooserTable') and immediately distinguishes scope: 'get EVERY matching result, not just the first: the multi-result mirror of evaluate_chooser_table.' An agent can tell exactly how this differs from its sibling 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?

Gives a clear selection condition: 'what you want when the chooser is meant to select a set,' which implicitly routes single-result needs to evaluate_chooser_table. No explicit when-not or prerequisite list, but the routing is unambiguous.

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