Agents and CI

Last updated 27 October 2026

Your board can be read and worked by an AI agent, and told by your pipeline when a pull request is merged. Both come in with a key, and both follow the rules a hand follows on the wall: the WIP limits, the clock, the history.

In five minutes.

Open your board, then Settings › Agents & CI, and make a key.

Paste the command it shows into a terminal:

claude mcp add --transport http kanbanwall https://kanbanwall.ai/mcp \
  --header "Authorization: Bearer kw_personal_…"

Ask Claude: "What's stuck on my board?"

What you can ask it

The agent sees the board the way a person standing at it does: which cards are where, who is on them, how many days each has been running and whether that is past the team's goal. It can also move work along. Some things teams ask:

"Which cards are over the goal, and who is on them?"
"What did we finish last sprint, and how does our cycle time compare with the one before?"
"Tell me the story of IX-2132: when did it start, where did it wait, was it reopened?"
"Move 1063 to Review."
"Write a card for the flaky login test, on Maya, straight into Implement."
"I just merged the retry-queue branch; mark it."
"2.15.0 went out: make the release and put 1063 and IX-2132 in it."
"What shipped in 2.14.0?"
"Before the stand-up, give me three sentences on what moved since yesterday."

A coding agent can keep the board honest as it works: pick a card, move it to Implement when it starts, and say it was merged when the pull request lands.

The tools

Tool	What it does
`list_boards`	The boards the key opens, and your role on each.
`get_workflow`	The board's stages as `Group › Stage`, which one starts the clock and which stops it, how many cards each holds, the WIP limits and the cycle-time goal; the columns with their lanes and the released column's release boxes; and the colours a card can be.
`list_releases`	The release boxes on the wall, top to bottom: name, whether it is published, and the cards shipped in each.
`list_cards`	The cards on the wall, longest-running first, each with its lane and colour, filtered by stage, lane, person, words or "over the goal".
`get_card`	One card by its key, its lane and colour, with every move it made, when and by whom.
`get_stats`	Per sprint: cards finished, median, 85th percentile and mean cycle time in days, reopens.
`create_card`	A new card, with people by name and a colour, in the tray or straight into a stage.
`move_card`	A card to another stage, another lane, or both; or into a release box. It lands at the foot of that stage's column, of that lane, or of that box.
`set_card_colour`	A card's colour, from the board's palette.
`create_release`	An empty release box at the top of the released column, named the way the team says it (`2.15.0`). One of that name already there is answered, not made twice.
`update_release`	A release box renamed, marked published, or not published after all.
`remove_release`	A release box taken away; its cards stay in the released column, ungrouped.
`mark_merged`	A merged change: its card goes to where the clock stops.
`mark_deployed`	A change in production: its card goes to the released stage, and with a `version`, into the release box of that name, made on the spot if need be.

Stages are named the way the board names them. "Review" means the Review group; "Review › Open" means one stage in it. When a name matches nothing, the answer lists the stages there are, so an agent corrects itself on the next try.

A stage is a step of the workflow; a lane is a subcolumn of a column on the wall, a Backlog split into Core and Mobile, and only a place. Moving a card between lanes of the same stage never starts or stops its clock or counts as a transition. Lanes are named by their exact name or by the id get_workflow gives, and a lane that is not there, or belongs to another stage, is refused with the lanes there are. More in the API docs.

A release is a box in the released column holding the cards that shipped together. Moving a card into one is a move into the released stage; list_releases names the boxes, and a release that is not there is refused with the ones that are. More in the API docs.

Keys

There are two kinds, both made in Settings › Agents & CI.

Key	Opens	Acts as	For
Personal `kw_personal_…`	every board you can open	you, with your role on each board	an MCP client on your own machine
Board `kw_board_…`	that one board	an agent with the name you gave the key	CI pipelines and shared bots

A key is shown once, when it is made; we keep only a hash of it, so a lost key is replaced, never recovered. Revoking one takes effect on the next request. Only an owner of a board can give that board's keys out, and a key can never make another key.

Other MCP clients

The server speaks MCP over HTTP at https://kanbanwall.ai/mcp. Claude Desktop, Cursor, VS Code and any client that reads an mcpServers block take:

{
  "mcpServers": {
    "kanbanwall": {
      "type": "http",
      "url": "https://kanbanwall.ai/mcp",
      "headers": { "Authorization": "Bearer kw_personal_…" }
    }
  }
}

Marking merges from GitHub

Make a board key, save it in the repository as the secret KANBANWALL_TOKEN, and add this workflow. The settings page shows it with your board's id already in place.

