mcpField
M
mcp-server-zuuna

mcp-server-zuuna

Local
github.com/kenzotpProductivity0Updated 5w ago

About mcp-server-zuuna

mcp-server-zuuna connects coding agents to Zuuna kanban boards through the v1 API. Its 73 tools cover board and card work, planning, time tracking, and Git-related records, while code changes remain in the repository.

Key features

  1. 0173 tools for board and card operations
  2. 02Manage sprints, releases, and recurring cards
  3. 03Comments, checklists, and attachments
  4. 04Time tracking and timer controls
  5. 05Record Git events and CI checks
  6. 06Scope-gated tools and destructive-action confirmation

Use cases

  1. 01Let a coding agent review and update board cards
  2. 02Plan sprints and track work time
  3. 03Link commits, pull requests, and CI status to cards

MCP support

Exposes Zuuna v1 API operations as 73 MCP tools, plus five prompts. It can run locally with an API token or use Zuuna's hosted MCP connector.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"kenzotp-mcp-server-zuuna": {
"command": "npx",
"args": [
"-y",
"mcp-server-zuuna"
],
"env": {
"ZUUNA_API_TOKEN": "<ZUUNA_API_TOKEN>",
"ZUUNA_BASE_URL": "<ZUUNA_BASE_URL>",
"ZUUNA_TIMEOUT_MS": "<ZUUNA_TIMEOUT_MS>"
}
}
}
}
Run commandnpx -y mcp-server-zuuna
Environment variables to set
ZUUNA_API_TOKENSecretBearer API token from your Zuuna workspace. Grant only the scopes the agent needs (boards:read + cards:read is enough for a read-only observer).
ZUUNA_BASE_URLZuuna base URL. Defaults to https://app.zuuna.de.
ZUUNA_TIMEOUT_MSPer-request timeout in milliseconds. Defaults to 15000.

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
npmmcp-server-zuuna0.3.0

Tools

73

Saved tool list · updated 2w ago

This tool takes no parameters.

Details

From the project README

mcp-server-zuuna

CI

Agent-native board access for Zuuna — a Model Context Protocol server that lets coding agents (Claude Code, Cursor, Codex) read and work a Zuuna board directly.

Agents work the board. Git keeps it honest.

The agent reads the board via this MCP server, does the work in the repo with its own coding tools, and when the PR merges, a rule on your Zuuna board moves the card. Zuuna provides the interface and the verifiable board truth — the agent writes the code, not Zuuna.

Status

Working and tested, and published on npm (npx -y mcp-server-zuuna) after an auth review of the token model, scopes and tool surface. Run from source (bottom) if you want to hack on it.

Hosted alternative

The same 73 tools are also available with nothing to install: Zuuna runs a hosted MCP connector at app.zuuna.de/mcp (OAuth sign-in, Developer plan). Point Claude Code, Cursor or Codex at that URL directly and skip the token and the npx line below. This package exists for the case that does need a local process: a CI runner, an air-gapped agent, or a workflow that wants a plain bearer token instead of an OAuth sign-in. See Kanban board for AI agents for both routes side by side.

Tools

73 tools, grouped by area. Every tool works with any valid token; the Scopes column lists what else the token must carry. The 8 marked destructive refuse to run without an explicit confirm: true argument.

