unarchive_taskRestore an archived task to its original list, or the first available list if the original is gone. Works with task key, URL, or ID.
sol2flow: bring an archived task back into its list (the first list if that one is gone).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task: its key (PRD-12), its URL in the app, or its id | |
| workspace | No | Workspace slug (from list_workspaces). Default: the configured workspace, or your only one |
Changes observed during successful MCP inspections.
v0.0.0-developmentDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=false, destructiveHint=false) and idempotency. The description adds real behavioral value beyond that: it discloses where the task lands (its original list, or the first list if that list is gone), which no structured field states.
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 the key behavior front-loaded and the edge case in a parenthetical. The 'sol2flow:' namespace prefix is slightly extraneous but costs almost nothing in space or comprehension.
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?
For an idempotent, non-destructive restore tool with full annotation coverage and a fully described schema, the description covers the essential gap (restoration target). No output schema exists, so return-value documentation is not required; nothing critical is missing.
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 100%, so both parameters (task's key/URL/id, and workspace slug with default) are fully documented in the schema. The description adds no additional parameter meaning, which is the expected baseline here.
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?
Specific verb ('bring an archived task back') plus a clear resource ('archived task'), and it is the obvious inverse of the sibling archive_task. It does not name that sibling explicitly, so it falls just short of the routing clarity a 5 demands.
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?
Usage is implied by the phrase 'bring an archived task back', which conveys restoring a previously archived task. There is no explicit when-to-use guidance and no stated prerequisites, so it is only minimal viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.