delete_lab

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

With no annotations, the description carries full burden. It discloses the search behavior (case-insensitive, recursive under search_path), the confirm boolean safety mechanism, and the constraint of one lab per call. It does not explicitly state that deletion is irreversible or what happens to associated resources, but provides sufficient operational context for safe use.

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 well-structured, starting with the core purpose, then the workflow, then matching details, then parameter list. All sentences add value, though the parameter bullet points could be slightly more integrated. It is appropriately sized for the tool's complexity.

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 4 parameters and search-delete flow, the description covers the essential aspects: matching semantics, confirm safety, and single-lab constraint. It does not detail error handling (e.g., no match, multiple matches without selection), but the flow is clear. The presence of an output schema reduces the need to describe return values.

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 fully explain parameters. It does so with detailed explanations for name (with examples), search_path (default '/'), selection (for multiple matches), and confirm (set true to actually delete). This adds significant meaning beyond the bare schema definitions.

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 clearly states 'Delete exactly one lab, matched by path OR name substring (case-insensitive).' It specifies the action (delete), the resource (lab), and the unique matching method, distinguishing it from sibling tools like delete_folder, delete_lab_node, etc.

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 outlines a 'Search -> select -> confirm flow,' explaining the multi-step process and the role of the confirm parameter. It notes that only one lab can be deleted per call, but does not explicitly exclude cases like deleting multiple labs or compare to alternatives like edit_lab or move_lab.

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