Identity
ToolMethod + pathScopes
zuuna_meGET /api/v1/menone
Groups
ToolMethod + pathScopes
zuuna_list_groupsGET /api/v1/groupsboards:read
zuuna_list_group_membersGET /api/v1/groups/{groupId}/membersboards:read
zuuna_list_epicsGET /api/v1/groups/{groupId}/epicsboards:read
zuuna_create_epicPOST /api/v1/groups/{groupId}/epicscards:write
zuuna_update_epicPATCH /api/v1/groups/{groupId}/epics/{epicId}cards:write
zuuna_list_group_cardsGET /api/v1/groups/{groupId}/cardscards:read
Boards
ToolMethod + pathScopes
zuuna_boardsGET /api/v1/boardsboards:read
zuuna_boardGET /api/v1/boards/{id}/columns + GET /api/v1/boards/{id}/cardsboards:read, cards:read
zuuna_create_boardPOST /api/v1/boardsboards:write
zuuna_list_columnsGET /api/v1/boards/{boardId}/columnsboards:read
zuuna_list_board_fieldsGET /api/v1/boards/{boardId}/fieldsboards:read
zuuna_create_columnPOST /api/v1/boards/{boardId}/columnsboards:write
zuuna_list_automationsGET /api/v1/boards/{boardId}/automationsboards:read
Cards
ToolMethod + pathScopes
zuuna_cardGET /api/v1/cards/{idOrKey}cards:read
zuuna_list_board_cardsGET /api/v1/boards/{boardId}/cardscards:read
zuuna_search_cardsGET /api/v1/cardscards:read
zuuna_create_cardPOST /api/v1/boards/{boardId}/cardscards:write
zuuna_create_cardsPOST /api/v1/boards/{boardId}/cards ({"cards":[...]})cards:write
zuuna_update_cardPATCH /api/v1/cards/{idOrKey}cards:write
zuuna_move_cardPATCH /api/v1/cards/{idOrKey}cards:write
zuuna_move_card_to_boardPOST /api/v1/cards/{cardId}/movecards:write
zuuna_archive_cardPOST /api/v1/cards/{cardId}/archivecards:write
zuuna_unarchive_cardDELETE /api/v1/cards/{cardId}/archivecards:write
zuuna_delete_card (destructive)DELETE /api/v1/cards/{cardId}cards:write
zuuna_restore_cardPOST /api/v1/cards/{cardId}/restorecards:write
Comments
ToolMethod + pathScopes
zuuna_list_commentsGET /api/v1/cards/{cardId}/commentscomments:read
zuuna_commentPOST /api/v1/cards/{cardId}/commentscomments:write
Checklist
ToolMethod + pathScopes
zuuna_list_checklistGET /api/v1/cards/{cardId}/checklistcards:read
zuuna_add_checklist_itemPOST /api/v1/cards/{cardId}/checklistcards:write
zuuna_update_checklist_itemPATCH /api/v1/cards/{cardId}/checklist/{itemId}cards:write
zuuna_delete_checklist_item (destructive)DELETE /api/v1/cards/{cardId}/checklist/{itemId}cards:write
Relations
ToolMethod + pathScopes
zuuna_list_relationsGET /api/v1/cards/{cardId}/relationscards:read
zuuna_add_relationPOST /api/v1/cards/{cardId}/relationscards:write
zuuna_delete_relation (destructive)DELETE /api/v1/cards/{cardId}/relations/{linkId}cards:write
Attachments

Upload included since ZNA-2170: zuuna_upload_attachment takes a local file path, or base64 bytes plus a filename. List and get still return metadata only, never the bytes themselves.

