This server lets you manage a personal kanban board (backlog → in_progress → testing → done) backed by SQLite, through typed MCP tools.
Add tasks (add_task): Create a task with a required title and optional description, priority (low/normal/high), and tags. New tasks land in backlog.
List tasks (list_tasks): Retrieve tasks with optional AND-combined filters by status, tag, priority, and whether to include archived tasks.
Get a single task (get_task): Fetch full details of one task by its numeric ID, including archived tasks.
Edit tasks (edit_task): Update a task's title, description, priority, and/or tags — only provided fields change; passing an empty string clears the description; passing tags replaces the entire tag list.
Move tasks (move_task): Move a task to any of the four kanban columns.
Archive tasks (archive_task): Soft-delete a task so it disappears from listings and the board but remains in the database (no hard delete exists).
View the full board (get_board): Get all unarchived tasks grouped by column, always returning all four columns in order, even if empty.
An optional web interface provides a drag-and-drop board UI over the same SQLite database, running alongside the MCP server.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tasks-mcp add a task for weekly report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A personal kanban board as a local MCP server, backed by SQLite. Four columns — backlog → in_progress → testing → done — driven entirely through typed MCP tools: Claude pulls your tasks, adds new ones, edits them, and moves them across the board.
Tasks are never hard-deleted: archiving hides a task from listings but keeps it in the database.
Python 3.11+
uv (recommended, not required — see the venv option below)
Related MCP server: kanban-lite
From this directory:
uv run tasks-mcpThat resolves the environment, installs the single runtime dependency (fastmcp), and serves over stdio — uv even downloads a suitable Python if the machine has none. It is also exactly what an MCP host runs for you (see below).
The tasks-mcp / tasks-mcp-web console scripts exist too, but prefer the python -m tasks_mcp / python -m tasks_mcp.web module form for anything long-running: Windows locks a running .exe, which blocks uv run from refreshing the environment while a server is up.
To install uv itself, see the official installation guide.
# Windows
py -3.13 -m venv .venv
.venv\Scripts\pip install -e .# macOS/Linux
python3 -m venv .venv
.venv/bin/pip install -e .The server is then the tasks-mcp entry point inside the venv (.venv\Scripts\tasks-mcp.exe on Windows, .venv/bin/tasks-mcp elsewhere). Re-run the pip install step after pulling dependency changes.
Add to claude_desktop_config.json (Windows: %AppData%\Claude\, macOS: ~/Library/Application Support/Claude/):
{
"mcpServers": {
"tasks": {
"command": "uv",
"args": ["--directory", "C:\\dev\\mcp-kanban", "run", "python", "-m", "tasks_mcp"]
}
}
}On macOS/Linux use the absolute path to this folder in --directory. If uv is not on the host's PATH, use the full path to the executable (where uv / which uv). Restart the Claude app fully after saving.
If you went with the venv install (Option B), point the config straight at the entry point instead — no args needed:
{
"mcpServers": {
"tasks": {
"command": "C:\\dev\\mcp-kanban\\.venv\\Scripts\\tasks-mcp.exe"
}
}
}(macOS/Linux: "command": "/path/to/mcp-kanban/.venv/bin/tasks-mcp".)
Then try: "add a task to buy milk", "show my board", "move it to testing".
Env var | Default | Meaning |
|
| SQLite database path (parent dir is created) |
|
| Transition policy. |
|
| Bind address for the web view. |
|
| Port for the web view. |
|
| Opt-in: |
Set them via the env key of the MCP config entry if you want a non-default location.
Tool | What it does |
| Create a task (lands in |
| List tasks with optional AND-combined filters: status, tag, priority, |
| Full detail of one task by id (works for archived tasks). |
| Update title/description/priority/tags/link. Omitted fields keep their value; empty-string description or link clears it. |
| Move a task to another column — the kanban action. |
| Soft delete. No hard delete exists. |
| The whole board grouped by column; always all four columns, in order. |
| Open a new terminal resuming a task's linked Claude Code chat. Without a task id it shows an interactive picker (MCP elicitation, rendered by the client). |
| Interactive board browsing in one tool call: chained client-rendered pickers navigate columns and tasks and can move/archive/resume — no model round-trips between steps, so every hop is instant. |
| Start the local web server if needed and open the drag-and-drop board in the default browser. |
A browser UI over the same database, runnable alongside the MCP server (WAL mode makes concurrent access safe). Start it when you want the visual board:
uv run python -m tasks_mcp.web # or .venv\Scripts\python -m tasks_mcp.web with the venv installThen open http://127.0.0.1:8765. Every MCP session (Claude Desktop, Claude Code, ...) is its own process, but they all share the database with this one web view, so it reflects everything live.
To have it always available, run it at login — e.g. a shortcut in shell:startup pointing at .venv\Scripts\pythonw.exe -m tasks_mcp.web (pythonw runs without a console window). There is also an opt-in convenience: set TASKS_MCP_WEB_AUTOSTART=1 in the MCP server's environment and whichever session starts first spawns the board in the background if it isn't running. Drag cards between columns to move them, click a card to edit or archive it, add tasks from the header. The page polls every few seconds, so changes Claude makes through MCP appear on their own.
It exposes the same seven operations as JSON endpoints (/api/board, /api/tasks, /api/tasks/{id}, /api/tasks/{id}/move, /api/tasks/{id}/archive) and is built on the stdlib HTTP server — no new dependencies, no build step. Binds to localhost only by default (TASKS_MCP_WEB_HOST / TASKS_MCP_WEB_PORT to change).
Tasks have an optional link field: a URL or command that reopens the task's context. The built-in use case is parking a Claude Code session — "make a task so I can pick this up tomorrow" — and resuming it later with one paste.
One-time setup. Claude Code doesn't expose the session id to the agent directly, but hooks receive it. If you installed the plugin (see below), skip this — it ships this hook. Otherwise, add a SessionStart hook to ~/.claude/settings.json that writes it where the agent can read it:
{
"hooks": {
"SessionStart": [
{
"hooks": [
{
"type": "command",
"command": "powershell -NoProfile -Command \"$i=[Console]::In.ReadToEnd()|ConvertFrom-Json; New-Item -ItemType Directory -Force -Path (Join-Path $i.cwd '.claude') | Out-Null; Set-Content -Path (Join-Path $i.cwd '.claude\\last-session-id') -Value $i.session_id\""
}
]
}
]
}
}Then teach the agent the convention in ~/.claude/CLAUDE.md:
When I ask you to "park this chat" (save work to continue later):
1. Read `.claude/last-session-id` in the project root — that is this session's id.
2. Call the tasks MCP `add_task` tool with:
- title: what we're in the middle of
- description: enough state and next steps to resume cold
- tags: ["parked"]
- link: "cd <absolute project dir>; claude -r <session-id>"Resuming. Three ways, all opening a new terminal already running claude -r <session-id> in the right directory:
/resume-task in Claude Code — with no arguments it shows an interactive picker of linked tasks (arrow keys, rendered by the CLI via MCP elicitation); with an id or title keyword it resumes directly.
The web board — cards whose link matches the resume shape show a ▶ resume button. (Other links show a ⧉ link copy chip.)
Manually — copy the link and paste it into a terminal.
Resume execution is deliberately narrow everywhere: nothing but the exact cd <dir>; claude -r <session-id> shape is ever launched, rebuilt from parsed parts, and the web endpoint additionally requires a custom header so no cross-origin webpage can trigger it against your localhost server.
This repo is itself a plugin (and its own marketplace): one install brings the MCP server, the three slash commands, and the session-parking hook together. In Claude Code:
/plugin marketplace add stikkeruip/mcp-kanban
/plugin install kanban@mcp-kanban(The plugin is named kanban, not tasks — /tasks is a built-in Claude Code command and plugin names should not shadow built-ins.)
(For local testing before pushing: /plugin marketplace add C:\dev\mcp-kanban then install the same way. claude plugin validate . checks the manifest.)
If you previously registered the server manually, remove it to avoid a duplicate: claude mcp remove tasks. The plugin's hook replaces the manual SessionStart hook from the parking section, and the plugin's server launches via uv --directory ${CLAUDE_PLUGIN_ROOT}, so it needs no per-machine paths.
Plugin commands are namespaced:
Command | Behavior |
| Open the drag-and-drop board in the browser (starts the web server if needed). The board and the chat share one database, so each always sees the other's changes. |
| Interactive board in the terminal: arrow-key pickers for columns and tasks, with move/archive/resume actions. One model turn to start, then every step is instant (elicitation, no model in the loop). |
| Deterministic filters: |
| Hybrid: |
| No args → interactive picker of linked tasks. Id or unique title keyword → resumes directly. |
Prefer un-namespaced /fetch-tasks etc.? Copy commands/*.md to ~/.claude/commands/ instead of installing the plugin — but then the server registration and hook are back to manual setup.
Caveats: claude -r only finds the session from the directory it was created in (that's why the cd is part of the stored command), and if two Claude Code sessions run in the same project simultaneously, the last one to start owns last-session-id — in that case ask the agent to double-check against the newest transcript in ~/.claude/projects/.
Dependencies point inward: mcp → services → storage(interface) + domain.
src/tasks_mcp/
├── domain/ # pure data + rules, zero I/O (Task, Status, Priority, TransitionPolicy)
├── storage/ # TaskRepository interface, SQLite impl, versioned migration runner
├── services/ # TaskService — all business logic, typed exceptions
├── mcp/ # thin, disposable adapter: MCP tools
├── web/ # thin, disposable adapter: JSON API + drag-and-drop board UI
├── wiring.py # shared composition: config → service object graph
└── config.py # env resolution in one placeDesign decisions worth knowing:
Storage is swappable. The service layer codes against the abstract TaskRepository; the SQLite implementation (raw SQL, no ORM) is the only file that knows how a task is stored. WAL mode is on, so a future read-only consumer (e.g. an HTML board view) can read while the server writes.
Schema changes are migrations. A versioned runner applies NNN_*.sql files in order, each in its own transaction, on every startup. Adding a field later = dropping a new 002_*.sql file next to 001_initial.sql. Never a manual ALTER.
Transitions are a policy object. v1 ships FreeTransitionPolicy. A strict linear pipeline is a new class registered in mcp/server.py and selected via TASKS_MCP_TRANSITIONS — zero changes to existing code.
Adapters are disposable. MCP tools and web endpoints alike parse input, call one service method, format output. The web view was added without touching a line beneath the adapter layer — the proof the seams work.
uv sync # create venv with dev deps
uv run pytest # domain, storage, services, MCP protocol, web APIThe service tests run against an in-memory SQLite repository; the MCP tests exercise the wired server through an in-memory MCP client; the web tests hit a live threaded server over real HTTP.
Add a new task to the board. It lands in the 'backlog' column.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional list of labels for filtering, e.g. ["work", "errand"]. | |
| title | Yes | Short name of the task (required, non-empty). | |
| priority | No | One of 'low', 'normal', 'high'. Defaults to 'normal'. | normal |
| description | No | Optional longer free-text detail. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond schema by specifying that the task lands in the 'backlog' column. No annotations are present, so the description carries the burden, and it adequately discloses the default placement behavior.
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?
Two sentences with no redundancy; every word serves a purpose. Front-loaded with core action and placement.
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 a simple creation tool with schema covering all parameters and an output schema present, the description is mostly complete. It lacks error or prerequisite details but covers the essential behavior.
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 the description adds little beyond what the schema already provides for parameters. The 'tags' filtering hint is minor.
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 clearly states 'Add a new task to the board' with specific verb and resource, and distinguishes from siblings like archive_task or move_task by implying creation.
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?
The description clearly implies use for creating new tasks, but does not explicitly contrast with siblings or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a task (soft delete): it disappears from listings and the board but stays in the database. There is no hard delete.
Returns the archived task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the operation is a soft delete, what it affects (listings and board), and that it returns the archived task. However, it does not mention reversibility (whether unarchive is possible) or permission requirements, which would enhance transparency.
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?
The description is extremely concise with three sentences, no unnecessary words, and front-loads the key action. Every sentence adds value: defines the operation, clarifies it is soft delete, and states the return value.
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?
The tool is simple (one parameter), has an output schema, and the description covers the core effect and return. However, it lacks information about whether the operation is reversible or if there are side effects (e.g., on dependent tasks). Given the low complexity, it is mostly complete.
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 parameter task_id. The description does not explain the parameter's meaning, type, or role beyond what the schema provides. Since coverage is low (<50%), the description should compensate, but it fails to add any parameter-specific information.
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 clearly states the verb 'archive' and resource 'task', and explicitly defines it as a soft delete. It distinguishes from siblings by specifying that the task disappears from listings but remains in the database, whereas sibling tools like edit_task, move_task, or delete (not present) have different effects.
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?
No explicit guidance on when to use this tool over alternatives. The description implies usage for hiding tasks without permanent deletion, but does not provide explicit when-to-use or when-not-to-use context relative to siblings like edit_task or move_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a task's title, description, priority, and/or tags.
Only the fields you pass are changed; omitted fields keep their current value. Pass an empty string for description to clear it. Passing tags replaces the whole tag list. To change a task's column, use move_task instead.
Returns the updated task.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| task_id | Yes | ||
| priority | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behaviors: partial updates, clearing description with empty string, replacing tags list, and returning the updated task. While it doesn't mention permissions or rate limits, it covers essential mutation semantics well.
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?
Very concise: three short paragraphs with front-loaded information. Each sentence adds value, no redundancy. The structure is clear and easy to parse.
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?
Covers all necessary aspects: what fields can be edited, how partial updates work, how to clear the description, and that column changes require a different tool. With an output schema present, the return value mention is sufficient.
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 has 0% description coverage, so description must compensate. It explains that omitted fields keep current values, empty string clears description, and passing tags replaces the entire list. This adds crucial meaning beyond the schema's type definitions.
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?
Description clearly states it edits specific fields (title, description, priority, tags) and distinguishes from the sibling tool move_task for column changes. The verb 'edit' combined with resource 'task' and explicit field listing makes the purpose unambiguous.
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?
Explicitly describes partial update behavior ('Only the fields you pass are changed') and provides an alternative tool for column changes ('use move_task instead'). This guides the agent on when to use this tool vs. siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the whole kanban board: unarchived tasks grouped by column.
Always returns all four columns in board order — backlog, in_progress, testing, done — even when empty:
{"columns": [{"status": "backlog", "tasks": [...]}, ...]}Use this to render or summarize the board.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behaviors: always returns four columns in board order, includes unarchived tasks only, shows empty columns, and provides response structure. Could mention idempotency or lack of side effects.
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?
Two concise sentences plus an example JSON. Every sentence adds value. Front-loaded with purpose, then details and usage.
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 parameters and existence of output schema, the description fully covers tool's purpose, return value, structure, and use case. No gaps.
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?
No parameters, schema coverage 100%. Baseline 4 is appropriate as description adds no param info needed.
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?
Description clearly states verb 'Get', resource 'whole kanban board', and specifies content: unarchived tasks grouped by column. Distinguishes from siblings like get_task (single task) or list_tasks (flat list).
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?
Explicitly states use case: 'render or summarize the board'. While it doesn't list when not to use, the sibling context makes alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full detail of one task by its numeric id.
Works for archived tasks too.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds one behavioral trait (archived task support) but does not disclose other aspects like error handling, authentication, or rate limits.
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?
Two sentences, no fluff. The first sentence states the core function, and the second adds a key behavioral note. Efficient and front-loaded.
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?
With an output schema present, return values are covered. The description adequately explains purpose and a key feature (archived tasks). However, it lacks mention of error conditions or prerequisites for a fully complete context.
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%, and the description does not elaborate on the task_id parameter beyond the schema (integer, required). No guidance is given on how to obtain or format the ID.
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 clearly states the tool retrieves full details of a single task by numeric ID, distinguishing it from siblings like list_tasks (listing multiple) or add_task (creating).
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?
The description notes it works for archived tasks, but does not explicitly advise when to use or avoid this tool versus alternatives like list_tasks for multiple tasks or edit_task for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks, optionally filtered. All filters combine with AND.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only tasks carrying exactly this tag. | |
| status | No | Only tasks in this column: 'backlog', 'in_progress', 'testing', or 'done'. | |
| priority | No | Only tasks with this priority: 'low', 'normal', 'high'. | |
| include_archived | No | Also include archived (soft-deleted) tasks. Off by default. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks details on ordering, pagination, limits, or response structure. The description only states basic purpose and filter logic.
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 sentence, front-loaded with purpose and additional filter rule. Efficient and clear, though could include a bit more detail without becoming verbose.
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 4 optional parameters and existence of an output schema, the description covers the essential filtering behavior but misses context like ordering, pagination, or typical usage patterns.
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% with individual parameter descriptions. The description adds value by stating 'All filters combine with AND', which is not in the schema.
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?
Description clearly states 'List tasks, optionally filtered' with specific verb and resource. It does not explicitly distinguish from sibling tools, but the purpose is unambiguous.
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?
Description implies usage with optional filters and notes that filters combine with AND. However, no explicit guidance on when to use this tool versus alternatives like get_board or get_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a task to another kanban column.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Numeric id of the task to move. | |
| target_status | Yes | Destination column: 'backlog', 'in_progress', 'testing', or 'done'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states the basic action. It omits details like permission requirements, reversibility, or whether moving affects task order or subtasks.
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?
The description is a single, front-loaded sentence with no wasted words. Every part is essential, achieving maximum conciseness.
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 a simple operation with a complete schema and existing output schema, the description adequately defines the core function. However, it lacks behavioral context needed for safe use, such as stating side effects or prerequisites.
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?
The input schema already covers both parameters with descriptions (100% coverage). The tool description adds no additional semantic value beyond the schema, meeting the baseline of 3.
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 clearly states the action ('Move') and the resource ('a task to another kanban column'), distinguishing it from sibling tools like add_task or archive_task. However, it could be more precise by specifying that it changes the task's status column.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., edit_task for other changes) or when not to use it. The description lacks context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_taskarchive_taskedit_taskget_boardget_tasklist_tasksmove_taskScored across 7 tools
Each tool has a distinct purpose: adding, archiving, editing, viewing board/getting task/list filtering, and moving. No overlap in functionality.
All tool names follow the verb_noun pattern using snake_case, e.g., add_task, archive_task, move_task. Completely consistent.
Seven tools is well-suited for a kanban task management server, covering all essential operations without being excessive or insufficient.
Core CRUD and board viewing are present. Missing an unarchive tool for soft-deleted tasks, otherwise the surface is complete for basic kanban usage.
Kanban board for teams and coding agents: manage tasks, subtasks, sprints and wiki pages via MCP.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
