What can you do with this server?

This MCP server connects to a Vikunja instance and exposes task management operations as typed tools for AI clients like Claude. There is no delete tool by design — tasks can only be created, updated, or toggled, never destroyed. * check_connection: Verify connectivity to your Vikunja instance. With a project ID, confirms task read access; without one, lists all projects the token can see — useful for diagnosing auth/scope issues. * list_tasks: Retrieve tasks from a project (open only by default, or all including completed), sorted by open status → priority → ID. * get_task: Fetch a single task by its global ID, including its full description (converted from stored HTML to markdown). * add_task: Create a new task with optional title, description (markdown), priority (0–5), due date (yyyy-MM-dd), and labels (auto-created if missing). * update_task: Modify specific fields of an existing task (only passed fields change); supports clearing due date or description, and appending to descriptions in chunks for long content. * complete_task: Mark a task as done. * reopen_task: Mark a completed task as not done.

How do I use vikunja-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vikunja-mcp list my open tasks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

vikunja-mcp

by skrimokst

Overview Schema Related Servers Score Discussions

Python

Remote

vikunja-mcp

An MCP server that exposes tasks in a Vikunja instance as typed tools — list / get / add / update / complete / reopen — for Claude Code, Claude Desktop, or any MCP client. Runs locally over stdio (the client launches it as a subprocess). Write-only — there is no delete tool, by design.

The API token comes only from the session environment (never a config file) and the project is mandatory (a default via env, or passed per-call).

Prerequisites

Installation is a couple of uv commands — no OS installer, no background service (the MCP client launches the server on demand). You need three things:

uv — the only hard dependency. It provisions a matching Python (requires-python >=3.11) and installs the deps (mcp, httpx, truststore, markdown) itself, so a system Python/pip is optional. Install it once:
```
winget install astral-sh.uv          # Windows  (or:  irm https://astral.sh/uv/install.ps1 | iex)
```
```
curl -LsSf https://astral.sh/uv/install.sh | sh    # Linux / macOS
```
An MCP client to register the server with — Claude Code or Claude Desktop.
A Vikunja service-account API token (scoped minimally: task read/create/update, project-views + view-tasks read, label read/create) plus your instance URL. With a project ID the token needs no 'read all projects' scope. Share the target project with that account.

The first install (uv tool install or uv sync) needs network access — uv fetches a matching Python and the packages; after that the server runs offline against your instance.

Related MCP server: Tasks MCP Server

Install

Two ways, by intent — use the server, or work on it.

Use it: install as a standalone tool

uv tool install builds the package into an isolated, uv-managed environment and drops a vikunja-mcp launcher on your tool bin dir (%USERPROFILE%\.local\bin on Windows, ~/.local/bin elsewhere). The source is disposable once installed — this is what keeps the server installed with no checkout on the machine. Run uv tool update-shell once to add that bin dir to your user PATH (a permanent, user-scope change), then relaunch your shell so it takes effect — after that the vikunja-mcp launcher resolves by name, with no path needed anywhere.

Install from the git remote — uv clones to a temp dir, builds, and discards it, so the source never lands on disk (note the url form is host/path, not the host:path an SSH remote prints):

uv tool install git+ssh://git@your-git-host/you/vikunja-mcp.git
uv tool upgrade vikunja-mcp                                        # update later (re-fetches the remote)

Two things to get right when installing/upgrading from the remote:

Push first. The build uses the remote's committed state, so git push your work before you install or upgrade — a run before the push silently builds the previous version, not your latest.
Release the launcher first. Before a reinstall/upgrade, make sure nothing is still running the server — quit Claude Desktop especially, since it keeps the vikunja-mcp executable open. A running launcher can't be overwritten, and a half-finished reinstall can leave the tool environment broken (recover by quitting the holders and re-running the install).

…or from a wheel you build yourself, if you'd rather not reach the remote to install or update:

uv build                                                          # -> dist/vikunja_mcp-<ver>-py3-none-any.whl
uv tool install ./dist/vikunja_mcp-<ver>-py3-none-any.whl
uv tool install --reinstall ./dist/vikunja_mcp-<newver>-py3-none-any.whl   # update later

