Vikunja MCP Server

Connect Vikunja to Claude, Cursor or any other MCP client and it stops being a tab you switch to. Security-first MCP server for Vikunja — full API coverage, read-only by default with opt-in write/delete, and just one dependency (the official MCP SDK). The vikunja mcp server is what makes that connection.

What the server does

The available third-party Vikunja MCP servers pull a dozen-plus dependencies from npm at runtime and run inside the agent's container with access to its secrets. This one is the opposite:

• One direct dependency — — the official @modelcontextprotocol/sdk. All HTTP
• One egress point — — every request goes through makeApi() in api.js
• Scoped by default — — read and additive tools are always on (list, get, create
• Secrets from env — , never hardcoded
• No build step — — plain Node ESM, node index.js

Available tools

The toolset is worth reading before you wire it up, because it tells you what the integration is really for:

• list_projects — read
• get_project — read
• list_tasks — read
• list_all_tasks — read
• get_task — read
• list_labels — read
• search_users — read
• list_task_assignees — read
• list_task_comments — read
• list_task_relations — read
• list_task_attachments — read
• list_buckets — read

Credentials and setup notes

Configuration is passed through the environment: VIKUNJA_URL, VIKUNJA_API_TOKEN. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

Installation

The server ships on npm as @eargollo/vikunja-mcp, so your MCP client can launch it on demand — there is no separate build step. Add the server block to your client's configuration, restart it, and the tools register themselves.

Where it fits

Plenty of developer tooling servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Vikunja's toolset — list_projects, get_project, list_tasks and 11 more — is a fair guide to whether it matches your workflow. It is maintained by GitHub Actions; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Worth knowing first

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Vikunja.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.