ToolMethod + pathScopes
zuuna_list_attachmentsGET /api/v1/cards/{cardId}/attachmentscards:read
zuuna_upload_attachmentPOST /api/v1/cards/{cardId}/attachmentscards:write
zuuna_get_attachmentGET /api/v1/cards/{cardId}/attachments/{attachmentId} (metadata only)cards:read
zuuna_delete_attachment (destructive)DELETE /api/v1/cards/{cardId}/attachments/{attachmentId}cards:write
Time tracking
ToolMethod + pathScopes
zuuna_list_card_timeGET /api/v1/cards/{cardId}/timetime:read
zuuna_log_timePOST /api/v1/cards/{cardId}/timetime:write
zuuna_start_timerPOST /api/v1/cards/{cardId}/timetime:write
zuuna_stop_timerPOST /api/v1/cards/{cardId}/timetime:write
zuuna_list_active_timersGET /api/v1/time/activetime:read
zuuna_update_time_entryPATCH /api/v1/time/{entryId}time:write
zuuna_delete_time_entry (destructive)DELETE /api/v1/time/{entryId}time:write
zuuna_import_time_entriesPOST /api/v1/time/entriestime:write
Sprints
ToolMethod + pathScopes
zuuna_list_sprintsGET /api/v1/sprintsboards:read
zuuna_get_sprintGET /api/v1/sprints/{sprintId}boards:read
zuuna_create_sprintPOST /api/v1/sprintscards:write
zuuna_update_sprintPATCH /api/v1/sprints/{sprintId}cards:write
zuuna_add_cards_to_sprintPOST /api/v1/sprints/{sprintId}/cardscards:write
zuuna_remove_card_from_sprintDELETE /api/v1/sprints/{sprintId}/cards/{cardId}cards:write
Recurring cards
ToolMethod + pathScopes
zuuna_list_recurring_cardsGET /api/v1/boards/{boardId}/recurringboards:read
zuuna_create_recurring_cardPOST /api/v1/boards/{boardId}/recurringcards:write
zuuna_update_recurring_cardPATCH /api/v1/recurring/{id}cards:write
zuuna_delete_recurring_card (destructive)DELETE /api/v1/recurring/{id}cards:write
Releases
ToolMethod + pathScopes
zuuna_list_releasesGET /api/v1/releasesboards:read
zuuna_get_releaseGET /api/v1/releases/{releaseId}boards:read
zuuna_create_releasePOST /api/v1/releasesreleases:write
zuuna_update_releasePATCH /api/v1/releases/{releaseId}releases:write
zuuna_delete_release (destructive)DELETE /api/v1/releases/{releaseId}releases:write
Deployments

Observation only: there is no "trigger a deploy" tool, on the hosted connector either (see "Honest scope").

ToolMethod + pathScopes
zuuna_list_deploymentsGET /api/v1/deploymentsboards:read
zuuna_report_deploymentPOST /api/v1/deploymentsdeployments:write
Webhooks
ToolMethod + pathScopes
zuuna_list_webhooksGET /api/v1/webhookswebhooks:manage
zuuna_create_webhookPOST /api/v1/webhookswebhooks:manage
zuuna_update_webhookPATCH /api/v1/webhooks/{id}webhooks:manage
zuuna_delete_webhook (destructive)DELETE /api/v1/webhooks/{id}webhooks:manage
zuuna_test_webhookPOST /api/v1/webhooks/{id}/testwebhooks:manage
zuuna_list_webhook_deliveriesGET /api/v1/webhooks/{id}/deliverieswebhooks:manage
Git on board

Link commits, branches, PRs and CI status to cards. None of these move a card by themselves (see "Honest scope").

ToolMethod + pathScopes
zuuna_link_git_branchesPOST /api/v1/git/branchesgit:write
zuuna_report_ci_checksPOST /api/v1/git/checksgit:write
zuuna_record_git_eventsPOST /api/v1/git/eventsgit:write

