Clicks a button on an open CLO dialog to continue a stopped command, return its result, and leave work-losing choices to the user.
Click a button on the dialog open in CLO (see get_clo_dialog). If a command was stopped by the dialog, it carries on inside CLO and its result is returned here. Decisions that lose work (e.g. "No" to saving changes) are the user's to make.
| Name | Required | Description | Default |
|---|---|---|---|
| button | Yes |
Changes observed during successful MCP inspections.
v0.6.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that a stopped command may continue inside CLO and that its result is returned here. It also warns that decisions losing work are up to the user, which is important for an interaction tool.
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?
Three sentences, each carrying distinct value: the action, the side effect on stopped commands, and the user-responsibility warning. It is front-loaded and contains no filler.
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 no output schema and no annotations, the description provides enough context to call the tool safely: it points to get_clo_dialog for dialog context, states that results are returned, and warns about work-losing decisions. The missing button enumeration is mitigated by that reference, though not fully spelled out.
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% for the single required 'button' parameter. The description adds only that the button is on the open dialog and gives one example ('No'), but it does not enumerate valid button values or explain how an agent should determine them beyond referring to get_clo_dialog.
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 a specific verb and resource: clicking a button on a dialog open in CLO. It explicitly references the sibling get_clo_dialog for discovering the dialog, making the distinction between reading the dialog and acting on it clear.
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?
It gives a clear usage context: use after a dialog is open via get_clo_dialog, and note that stopped commands may resume. It does not spell out when not to use this tool or name explicit alternatives, but the prerequisite is obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.