Skip to main content
Glama
SawatKia

Kanban MCP

by SawatKia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp_kanban_task_manager

Create, update, complete, and organize checklist tasks on Kanban cards. Manage step-by-step tasks within multiple checklists, from creating checklists to batch-adding tasks and syncing completed references.

Instructions

Manage step-by-step tasks (actionable checklist items with isCompleted boolean status) inside a card's checklist (task-list). Hierarchy: Board -> Board Column (List) -> Card -> Checklist (Task-List #1, #2...) -> Tasks (Individual checklist step items). A single card can contain multiple checklists, and each checklist contains multiple step tasks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe ID of the individual task (or checklist ID when deleting a checklist)
nameNoThe name/title of the individual task (or checklist name when creating a checklist)
tasksNoArray of tasks (checklist step items) to create in batch for a card
actionYesThe action to perform: get_all (list tasks on card), create (add a task to card's checklist), batch_create (add multiple tasks), get_one (get task by ID), update (update task name/position/isCompleted), delete (delete task), complete_task (mark task isCompleted: true), sync_referenced_card (mark tasks referencing completed card as done), get_checklists (list all checklists on card), create_checklist (add new checklist to card), delete_checklist (delete a checklist)
cardIdNoThe ID of the card containing the checklist and tasks (or completed card ID when using sync_referenced_card)
boardIdNoThe ID of the board (used with sync_referenced_card to search for referencing tasks across all cards)
positionNoThe vertical sort position of the task within its checklist (default: 65535). Lower numbers = higher up / top, higher numbers = lower down / bottom.
taskListIdNoThe ID of the specific checklist (task-list) containing the tasks
isCompletedNoWhether the task (checklist step item) is completed (true) or pending (false)
checklistNameNoThe name of the checklist to add the task to or create (e.g. 'Checklist', 'Implementation Steps')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.6

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the data model (hierarchy, isCompleted, checklists) and says nothing about side effects of actions, destructiveness, reversibility, permissions, or output behavior. For a multi-action tool with create/delete/sync operations, this is a clear gap.

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 two sentences with no filler. The first sentence states the core purpose immediately, and the second provides essential hierarchy context. Every part earns its place, and it is front-loaded enough for quick scanning.

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

Completeness3/5

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

The description gives the essential hierarchy needed to understand where tasks live, but given the tool's complexity (11 actions, 10 parameters, no output schema, no annotations), it does not cover action semantics or expected results. The schema partially compensates by describing each action, so the description is adequate but not complete.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter already has a description. The tool description adds contextual meaning about hierarchy and the role of isCompleted, but it does not introduce parameter-specific semantics beyond what the schema already provides. The baseline of 3 is appropriate.

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

Purpose4/5

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

The description clearly scopes the tool to managing step-by-step tasks inside a card's checklist, and the hierarchy line reinforces the resource path. It does not explicitly name sibling tools or differentiate from them, but the domain is specific enough that an agent can tell it is for task/checklist items, not cards or lists.

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

Usage Guidelines2/5

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

The description provides no explicit when-to-use guidance or comparison with sibling tools like card_manager or list_manager. The hierarchy implies the task layer, but there is no stated condition for when to pick this tool over alternatives, nor any exclusions or prerequisites.

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

Deploy Server

Other Tools