Behavioral notes:

  • Errors come back as MCP tool errors with the API's own message (the v1 envelope's message plus status and machine code) — e.g. 409 wip_limit_reached when a HARD WIP limit refuses a move.
  • One request, no retries: 4xx answers are never re-sent. Requests time out after 15 s (configurable) and surface as network errors.
  • Card display keys like ZNA-2001 work anywhere a card is addressed — the v1 API accepts the key as the handle.
  • zuuna_board pages the card list (200 cards per page, the v1 API's own cap) so a big board cannot flood the agent's context. When a page is not the whole board, the response says cardsTruncated: true and carries nextCursor; send it back as cardsCursor to fetch the next page.
  • zuuna_create_card accepts an optional client-chosen idempotencyKey: re-sending the same key after a lost response or a 5xx returns the original card (200) instead of minting a duplicate.
  • zuuna_me also returns a hiddenTools list: every tool this token's scopes hide, each with the scope or scopes that would unlock it (the same boundary the startup scope-gating applies).
  • At startup the server reads its own token's scopes (GET /api/v1/me) and registers only the tools they cover, the same scope gating the hosted connector applies. If that read fails (no network yet, an invalid token) it registers every tool instead and prints one line to stderr saying so; every call is still enforced by the API regardless of what got registered.
  • Five prompts ship alongside the tools (session_start, session_end, triage_board, standup_summary, plan_sprint), starting points for a client that surfaces MCP prompts, not required for using the tools directly.

Setup

You need an API token from your Zuuna workspace. Give it the scopes for what the agent should be allowed to do — a read-only observer needs only boards:read + cards:read.

The server is configured per client via environment variables:

VariableDefaultMeaning
ZUUNA_API_TOKEN— (required)Bearer API token
ZUUNA_BASE_URLhttps://app.zuuna.deZuuna base URL — must be an absolute http(s) URL (invalid values fail at startup); a plain-http value prints a cleartext-token warning to stderr
ZUUNA_TIMEOUT_MS15000Per-request timeout
Claude Code
claude mcp add zuuna \
  -e ZUUNA_API_TOKEN=zk_live_your_token \
  -- npx -y mcp-server-zuuna

or in the project's .mcp.json:

{
  "mcpServers": {
    "zuuna": {
      "command": "npx",
      "args": ["-y", "mcp-server-zuuna"],
      "env": { "ZUUNA_API_TOKEN": "zk_live_your_token" }
    }
  }
}
Cursor

In ~/.cursor/mcp.json (or the project's .cursor/mcp.json):

{
  "mcpServers": {
    "zuuna": {
      "command": "npx",
      "args": ["-y", "mcp-server-zuuna"],
      "env": { "ZUUNA_API_TOKEN": "zk_live_your_token" }
    }
  }
}
Codex

In ~/.codex/config.toml:

[mcp_servers.zuuna]
command = "npx"
args = ["-y", "mcp-server-zuuna"]
env = { "ZUUNA_API_TOKEN" = "zk_live_your_token" }
Run from source
git clone https://github.com/kenzotp/mcp-server-zuuna
cd mcp-server-zuuna && npm install && npm run build

then point the client at the built binary instead of npx:

claude mcp add zuuna -e ZUUNA_API_TOKEN=zk_live_your_token -- node /path/to/mcp-server-zuuna/dist/index.js

The loop

  1. zuuna_board — the agent sees the board and picks a card (or you tell it: "do ZNA-2001").
  2. The agent codes in your repo with its own tools, referencing the card key in commits.
  3. The PR merges — and git truth moves the card: Zuuna's git integration (webhooks/CLI) links the commits and the PR to the card, and a rule on the board (for example "PR merged → move to Done") moves it. Linking works out of the box; the move is one rule you add once under the board's Automations. After that the agent never has to touch the board by hand, and the board cannot drift from the repository.

Guides

Honest scope

There is still no tool that triggers a deploy. zuuna_report_deployment (deployments:write) only records what a pipeline already did (building, succeeded, failed); actually shipping stays with your own CI, not the agent.

There are now three git:write tools, and what they do is narrower than the name suggests:

  • zuuna_record_git_events and zuuna_report_ci_checks attach commit/branch/PR history and CI status to whichever card a smart-commit reference or description names.
  • zuuna_link_git_branches replaces a repo's whole in-flight-branches snapshot in one call.

None of the three moves a card. A card moves only because a board rule matched it (see "The loop" above) or because zuuna_move_card / zuuna_update_card was called directly. Automations themselves stay read-only here too (zuuna_list_automations): no tool creates, edits or disables one. Attachment uploads go through as multipart (ZNA-2170) with the REST route's own limits and errors; no tool ever READS a file's bytes back out.

Development

npm install
npm run lint     # eslint
npm run build    # tsc -> dist/
npm test         # vitest, fully mocked (no network)

Optional live smoke test, strictly read-only (GET /me and GET /boards only — nothing is ever created, moved or commented):

ZUUNA_E2E=1 ZUUNA_API_TOKEN=zk_live_your_token npm run test:e2e

Requires Node.js >= 20.

License

MIT

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.