Env

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description adds genuine behavioral context beyond that (doctor 'answers in under a second and mutates nothing', the collision rationale for the checks), but this context is scoped to the doctor operation rather than the tool's mutating start/finish paths, so it only partially covers the tool's 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?

The body is a long prose narrative about historical collisions that consumes most of the text without stating what the tool does or how to invoke it. Only the final short paragraph is actionable, and it addresses doctor rather than the tool itself; the structure is poorly front-loaded for tool selection.

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?

An output schema exists, so return values need not be explained. However, for a six-parameter tool spanning start/env/doctor/finish operations, the description never enumerates or differentiates those operations, so an agent cannot determine what invoking rm_lane_env actually does or which parameter combination triggers which path.

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 100%, so each of the six parameters (env, base, path, repo, force, branch) is already documented in the schema with operation-specific meaning. The description adds no parameter syntax or format detail beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 opens by restating the name ('Env (rm_lane)') and gives only a domain ('the lane lifecycle for concurrent agents and humans') rather than a specific verb+resource for what rm_lane_env itself does. It then spends its substance describing a different operation, `doctor`, which is already a sibling tool (rm_lane_doctor), leaving the tool's own action undefined and indistinguishable from siblings.

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 only explicit when-to-use guidance ('doctor is the one to reach for when something behaves impossibly — a test failing that cannot fail...') points at the doctor path rather than routing between rm_lane_env and its actual siblings (rm_lane_start, rm_lane_finish, rm_lane_heal, rm_lane_doctor). No condition selects rm_lane_env itself, and no exclusions are given.

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