run_test

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

With no annotations provided, the description carries the full burden and meets it by disclosing always-on guardrails, the ensure_environment call, return fields, run_id validation rules, overwrite semantics, and force_docker preference. This is substantial behavioral context beyond the schema.

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 description is dense but every sentence earns its place: purpose, prerequisite, return value, guardrail requirement, run_id validation, and force_docker. It is front-loaded with the core purpose and avoids fluff.

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?

Given the tool's complexity, the description provides a solid high-level picture: what it does, prerequisites, return value, and key constraints. It omits details about some parameters and the exact behavior of guardrails, but the parameter names and defaults plus the output schema cover some of that. It is adequate for an agent to select and invoke the tool.

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 0%, so the description must compensate. It adds meaning for run_id (regex and collision handling), acknowledged_risk alias, and force_docker, but does not explain plan_path, properties, timeout_seconds, generate_html_report, or overwrite beyond the collision note. With eight parameters, this is only partial compensation.

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 states 'Execute a JMX plan' with a specific verb and resource, and further specifies guardrails and streamable JTL output. It distinguishes itself from siblings by noting it calls ensure_environment first and is the execution step in the workflow.

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 clearly implies this is the tool for running JMX plans and even notes the prerequisite of ensure_environment. It does not explicitly name alternative tools or when not to use it, but the context and sibling list make the execution role obvious.

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