robot_list_tests

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

With no annotations, the description carries the behavioral burden; it does disclose the key non-execution guarantee, which is valuable for an agent weighing side effects. However, it does not mention file/path expectations, default workspace behavior, or any failure modes, so behavioral coverage remains partial rather than complete.

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?

One compact sentence with no filler; every phrase ('List', 'test cases, tags, source files, and line numbers', 'without executing them') earns its place. The verb and object are front-loaded, making the intent immediately visible.

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?

The tool is simple and has an output schema, so return values need not be re-described, but the description still lacks parameter semantics and explicit usage guidance for 2 defaults-only parameters. An agent can infer basic behavior from the name and 'without executing,' yet important invocation details (what path/workspace mean, when this is preferable to parsing results) are absent.

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% and the description never discusses the 'path' or 'workspace' parameters, leaving their meaning, relationship, and constraints entirely to the sparse schema field names and defaults. The description also doesn't clarify whether 'path' refers to a file, directory, or suite pattern, so it fails to compensate for the schema gap.

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 ('List') and concrete resource ('Robot test cases, tags, source files, and line numbers'), and adds 'without executing them' to set it apart from execution-oriented siblings like robot_run and robot_dry_run. This makes the tool's intent immediately actionable and differentiates it from robot_list_resources by naming test cases rather than resources.

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 phrase 'without executing them' implies a safe inspection use case and distinguishes it from run/dry_run, but it never names an alternative or states conditions for choosing this tool over robot_parse_results or robot_list_resources. The guidance is therefore implied rather than explicit, leaving the agent to infer selection rules from sibling names.

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