Keelen

Close Task

close_task

Destructive

Close a task that should not be built — a duplicate, or work already shipped.

For a task on the board that is obsolete: the change already landed in
another PR, a sibling task covers it, or the user changed direction. The
task is marked `cancelled` and keeps ALL of its history (acceptance
criteria, QA steps, iterations) — nothing is deleted.

`reason` is REQUIRED and is recorded on the audit trail in one line.
`superseded_by_pr_number` (or `superseded_by_task_id`) records verified
provenance when the work was genuinely delivered somewhere else, instead of
a bare abandon. Closing does NOT claim the content is on the default branch,
so any task that declared a dependency on this one keeps waiting; those are
delivered or re-planned separately.

Refuses with 409 while the task is being worked on by a running iteration
(an in-flight iteration must finish, or its machine must be stopped, before
the close succeeds). A task in another
workspace 404s. Business-level replay guard: closing an already-closed task
changes no task state. The call is not idempotent end to end — an
authenticated request also persists credential-use state.

The response echoes `open_tasks`: how many tasks are still open on the
project, counted after the close commits. A count that did not drop means
the ticket was already closed and this call changed nothing. It is the same
count `project_status` returns, and neither counts a closed task as open.

This is preferable to leaving a dead task on the board: unfinished tasks
count against the project's planning capacity, so stale duplicates quietly
stop new roadmap items from being expanded.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`reason`	Yes
`task_id`	Yes
`project_id`	Yes
`superseded_by_task_id`	No
`superseded_by_pr_number`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes well beyond them: it clarifies the soft-close semantics (marked cancelled, ALL history retained, nothing deleted), the audit-trail recording of `reason`, the 409 in-flight-iteration refusal, the cross-workspace 404, the replay guard, and the subtle end-to-end non-idempotency from persisted credential-use state. That is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the required-parameter constraint are front-loaded, and the paragraphs are information-dense rather than repetitive. It is on the long side, and the closing motivational paragraph about planning capacity could be trimmed, but nearly every sentence carries operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description correctly leverages it by explaining the meaningful return signal (`open_tasks`, how to read an unchanged count, and its equivalence to project_status). Combined with error paths, idempotency nuances, and provenance semantics, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for the non-obvious parameters: `reason` is stated as REQUIRED and audit-trail-recorded, and `superseded_by_pr_number`/`superseded_by_task_id` are explained as verified provenance instead of a bare abandon. `project_id` and `task_id` are left unexplained, but they are self-evident identifiers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource plus the exact subclass of tasks it applies to ('a task that should not be built — a duplicate, or work already shipped'). This clearly separates it from siblings like replan_task, retry_blocked_task, and cancel_roadmap_item, which address different lifecycle states.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use ('obsolete: the change already landed in another PR, a sibling task covers it, or the user changed direction'), a when-not (a task under a running iteration refuses with 409, and cross-workspace tasks 404), and the alternative path ('those are delivered or re-planned separately'). The final paragraph adds the positive reason to prefer closing over leaving a dead task.

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

All Keelen tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.