Remove it with uv tool uninstall vikunja-mcp. Upgrades keep the launcher path stable, so the MCP registration below never has to change — just relaunch the client.

Work on it: dev checkout

For hacking on the code, keep the checkout and run out of it — no install, edits take effect live:

cd vikunja-mcp
uv sync            # creates the venv, provisions Python if needed, installs deps
uv run pytest      # optional: run the client tests

Configure (environment only)

Setting	Env var	Notes
Instance URL	`VIKUNJA_URL`	required; the http(s) base URL of your instance
Default project by ID	`VIKUNJA_PROJECT_ID`	optional, preferred; set it per repo (below); no `/projects` lookup → minimal token
Default project by name	`VIKUNJA_PROJECT`	optional; its name→ID lookup needs 'read all projects'
Token	`VIKUNJA_API_TOKEN`	secret — session env only, see below

Token — session env only, never persisted. Set it in the shell/session you launch the MCP client from; the server the client spawns inherits it. Do not put it in .mcp.json. If it's missing, check_connection (and every write) reports the fix and stops.
```
$env:VIKUNJA_API_TOKEN = Read-Host -AsSecureString "Vikunja API token" | ConvertFrom-SecureString -AsPlainText   # PowerShell 7+
```
```
read -rs -p "Vikunja API token: " VIKUNJA_API_TOKEN && export VIKUNJA_API_TOKEN   # bash
read -rs "VIKUNJA_API_TOKEN?Vikunja API token: " && export VIKUNJA_API_TOKEN      # zsh (its -p means coprocess)
```
Each prompts with echo off, so the token never reaches the command line or your shell history. A running client captured its environment at launch, so after setting it you must relaunch it.
Default project is optional; a tool's project_id argument overrides it. Leave it unset if you work across several projects on this machine — then check_connection, list_tasks and add_task take the project per call, and ask you which project to use (prefer the numeric id) when you haven't said. Set a default only if one project dominates, to skip that prompt. get_task, update_task, complete_task and reopen_task need no project at all: a task id is global and identifies the task on its own.

Register with an MCP client

Each setting has one right home, because each changes at a different rate:

Setting	Where	Why there
`VIKUNJA_API_TOKEN`	the shell you launch from	secret; never in any file
`VIKUNJA_URL`	user scope — register the server once	one instance per machine
`VIKUNJA_PROJECT_ID`	per repo — `.claude/settings.json` `env`	differs for every repo

Register the server once, at user scope, with only the URL. For a standalone-tool install, register the launcher by name — this works because uv tool update-shell (above) put its bin dir on PATH; relaunch first if you haven't since. A later uv tool upgrade keeps the launcher name, so this registration never changes on update:

claude mcp add vikunja --scope user --env VIKUNJA_URL=https://your-vikunja-host -- vikunja-mcp

From a dev checkout instead, run it out of the tree — no install needed, but the checkout must stay:

claude mcp add vikunja --scope user --env VIKUNJA_URL=https://your-vikunja-host -- uv run --directory /abs/path/to/vikunja-mcp vikunja-mcp

Then, in each repo whose tasks live in a Vikunja project, name that project in .claude/settings.json — Claude Code applies its env to the MCP servers it spawns, so this adds the default without redefining the server:

{ "env": { "VIKUNJA_PROJECT_ID": "11" } }

Do not put VIKUNJA_PROJECT_ID at user scope: one machine spans several projects, and a global default silently sends every repo's tasks to whichever project you named first. Omit it entirely and the tools ask which project to use — the intended fallback, not a failure. Use .claude/settings.local.json instead if the id shouldn't be committed (it is gitignored).

Prefer a project-scope .mcp.json only if a repo needs a wholly different server (a second instance, say). Scopes do not merge — Claude Code takes the entire entry from the highest-precedence scope (local → project → user), so a project-scope entry must restate command, args and VIKUNJA_URL, or it will lose them. The token is deliberately absent from that file — set it in your shell (above).

