vikunja-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VIKUNJA_URL | Yes | The http(s) base URL of your Vikunja instance | |
| VIKUNJA_PROJECT | No | Default project name (needs read all projects scope) | |
| VIKUNJA_API_TOKEN | Yes | Vikunja API token (secret, session env only) | |
| VIKUNJA_PROJECT_ID | No | Default project ID (numeric) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_connectionA | Verify the server can reach Vikunja and read a project. project_id overrides the configured default, and is REQUIRED when no default is set — the normal case when several projects are used on one machine. There is no project-less health check by design: proving the token works means reading something, and every alternative route (/projects, /tasks/all) would demand a token scope the task tools themselves never need. Returns {ready: true, ...} when a task READ succeeds, else {ready: false, issues: [...]} with the specific fix (token/URL/project/scope). Run this first if anything seems off. |
| list_tasksA | List tasks in a Vikunja project (open only unless include_done=true). Uses VIKUNJA_PROJECT_ID/VIKUNJA_PROJECT when project_id is omitted. Sorted open-first, then priority (high first), then id. |
| get_taskA | Get a single task by its global id, including its description (HTML). task_id is the |
| add_taskA | Create a task. priority 0..5; due is yyyy-MM-dd; description is markdown; labels are created if missing then attached. Returns the created task. |
| update_taskA | Update a task; only the fields you pass change (read-modify-write). Pass due="" to clear the due date, description="" to clear the description. Returns the updated task. |
| complete_taskB | Mark a task done. Returns the updated task. |
| reopen_taskB | Reopen a completed task (mark not done). Returns the updated task. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a distinct purpose (create, read, update, complete, reopen, list, connect) with no overlap. Descriptions clarify ambiguous fields like task_id vs index, further aiding agent selection.
All tool names follow a strict verb_noun pattern (e.g., add_task, get_task, update_task) using lowercase with underscores. No deviations or mixed conventions.
Seven tools is appropriate for a task management server, covering creation, retrieval, update, completion, reopening, listing, and connection verification. Neither too sparse nor bloated.
Core task lifecycle (CRUD plus complete/reopen) is covered, and the connection check is a helpful addition. Missing a dedicated delete tool is a minor gap, but agents can work around it via updates if a soft-delete field exists.