Evaluate agent

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

Adds substantial behavior beyond the sparse annotations: discloses runtime duration (30s–30min), the dual execution model (task-capable clients get a pollable task handle; others block), and the internal sequence of operations (preview cost → run simulation → wait → return scores). This is exactly the kind of context annotations cannot convey.

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 tightly packed sentences, front-loaded with purpose and runtime expectation before parameter guidance. Every clause earns its place with no filler.

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 long-running, potentially blocking operation, the description covers runtime, client-dependent execution model (critical for avoiding timeouts), the internal workflow, and required inputs. Nothing essential for correct invocation is missing despite the absence of an output schema.

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 all four parameters are already documented in the schema. The description calls out timeout_minutes's override semantics and its 1–240 range, which mirrors the schema, and adds no new meaning for num_runs or the uuids. Baseline 3 applies.

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+resource ('Runs an agent against a scenario and evaluates the result end to end'), and distinguishes itself from siblings like preview_run_cost and get_run_details by covering the full execute-then-evaluate flow. An agent can immediately tell this is the end-to-end evaluation entry point.

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?

Implies usage by stating the required inputs ('Give it an agent uuid and a scenario uuid') but never explicitly says when to use this vs. preview_run_cost or get_run_details, nor when-not to use it. Context is implied rather than stated.

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