Keelen

close_task

Destructive

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

Use this when a task on the board 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; say why in one
line. Pass `superseded_by_pr_number` (or `superseded_by_task_id`) when the
work was genuinely delivered somewhere else — that records verified
provenance 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; deliver or re-plan those separately.

Refuses with 409 while the task is being worked on by a running iteration
(stop the machine first, or wait for it to finish). 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. Check it — if it did not drop,
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.

Prefer this over 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

A5/5.0

Behavior5/5

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

The description goes far beyond the annotations: it explains that the task is marked cancelled with all history preserved, that nothing is deleted despite destructiveHint=true, that reason is recorded on the audit trail, that dependencies keep waiting, that 409/404 responses occur in specific states, and that the call is not idempotent end-to-end due to credential-use state persistence. No contradiction with annotations.

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

Conciseness5/5

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

The description is long but information-dense, and every section earns its place by covering semantics, error behavior, side effects, response interpretation, and usage rationale. The opening sentence front-loads the core purpose, and subsequent paragraphs are structured around distinct behaviors rather than repeating the schema.

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?

Given the tool's complexity, the description is unusually complete: it explains required vs optional parameters, error conditions, side effects, the open_tasks response count, how to verify the close actually happened, and why closing is preferred over leaving stale tasks. Since an output schema exists, the description does not need to enumerate the full response shape.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the parameter-semantics burden. It adds meaningful guidance: reason is REQUIRED, one line, and recorded on the audit trail; superseded_by_pr_number and superseded_by_task_id should be passed when work was genuinely delivered elsewhere to record verified provenance. This is essential context the schema alone does not provide.

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 description states a specific verb and resource: 'Close a task that should not be built' and clarifies the intended meaning with concrete examples ('a duplicate, or work already shipped'). It clearly targets board tasks rather than projects, roadmap items, or requests, so it is distinguishable from sibling tools without opening their schemas.

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 explicitly says when to use the tool: when a task is obsolete because the change landed elsewhere, a sibling task covers it, or the user changed direction. It also gives a when-not condition: a 409 occurs while a running iteration is working on the task, so stop the machine or wait. It even advises preferring this over leaving a dead task on the board.

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.