I fired 92 next_task calls at the Kanzo MCP server, in five bursts of up to 32 at once, and not one task went to two agents. The server is a single 4,934,872-byte binary, and it sat at 4,172 kB of RAM when idle. Then one list_tasks call on a 5,000-task board cost 92,075 tokens, which is the number that changed how I would use it.
Kanzo is an open-source kanban board with a built-in MCP server, written by one developer (emanuele-em) and licensed AGPL-3.0. Version 0.3.0 came out on November 1, and the repo was 8 days old when I tested it on November 2. It gives Claude Code, Codex and any other MCP client one shared task list. In this post I go over how I tested the claim step, what the tool does, three places where it breaks, and what I would do Monday morning. My verdict: use it on one machine today, and don’t trust the safety switches yet.
What do 92 racing claims show?
A shared task list has one job. Two agents ask “what is next?” at the same time, and they must not get the same task. If that breaks, you pay twice for the same work.
I ran five race tests on a 4-core Debian box. A double claim would show as the same task id in two replies. The runs: 8 agents on 8 tasks, 32 on 32, 16 agents on 4 tasks over HTTP sessions (4 got a task, 12 got “Nothing in todo”), then 12 and 24 separate kanzo mcp stdio processes on 12 and 24 tasks. That is 92 calls and zero duplicates, and the slowest answer took 1.555 seconds.
Five runs on four cores is a smoke test, not a proof, and I threw away a sixth because my own script had a bug. I did not read the source for the locking. The data folder holds kanzo.db and kanzo.db-journal, which looks like SQLite. Say “92 calls, 80 tasks handed out, none twice, in my runs” and nothing bigger.
How I measured the Kanzo MCP server
Everything ran on November 2, 2026, on x86_64 Linux. I downloaded v0.3.0 from the GitHub releases page. The tarball is 1,832,572 bytes, and its SHA-256 matched the checksum file next to it. I did not run gh attestation verify.
The repo description says “One 4.5 MB binary, 4.5 MB of RAM”, and the README table says “8 MB with 3,000 tasks”. The Linux binary is 4,934,872 bytes, 4.93 MB in decimal, so the README rounds down about 9%. The idle claim holds, but the 8 MB did not: after about 150 tasks and 100 test sessions my process sat at 11,108 kB, and the peak was 13,356 kB with 5,000 tasks loaded. It was not a fresh process, so read that as a ceiling. Each kanzo mcp stdio process, the one your agent launches, was 4.2 to 4.3 MB.
Tokens come from tiktoken o200k_base, not a Claude tokenizer, so read them as close and not exact. The ten-tool list itself is about 646 tokens. That part is cheap.
To repeat the test, start the board, wire one agent, and open two or three agents on the same repo:
kanzo --version
kanzo --no-open &
claude mcp add kanzo --scope user -- kanzo mcpAsk each agent for the next task and compare the ids.
What Kanzo does, in plain words
You run kanzo and it starts a board at localhost:4242. You use the web page, and agents use kanzo mcp, or the HTTP endpoint at /mcp. An agent calls next_task, the task moves to “doing”, and the reply has the title and description. All of it lives in one folder, ~/kanzo.
There is no account and no login. Sharing is kanzo share on, and other computers join with kanzo join and an address. Export is kanzo export -f json, so you can leave any day.
Why a small team cares. Mettons you have three workers on one TODO.md, say Claude Code, a Codex session and a cron bot. Two of them grab line 14 at the same moment. A text file has no claim step, so nothing stops them. A server that hands out each task once is the missing piece.
The local mode is also not naive. On the default 127.0.0.1 setup, a request with Host: evil.example or Origin: https://evil.example got HTTP 403 on /mcp and on every other path I tried. A bad website in a browser tab can’t poke your board. Good. The repo is worth a look.
Where does it break? Three catches
One: list_tasks has no limit. The schema takes a project and a status, nothing else, and returns every task not done. On my 5,000-task board that was 236,834 characters, or 92,075 tokens. The first 200 tasks cost 3,199 tokens. My titles were synthetic, like “task 1234: refactor module 1234”, so count your own board, but 18 tokens a line is a fair guess. One call on a big board eats almost half of a 200k window.
Two: the human flag is a suggestion. Mark a task “human only” and agents don’t see it in list_tasks or next_task. That part works. But I called update_task on the id of a human-only task and moved it from todo to done. Ids are sequential, like rb8#5110, so they are easy to guess. Then I called delete_task on another task. Its own description says “Can’t be undone”, and the task was gone.
Three: sharing means no auth. After kanzo share on, I connected through the machine’s LAN address with no credentials and created a project and a task. The task text was a fake instruction. When my own agent called next_task, it got that text word for word. The README says it plainly: there are no logins. I tested from the same machine and not from a second computer, so the real network case is untested.
The claim step works. The guardrails around it, I could not find.
Is this just a worse GitHub Issues?
For a team already living in GitHub Issues, probably yes, so don’t switch. I did not run a markdown file through the same race, so I can’t say Kanzo beats a TODO.md. I can say concurrent claiming works here and costs 4 MB.
“One person wrote 93% of it.” True. I counted 154 of 165 commits on November 2, with 781 stars and 2 open issues. A star is a click, not a code review. Bus factor of one is real. AGPL bites if you change it and serve it to other people, and not if you run it inside your own team, as far as I read the license. You can walk away with kanzo export -f json.
“Your token count uses fake titles.” Yes. Count your own board before you believe my 18.
Me, I prefer a tool whose weak points I can name. I only ran Linux x86_64. Browser UI, macOS, Windows, Raspberry Pi and kanzo sync are untested.
What should a small team do Monday morning?
Install it on one dev machine, wire your agents with the claude mcp add line above, and move your TODO.md into the board. Keep it on localhost. That is the part I verified.
Don’t click “Share this board” or run kanzo share on at a coworking space, an office guest network or a coffee shop. Anyone who can reach the port can read and change your board, and the task text lands in your agent’s context. Use Tailscale or an SSH tunnel.
Don’t rely on the human flag, and don’t give agents delete_task for anything you care about. Tell agents to use next_task and not list_tasks once the board is past a few hundred tasks.
I wrote about the same trust gap in MCP Skills: I Tried Them, and Verified Is Not Trusted.
Still unknown: why task creation slowed from 8.8 ms each for the first 500 tasks to about 37 ms each past 2,500. Other jobs ran on the box, so I will rerun it alone first.
