rad_select_context

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

Annotations already declare it is not read-only but non-destructive and closed-world. The description adds useful sequencing context and the source of frame indices, but does not explain what selecting context changes, whether it persists, or how expected_stop_count affects behavior.

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?

Two direct sentences with no wasted text. The prerequisite statement is front-loaded and easy for an agent to act on.

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?

Output schema exists and annotations cover safety, but the input schema has no parameter descriptions. The description explains the core selection intent and one prerequisite, yet it is not complete enough for all four parameters, particularly expected_stop_count.

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 0%, so the description must carry parameter meaning. It hints at thread_id and frame_index and says frame indices come from rad_get_stack, but session_id and especially expected_stop_count are left unexplained.

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: select a thread and/or stack frame. It also distinguishes the tool's role by tying it to evaluating locals, which differentiates it from siblings like rad_get_stack and rad_evaluate.

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?

Clearly says to use it before evaluating locals and that frame indices come from rad_get_stack. The prerequisite is explicit, though it does not spell out when not to use it or name alternatives beyond the implied sequence.

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