Then relaunch Claude and run /mcp (or claude mcp list) to confirm vikunja is connected.

Claude Desktop / cowork — the `.mcpb` bundle

Claude Desktop (and cowork in local mode, which shares Desktop's config) doesn't use claude mcp add; it installs an MCP bundle. A ready-to-build manifest lives in packaging/mcpb/ — see its README for the full build + install steps. In short:

Build the .mcpb with Anthropic's official @anthropic-ai/mcpb CLI (mcpb validate + mcpb pack), so the manifest is schema-checked — not a hand-zipped archive.
Drag it onto Settings → Extensions. It prompts for the URL and token at install; the token field is sensitive, so Desktop keeps it in the OS keychain and injects it at launch. This is the one place the token model differs from the CLI — Desktop has no launching shell to inherit it from — and it still never touches a config file.
cowork remote can reach neither a LAN instance nor your local launcher, so the bundle only works in local mode on the machine where the server is installed.

Verify

Ask Claude to run check_connection. Name a project ("check the Vikunja connection for project 7") and it returns { ready: true, url, project, ... } once a task read succeeds — this verifies exactly the scope list_tasks/add_task need, using only project-scoped permissions. Run it with no project and it returns { ready: true, url, projects: [...] }, listing the projects the token can see — handy for discovering which id to pass. That no-project path uses GET /projects, so a token scoped to specific projects gets a 403 there and the result says to pass a project_id instead (not a broken setup). Either way, { ready: false, issues: [...] } names the specific cause (token / URL / 401 bad-token / 403 missing-scope). Then "list my open Vikunja tasks".

Tools

Tool	Does
`check_connection(project_id?)`	readiness probe. With a project: verifies a task read. Without: lists the projects the token can see (see below)
`list_tasks(project_id?, include_done=false)`	open tasks (or all), sorted open→priority→id
`get_task(task_id)`	one task, including its description (returned as markdown — see below)
`add_task(title, project_id?, description?, priority?, due?, labels?)`	create (priority 0..5; `due` = `yyyy-MM-dd`; `description` markdown; labels created-if-missing)
`update_task(task_id, title?, description?, description_append?, priority?, due?, labels?)`	change only the passed fields; `due=""`/`description=""` clear; `description_append` grows the description (see below)
`complete_task(task_id)` / `reopen_task(task_id)`	mark done / not done

Tasks come back as structured JSON. Priority is 0..5: 0=Unset 1=Low 2=Medium 3=High 4=Urgent 5=DO NOW.

Field	Notes
`id`	global; this is what every `task_id` argument takes
`index`, `identifier`	the per-project number the UI shows (`26`, `TEST-26`) — display only
`project_id`	which project the task is in; the task-id tools take no project, so this is the only way to tell
`title`, `done`, `priority`, `labels`	writable via `add_task`/`update_task`
`due`	`yyyy-MM-dd`; `""` when unset
`done_at`, `start_date`, `end_date`, `created`, `updated`	RFC3339; `""` when unset
`assignees`	usernames, read-only (see below)
`related_tasks`	`{kind: [{id, identifier, title, done}]}` — references only
`reminders`	`[{reminder, relative_to, relative_period}]`
`repeat_after`, `repeat_mode`	seconds; `0` = does not repeat
`description`	`get_task` only — markdown (converted from Vikunja's stored HTML), see above

Everything above rides in the payload Vikunja already sends, so none of it costs an extra request. bucket_id, position, cover_image_attachment_id and reactions are dropped: kanban/UI state with nothing in it for a caller. Unset dates arrive as 0001-01-01T00:00:00Z and are normalized to "", so nothing renders a year-1 timestamp as real.

Only title/description/priority/due/labels are writable; the rest are reported as-is. assignees are usernames rather than ids because a project-scoped token gets 401 on GET /user — it can read the assignees embedded in a task, but cannot look a user up, so an id would be a handle nothing here can resolve. related_tasks is trimmed to references on purpose: Vikunja nests the entire related task, description included, which would put a task's whole body inside every task linking to it.

Descriptions: markdown both ways. Vikunja's description field stores the HTML its WYSIWYG editor produces — HTML is the storage format — but the tools present markdown at both ends. add_task/update_task take markdown and convert it to HTML on the way in; get_task converts the stored HTML back to markdown on the way out. So you read and write the same format. Feeding a description from get_task straight into update_task is safe (it just converts back to HTML). The read-side conversion is a rendering convenience, so unusual editor markup (tables, checkboxes) can come back as slightly rough markdown — expected, not a failure. Note description_append still concatenates on the stored HTML internally, so it stays exact no matter how reads render.

Long descriptions: description_append. Neither this server nor Vikunja limits description length in practice (~1MB round-trips fine). The real ceiling is the calling agent's output budget for a single tool call: the description is text the model has to emit, and an over-long call is truncated before it reaches this server — so the failure looks like the tool erroring, not Vikunja rejecting anything. Writing the text to a file first does not help; that costs the same tokens. Instead, send the first part, then grow it:

add_task(title="Report", description="# Report\n\nOpening.")   -> id 42
update_task(42, description_append="## Findings\n\n...")
update_task(42, description_append="## Conclusion\n\n...")

Vikunja has no append endpoint, so this is a read-modify-write: the chunk is converted to HTML and concatenated onto the stored HTML (which is never re-converted). Each call costs only its own chunk, so a description can grow far past what one call could carry. Split on block boundaries — each chunk is converted as standalone markdown, so a chunk cut mid-block (half a code fence, a split table) converts wrongly and the next chunk cannot repair it.

This MCP server was built with Claude Code.

Available Tools

7 tools

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.

ParametersJSON Schema

Name	Required	Description	Default
`due`	No
`title`	Yes
`labels`	No
`priority`	No
`project_id`	No
`description`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes that labels are auto-created and returns the created task, but no annotations exist and it omits side effects, permissions, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and packs many details in one sentence, but could be more readable with structured lists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers return value and key param constraints, but lacks usage context, error cases, and completeness for all parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds constraints for priority, due format, description format, and label behavior beyond the bare schema types, though project_id remains unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a task', a specific verb and resource, distinguishing it from sibling tools like update_task or complete_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus updating or listing tasks; no prerequisites or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	No

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Full disclosure of behavior: returns {ready: true/false, issues: [...]}, explains the design rationale (proving token works by reading something), and distinguishes between success and failure outputs. No annotations to contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet comprehensive: each sentence serves a purpose. Front-loaded with purpose, followed by parameter details, return format, and usage advice. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is fully complete. Covers purpose, parameter logic, return value structure, and usage context without gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description thoroughly explains the project_id parameter: it overrides the default, is required when no default is set, and why. Adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool verifies server connectivity to Vikunja and reads a project. The verb 'verify' and resource 'Vikunja' are specific, and it is distinct from sibling task tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to run this first if anything seems off, explains when project_id is required, and why no project-less health check exists. Provides clear context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

complete_taskB

Mark a task done. Returns the updated task.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the action and return value. It does not disclose prerequisites, side effects (e.g., whether it checks if task is already done), or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with the action and includes return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks details like default behavior or handling of already-done tasks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not add meaning to the only parameter 'task_id' beyond the schema. Schema coverage is 0%, so the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Mark a task done' and the resource 'task', distinguishing it from siblings like 'add_task', 'get_task', etc. It also mentions the return value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for marking tasks as done but provides no explicit guidance on when to use it versus alternatives like 'update_task' or 'reopen_task'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_taskA

Get a single task by its global id, including its description (HTML).

task_id is the id field, NOT the index/identifier shown in the UI. To act on a task the user named by its UI number (e.g. "HL-12"), list the project and match on identifier/index first, then pass that task's id here.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses that it returns 'description (HTML)', which is beyond the schema. It implies read-only behavior via 'get', though it could explicitly state non-destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus a clarifying note; every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter get tool without output schema, the description fully explains the parameter and return content (including HTML description), leaving no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds critical detail: task_id is the `id` field (not UI index/identifier), and explains how to derive it via list_tasks, fully compensating for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a single task by its global id', which is specific and distinguishes from sibling tools like list_tasks that retrieve multiple tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when not to use this tool directly (when user has UI number) and provides steps to obtain the correct id using list_tasks first, offering clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	No
`include_done`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: default env var usage, open-only filtering, and sorting. It does not mention permissions or pagination, but for a read operation, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with critical info front-loaded. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input semantics and behavior; output schema exists so return values needn't be detailed. Missing pagination info, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning: project_id defaults to env vars, include_done controls done task inclusion. This compensates for the schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists tasks in a Vikunja project, with specific filtering for open tasks unless include_done=true. This distinguishes it from sibling tools like add_task, complete_task, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on default project ID from environment variables and sorting order. However, it doesn't explicitly state when to use this tool versus alternatives like get_task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reopen_taskB

Reopen a completed task (mark not done). Returns the updated task.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description states it returns the updated task but lacks disclosure of side effects, authorization needs, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that efficiently convey the action and result, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-param tool with no output schema, the description provides minimal completeness. It explains the core operation but lacks details on return structure, error handling, or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage; the description does not add any explanation for the task_id parameter, leaving its meaning and constraints undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'reopen' and resource 'task', explicitly indicating it marks a completed task as not done. This distinguishes it from sibling tools like complete_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Only implied context that it is for reopening completed tasks; does not include prerequisites or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`due`	No
`title`	No
`labels`	No
`task_id`	Yes
`priority`	No
`description`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the mutation nature, partial update semantics, and how to clear specific fields (due, description). Adequate given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise and front-loaded, but could be slightly more structured. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides essential behavioral context but lacks details on all parameters and error conditions, given no output schema and no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds value for due and description clearing, but does not explain other parameters like title, labels, or priority.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it updates a task with a read-modify-write pattern, distinguishing it from siblings like add_task (create) and get_task (read).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (update a task) and hints at partial update behavior, but lacks explicit exclusions or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

Seven tools is appropriate for a task management server, covering creation, retrieval, update, completion, reopening, listing, and connection verification. Neither too sparse nor bloated.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
mcp
net.todoist
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
App Automation Workplace & Productivity Project Management
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
acme-todo
com.ritzademo
An MCP server for a simple todo list
Developer Tools App Automation
2

Related MCP Servers

Procrastinator MCP Server
Project Management Workplace & Productivity Communication
mateusjunges
F
license
Not graded
quality
D
maintenance
An OAuth-authenticated MCP server that bridges Claude AI with a task management system, allowing users to list, create, and update tasks through natural language commands.
Updated a year ago (2025-06-25 00:45 UTC)
1
Tasks MCP Server
App Automation Project Management Developer Tools
maxouverzou
F
license
Not graded
quality
D
maintenance
A task management MCP server that provides tools to create, list, complete, and delete tasks using pluggable storage backends. It enables users to interact with their task lists through natural language using MCP-compatible clients like Claude Desktop.
Updated 7 months ago (2026-01-22 01:12 UTC)
Taskwarrior MCP Server
Command Line App Automation Workplace & Productivity
tylyan
A
license
A
quality
D
maintenance
An MCP server that enables AI assistants to interact with the Taskwarrior command-line task management tool. It allows users to list, create, modify, and organize tasks using projects, tags, and annotations through natural language.
Updated 7 months ago (2026-02-02 08:45 UTC)
13
2
MIT
mcp-task-manager
Project Management Workplace & Productivity
zsomtor
A
license
Not graded
quality
D
maintenance
MCP server that wraps a personal task manager REST API, enabling Claude to read and manage tasks via tools like get_tasks and add_task.
Updated 3 months ago (2026-06-11 07:26 UTC)
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/skrimokst/vikunja-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

vikunja-mcp

Prerequisites

Install

Use it: install as a standalone tool

Work on it: dev checkout

Configure (environment only)

Register with an MCP client

Claude Desktop / cowork — the .mcpb bundle

Verify

Tools

Available Tools

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop / cowork — the `.mcpb` bundle