A board and a timer are usually two apps, so the task you are billing and the task you are looking at
drift apart within a week. Say "add a task to the nova site board: write the launch email, due Friday, 90
minutes" and the MCP Kanban server creates the board if it does not exist yet, files the task in backlog,
and gives it a short id such as NOVA-1. Ask "what's on the nova board?" or "what's overdue?"
and it answers from the same file. The part that matters for billing is task_start_timer: it
does not start a timer itself, it hands back the exact project and task name for the time tracker's
timer_start, so the hours you log are never a re-typed guess at what the task was called.
claude mcp add kanban -- npx -y @theluckystrike/mcp-kanbanCursor reads the same shape of config from .cursor/mcp.json (or the project-level file),
then restart Cursor:
{
"mcpServers": {
"kanban": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-kanban"]
}
}
}Claude Desktop takes the identical block in claude_desktop_config.json. No account, no
API key: the server runs locally over stdio and writes to
~/.local/share/mcp-servers/kanban/.
A title, an optional project (a new name creates its board, and a partial name that matches exactly one
existing project is used as that project so "the nova board" and "nova" do not fork into two boards), a
column (backlog, todo, doing, review, done by default), a due date, an estimate, a priority and tags. Each
task's id is a short code like NOVA-1 or NOVA-A, base36 of a counter that never
goes backward, so it stays stable once handed out even after the task is done or deleted.
The counter that produces NOVA-1, NOVA-2 and so on lives inside the same JSON
file as the board it numbers, not in a separate sequence file. That is fine for one client talking to one
server process. It stops being fine the moment a second client, a second Claude window, a second machine
on a synced folder, opens the same data directory: a load the counter, add one, save cycle with no lock lets
two processes both read counter 7, both increment it to 8, and both write a task numbered NOVA-8,
so one of the two tasks is silently gone under the same id the other one now owns. The fix already shipped
here is a lock file next to the data file: a writer takes an advisory lock before it reads the counter and
releases it after the save, so a competing writer waits its turn instead of reading a stale number. This is
tested directly, not assumed: two server processes pointed at one data directory fire 40 concurrent
task_add calls at the same board, and the suite asserts that all 40 tasks persist, that every
id is unique, and that the board's counter ends at exactly 41 (one seed task plus 40), not some smaller
number a lost write would have produced.
The practical reason this matters: it is the same failure mode a shared spreadsheet has when two people edit a cell at once, except here the two writers are usually a background agent and you typing in the same chat, both reaching for the board within the same second. Without the lock, the number stamped on your invoice line could be numbering a task nobody remembers adding.
"Start a timer on NOVA-3" calls task_start_timer, which returns the project and task name
to pass straight to the time tracker's timer_start and records the link on the task itself, so
a later "what's still running" or a report knows which board item earned those minutes. There is no shared
process between the two servers and no direct call from one into the other: the kanban server hands back
arguments, and it is the model (or you, reading the response) that makes the second call. That handoff is
the whole point of keeping the two servers separate rather than building a timer into the board: the same
task can also feed task_log_time directly, for minutes you tracked some other way, so
estimate and actual can be compared in the weekly review without ever starting a live timer.
board gives a column-by-column summary with estimate and actual totals and an overdue
count. overdue lists everything past its due date across every board, and takes an
as_of date to check against a day other than today. weekly_review compares what
was planned against what actually got done, and estimate against actual, for a week; the current week is
free, past weeks are Pro. The prompt plan_week turns an open board into a day-by-day plan that
fits the hours you actually have, rather than listing everything at once.
Free covers 3 project boards, 200 open tasks and the default five columns. Pro ($19 once, lifetime) removes both limits, adds custom columns per board, full weekly review history, and estimate-versus-actual reports for every week instead of only the current one. Product page: MCP Kanban.
Yes, and that is the case the id counter is built for. A file lock around the read-increment-save cycle means two server processes writing to one data directory in parallel still hand out unique ids and lose no tasks, which is verified by a test that fires 40 concurrent task_add calls from two processes and checks every id and the final counter.
It requires the time-tracker server to be configured in the same client. task_start_timer only returns the arguments; it does not start anything itself, so without the time tracker installed you get the project and task name back and nothing else happens.
Nothing reuses it. The counter only moves forward, so a deleted NOVA-4 leaves a gap rather than handing NOVA-4 to the next task you add.
On Pro, yes, per board, with columns_set. Tasks sitting in a column you remove move to the first column automatically rather than being dropped.
Plain JSON under ~/.local/share/mcp-servers/kanban/ (or $XDG_DATA_HOME). Nothing is uploaded and there is no account.