Want cards to move to Released when the deploy finishes too, an agent that moves its own card, and the repository's issues on the board? Follow GitHub, end to end.

# .github/workflows/kanbanwall.yml
name: kanbanwall
on:
  pull_request:
    types: [closed]
jobs:
  merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - name: Tell the board
        env:
          KANBANWALL_TOKEN: ${{ secrets.KANBANWALL_TOKEN }}
          BRANCH: ${{ github.head_ref }}
          TITLE: ${{ github.event.pull_request.title }}
          PR: ${{ github.event.pull_request.number }}
          RUN: ${{ github.run_id }}
          REPO: ${{ github.repository }}
        run: |
          jq -n --arg branch "$BRANCH" --arg title "$TITLE" --argjson pr "$PR" \
                --arg id "$REPO-$RUN" --arg repo "$REPO" \
                '{event: "merged", repo: $repo, branch: $branch, pr: $pr, title: $title, id: $id}' |
          curl -sS -X POST https://kanbanwall.ai/api/boards/<board-id>/ci \
            -H "Authorization: Bearer $KANBANWALL_TOKEN" \
            -H "Content-Type: application/json" --data-binary @-

The card is found from what the merge says about itself, in this order:

a tracker key in the branch name: IX-2132-retry-queue, feature/IX-2132;
a card number at the start of the branch: 1063-sync-retry;
the branch named in the merge commit, by the same two rules: "Merge pull request #412 from acme/1063-sync" → card 1063;
a tracker key in the pull request's title: "IX-2132: retry the queue";
an issue the title says it closes: "Retry the queue (fixes #88)" → card #88, or vault#88 when the board gives that repository's cards a prefix (send repo, as the workflow above does, and the board knows which).

The pull request's own number is never used: PR #1063 and card 1063 are numbered separately. The API reference has the rules in full.

When nothing matches, the answer says so and the board is left alone; the build does not fail over it. The id names the delivery, so a re-run of the same workflow moves nothing twice.

Any other CI

It is one request. event is merged, deployed or pr-opened:

curl -sS -X POST https://kanbanwall.ai/api/boards/<board-id>/ci \
  -H "Authorization: Bearer kw_board_…" \
  -H "Content-Type: application/json" \
  -d '{"event":"merged","branch":"IX-2132-retry-queue","pr":412,"id":"build-8812"}'

merged moves the card to the stage where the board's clock stops, so its cycle time is counted from that moment. deployed moves it on to the released stage, and with a "version": "2.15.0" into the release box of that name, which the board makes the first time it hears of it, so a deploy job that knows its version fills the wall's release boxes by itself. pr-opened moves it to Review, for teams that want that too.

How it works

Every change is an ordinary move. What an agent or a pipeline does goes through the same rules as a card dragged by hand. A strict WIP limit refuses it, and the answer says which group is full; the clock starts and stops where the board says it does.
The history says who. A board key writes its own name into the card's history ("GitHub CI"), so the time machine and the card panel show a pipeline's moves as a pipeline's.
A board key stays on its board. It cannot list your other boards, make boards, invite people or change the board's shape; only owners change the workflow.
The same answers everywhere. The MCP tools and the REST endpoints below run the same code, so a script and an agent never see two versions of the board.

REST, for scripts

`GET /api/boards/{id}/cards?stage=&lane=&person=&q=&overGoal=`	the cards on the wall, each with its lane and colour
`GET /api/boards/{id}/cards/{key}`	one card and its history
`GET /api/boards/{id}/workflow`	stages, roles, limits; the columns with their lanes; the colour palette
`POST /api/boards/{id}/cards`	`{ "title", "stage", "people", "number", "colour" }`
`POST /api/boards/{id}/cards/{key}/move`	`{ "stage": "Review" }`, `{ "lane": "Mobile" }`, or both; or `{ "release": "2.15.0" }`
`GET /api/boards/{id}/releases`	the release boxes, with the cards shipped in each
`POST /api/boards/{id}/releases`	`{ "name": "2.15.0" }`
`PATCH /api/boards/{id}/releases/{release}`	`{ "name": "2.15.1", "published": true }`, either or both
`DELETE /api/boards/{id}/releases/{release}`	the box goes; its cards stay
`POST /api/boards/{id}/cards/{key}/colour`	`{ "colour": "pink" }`
`POST /api/boards/{id}/ci`	as above

Every answer is { "ok", "message", "data" }. A refusal is ok: false with a sentence saying why.