Kanboard MCP

What ernestocorona/kanboard-mcp MCP server does

The ernestocorona/kanboard-mcp MCP server connects an MCP client to a Kanboard instance and exposes tools for reading and changing project data. Its operations cover projects, columns, swimlanes, tasks, subtasks, comments, file attachments, categories, and project members. Agents can inspect projects and tasks, create or update work items, assign users, manage board structure, and retrieve overdue or personally assigned tasks.

Project context can be supplied with a numeric project ID or a short project identifier. Several tools can instead resolve the project from a .kanboard.yaml file in the project root. That file can also provide defaults for task fields such as the column, owner, category, and swimlane.

How it works

The ernestocorona/kanboard-mcp MCP server communicates with clients over MCP stdio and calls Kanboard through its JSON-RPC API. It supports two authentication patterns: a personal token that represents the authenticated Kanboard user, and an application token for a service identity such as a bot or CI process. The authenticated identity affects visible projects, task ownership, comments, and user-scoped queries.

Task creation supports both individual requests and JSON-RPC batching. create_tasks_batch accepts between 1 and 100 tasks in one call, but the operation is non-atomic: some tasks can succeed while others fail, so callers should inspect both result arrays. Read requests retry on selected transient HTTP responses, while mutations are not retried. Each request has a timeout, configurable through KANBOARD_TIMEOUT_MS, with a default of 15 seconds.

Setup and configuration

The package is published as @ernestocorona/kanboard-mcp and requires Node.js 22 or later. A direct MCP client configuration can run it with:

{
  "command": "npx",
  "args": ["-y", "@ernestocorona/kanboard-mcp"],
  "env": {
    "KANBOARD_URL": "https://kanboard.example.com",
    "KANBOARD_USERNAME": "your-login",
    "KANBOARD_API_TOKEN": "your-token"
  }
}

KANBOARD_URL, KANBOARD_USERNAME, and KANBOARD_API_TOKEN identify the Kanboard endpoint and credentials. The server can also run from the published multi-architecture Docker image on GHCR, or from a source checkout after building the project. It is ESM-only. The selftest command checks the server version, authentication, and visible projects.

Tools and capabilities

The available tools include:

• List projects, project users, categories, columns, swimlanes, tasks, subtasks, and overdue work.
• Create, update, move, close, reopen, and permanently delete projects and work items where supported.
• Create up to 100 tasks in a batch and report per-task failures.
• Add, edit, and remove comments, plus upload or delete task attachments.
• Add project members with a role and reorder columns or swimlanes.

Attachments accept either a local file path or inline Base64 content, but not both, and are limited to 5 MB. Closed tasks remain preserved and can be reopened; deletion is a separate permanent operation.

Limitations and notes

Destructive operations require an explicit confirm: true value and cannot be undone through the server. This applies to deleting projects, tasks, subtasks, columns, swimlanes, comments, and task files. Batch task creation can leave partial results after an error. Some queries depend on Kanboard permissions: listing visible projects only returns projects the authenticated user can access, and listing all overdue tasks requires an administrator token.

The server does not retry mutations, so callers should avoid automatically repeating a write after an uncertain network failure without checking the result. MCP clients must keep the process stdin connected when using stdio; Docker runs require the interactive stdin flag. Logs use structured output with secret redaction, but credentials should still be provided through environment configuration rather than task prompts.