kanban.board
Read-only access to GitHub Projects v2 kanban boards so the assistant can inspect your boards mid-conversation.
list_boards— list the boards you track (the configured repository's account plus every project source added on the board); returns each board'sid(needed by the other tools),number,titleandurl.get_board— read one board by itsproject_id(the opaquePVT_…node id fromlist_boards): its Status columns and every issue/PR card, each withnumber,title,state,repo,labelsand thestatus_namecolumn it sits in.board_summary— summarise a board as counts per column plus a total card count; cheaper than the full card list for questions like "where does the work stand?".
All three only read data — there are no tools for moving cards or editing boards.
Allows interaction with GitHub Projects v2 kanban boards, providing tools to list boards, retrieve board details, and generate board summaries.
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., "@kanban.board Summarize the current state of my kanban board."
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.
precursor-kanban
A GitHub Projects v2 kanban board for Precursor — and the reference implementation of a Precursor plugin.
What it adds
One package, three contributions:
A section — sidebar entry, home card, command-palette entry and a
/kanbanroute, with columns derived from each project's Status single-select field, drag-and-drop card moves (updateProjectV2ItemFieldValue), and a card preview showing the issue body, labels and comments plus a jump to the linked Precursor topic. The UI is a built ES module shipped inside this wheel, loaded by the app at runtime.MCP tools — a
kanban.boardserver (list_boards,get_board,board_summary) so the assistant can read your boards mid-conversation.API routes —
/api/github/projects, backing the board.
Remove the package and all three disappear; core keeps no knowledge of them.
Related MCP server: GitHub Projects MCP Server
Install
uv pip install precursor-kanban # into an existing Precursor install
uv tool install "precursor-ai[kanban]" # or alongside the app…or from Settings → Plugins inside the app, which also offers the restart.
Precursor discovers it at startup through the precursor.plugins entry-point
group; no configuration is needed.
Compatibility
The plugin targets two versioned contracts — precursor.plugin_api on the
Python side and @precursor/host on the frontend side. They move independently
of each other and of the host's own version. Its MCP server also runs in the
host's environment, so the plugin and the host must agree on one MCP SDK major.
precursor-kanban | Python contract | Frontend contract | MCP SDK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Requires a Precursor newer than
2026.7.0.precursor.plugin_api— the entire surface this package compiles against — landed on Precursor'smainafter that release, so2026.7.0cannot load this plugin at all. Use a host built frommain, or the next release.From
2026.9.1on, requires a Precursor on MCP 2 (lrivallain/precursor#345). On a host still running MCP 1, the board works but thekanban.boardMCP server can't start.From
2026.9.2on, the browser tab names the open board, but only on a Precursor whose section host hassetPageTitle(lrivallain/precursor#358). It is on Precursor'smainand in the nightly, but not in any release yet, including2026.9.0. It is additive, so on an older host everything works and the tab keeps its old title.
Requirements
Issue associations enabled in Settings → GitHub — the master switch for the whole GitHub surface; the board's endpoints answer 403 without it.
A GitHub repository is optional. When set it contributes its owner's boards, which is all it is ever read for; otherwise add projects from the board's +.
A token carrying the
projectscope (a superset ofread:project), which thereposcope does not imply:gh auth refresh -h github.com -s projectWithout it the board returns a 403 explaining exactly this.
Layout
Path | Role |
|
|
|
|
| ProjectsV2 GraphQL queries (extends core's |
| Board read models |
| The |
| Frontend source — |
| The bundle's own Tailwind utilities (see below) |
| Our declaration of the host SDK we compile against |
| Built frontend, shipped in the wheel (gitignored) |
| Provisions and runs a host to load this plugin into |
| GitHub Copilot app project settings (setup + dev server) |
See Precursor's plugin documentation for the full contract.
Development
make sync # uv sync + npm ci + build the frontend bundle
make check # every gate CI runs
make test # the test suite alone
make build # rebuild the frontend into the Python packageRunning it
A plugin has nothing to run on its own. The section, the routes and the MCP
server only exist inside a host that discovered them through the
precursor.plugins entry point, so seeing the board means running a Precursor
with this working tree installed into it:
make dev-host # provision a host beside this checkout, plugin installed into it
make dev # run its dev stack — Vite HMR + uvicorn --reloadscripts/dev-host.sh clones the host's main into .precursor-host/
(gitignored, disposable), syncs its environment, and installs this repository
into it editable — so Python changes need only a restart and frontend
changes only make build. make dev runs with --port 0, meaning the OS picks
a free port and several checkouts can serve their own board at once; the URL is
in the startup banner. Override the host with PRECURSOR_HOST_REPO,
PRECURSOR_HOST_REF, PRECURSOR_HOST_DIR or PRECURSOR_HOST_EXTRAS.
The host from uv sync is deliberately not what this runs. That one is
resolved from git as a wheel built without its npm step, so it has the backend
and no SPA — enough for the test suite to boot an app, nothing to look at.
On a device that routes packages through a mirror, uv sync --frozen cannot
work here: it downloads the files.pythonhosted.org URLs recorded in uv.lock,
which such devices block, and --index cannot redirect a URL the lockfile
already pinned. The script falls back to uv export + uv pip install, which
keeps the locked versions and their hashes but lets the configured index serve
them; npm ci falls back to npm install --no-package-lock for the same reason.
Neither lockfile is ever written — CI owns both. If the mirror is behind on a
pinned version the plugin's own environment may still fail; the host is set up
first, so make dev works regardless and only make test has to wait.
In the GitHub Copilot app both steps are already wired up in
.github/github-app.yml: Setup env runs on session
create, and Dev Server is one click away. Accept the configuration when the
app offers it.
Four things are worth knowing before changing anything.
The frontend is a build product. src/precursor_kanban/web/ is generated and
gitignored. Without it the backend still advertises the section, the app has
nothing to import, and the section silently doesn't appear — so make sync and
make check both build it for you.
The bundle borrows the host's React. react, react-dom, both JSX runtimes
and @precursor/host are marked external; an import map injected by Precursor
resolves them to its own runtime. That is what keeps a single React on the page.
Bundling our own would give the app two dispatchers and every hook here would
throw — so CI asserts the built bundle still imports them rather than containing
them.
The bundle ships its own Tailwind utilities. Inside the Precursor monorepo
this was free: the host's Tailwind build scanned these sources and its stylesheet
already carried every class they used. Out of tree it cannot — the sources ship
compiled — so web/src/styles.css builds the utilities this plugin needs and
styles.ts injects them. They resolve against the host's theme variables, so the
board stays themed with the app and follows dark mode with it.
Lockfiles are generated by CI, never locally — a corporate mirror rewrites
artifact URLs and downgrades their hashes. Run make hooks once to have that
blocked at commit time.
More detail, including how the test suite pins the host and how to keep the SDK declaration honest, is in CONTRIBUTING.md.
Licence
MIT, same as Precursor.
Available Tools
3 toolsboard_summaryA
Summarise a board as counts per column, plus its total card count.
Cheaper for the model to reason over than the full card list when the question is "where does the work stand?".
Inputs: project_id (required). Returns: object
get_boardA
Read one board: its Status columns and every issue/PR card on it.
``project_id`` is the opaque node id from ``list_boards`` (e.g. ``PVT_…``).
Each card carries its ``number``, ``title``, ``state``, ``repo``, ``labels``
and the ``status_name`` column it sits in.
Inputs: project_id (required). Returns: object
list_boardsA
List the GitHub Projects v2 boards the user tracks.
Covers the configured repository's account when there is one, plus every
project source added on the board. Returns each board's ``id`` (needed by
``get_board``), ``number``, ``title`` and ``url``.
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 3 tools
Each tool has a distinct role: discovering boards, reading a full board, and producing a column summary. Descriptions clarify when to use board_summary vs get_board, so there is no ambiguity.
list_boards and get_board follow a clear verb_noun pattern, but board_summary uses a noun phrase instead. The names remain readable and consistent in domain terminology, but this small deviation makes the set mostly consistent rather than fully uniform.
With three tools, the server is tightly scoped to reading and summarizing Kanban boards. Each tool has a clear purpose, and the count feels appropriate rather than excessive or thin.
The tools cover board discovery, full board retrieval, and aggregate summaries, which is complete for a read-only Kanban workflow. The absence of write operations (create/update/move) is a notable gap if broader board management is expected, but for the stated tracking purpose the surface is sufficient.
Maintenance
Related MCP Connectors
Read and manage your EasyKanban kanban boards: to-do summaries, create, update, and move cards.
Project memory for AI agents: read and keep the user's Listspace boards up to date.
A todo and task board in kanban form, driven from chat with full CRUD.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables users to interact with GitHub's Projects v2 API through natural language for Agile project management, supporting repository details, issue tracking, and project board management operations.35GPL 2.0
- AlicenseAqualityDmaintenanceEnables AI assistants to manage GitHub Projects V2, including items, fields, and views through a standardized interface.176 npm1MIT
- AlicenseBqualityDmaintenanceEnables AI agents to manage kanban boards with tasks, including creating boards, items, moving between columns, and searching.81MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to programmatically manage GitHub Project V2 boards with 100+ tools for issues, fields, workflows, and automation via MCP.1MIT