vikunja-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.2
Disambiguation2/5
The 'vikunja_tasks' tool description claims to handle all task operations, overlapping with many specialized tools like vikunja_task_crud, vikunja_task_assignees, vikunja_task_comments, etc. This creates significant ambiguity about which tool to use for task-related actions, leading to potential misselection.
Naming Consistency3/5
All tools share the 'vikunja_' prefix, but the suffix naming is inconsistent: some use plain nouns (auth, filters, projects), while tasks have a mix of 'vikunja_tasks' and 'vikunja_task_*'. The plural 'tasks' vs singular 'task' adds inconsistency, though overall the pattern is still readable.
Tool Count3/5
With 17 tools, the count is slightly above the typical 3-15 well-scoped range. The duplication due to the overlapping 'vikunja_tasks' tool makes the set feel heavier than necessary, but for a full-featured task management server, 17 tools could be justified if each had a distinct role.
Completeness4/5
The tool surface covers authentication, projects, tasks (with comments, labels, relations, reminders, bulk operations), teams, templates, webhooks, and filters. It addresses most lifecycle operations for the domain, though the redundancy suggests some consolidation could be possible.
Average 2.5/5 across 17 of 17 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool is destructive, read-only, or requires authentication. The description carries the full burden but fails to provide any transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is only one sentence and front-loaded, it is too sparse and lacks meaningful content for a tool with 9 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema, no annotations), the description is extremely incomplete. A tool managing templates needs to explain subcommands, parameter usage, and return values.
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 description does not explain any of the 9 parameters. With 0% schema description coverage, the description should compensate, but it adds no parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the vague verb 'manage', not specifying whether it creates, lists, updates, or deletes templates. It does not distinguish from sibling tools like vikunja_task_crud or vikunja_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. No context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral traits (e.g., idempotency, side effects, permissions). The tool could be destructive or require specific conditions, but nothing is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence, but it sacrifices substance for brevity. It is not verbose, but it fails to provide necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 30 parameters, 22 subcommands, and numerous sibling tools, the description is critically incomplete. It lacks parameter explanations, output schema, and usage context, leaving the agent severely underinformed.
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?
Schema description coverage is 0%, and the description adds no information about the 30 parameters. Parameters like subcommand, id, and filters are left unexplained, making it impossible for an agent to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages tasks with comprehensive operations, but it does not clarify how it differs from specialized siblings like vikunja_task_assignees, vikunja_task_crud, etc. The purpose is vague and overlapping.
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 sibling tools. There is no mention of alternatives or exclusions, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it manages tasks, but does not explain what each operation does, required permissions, side effects, or constraints (e.g., whether deletion is irreversible, or prerequisites like authentication).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be seen as concise, but it omits critical details needed for usage. It is under-specified rather than efficiently documented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 20 parameters, no output schema, and no annotations, the description fails to provide sufficient context. An agent cannot determine required parameters per operation, expected outputs, or error conditions.
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?
Schema description coverage is 0%, meaning the description adds no information about the 20 parameters. The description merely lists operations but does not specify which parameters apply to which operation, their formats, or purpose. This severely hinders correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the operations (create, get, update, delete, list) and identifies the resource as 'individual tasks'. However, it does not differentiate from sibling tools like vikunja_tasks or vikunja_task_assignees, which also deal with tasks. The purpose is clear but not distinct enough contextually.
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 is provided on when to use this tool versus alternatives. For example, the sibling tool 'vikunja_task_assignees' might be better for managing assignees, but there is no mention of when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as mutation, authorization requirements, or side effects. For a tool that can create, update, and delete teams, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but omits critical information. It front-loads the resource but does not earn its place due to lack of useful detail beyond a vague statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, CRUD operations, no output schema), the description is grossly incomplete. It fails to explain subcommands, parameter combinations, member management, or return values.
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 10 parameters with 0% description coverage, and the tool description does not explain any of them. The agent cannot infer what 'id', 'name', 'subcommand', or other parameters do without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage teams and team memberships', which identifies the resource but uses the vague verb 'manage'. It does not specify the scope of operations, nor does it differentiate from sibling tools like vikunja_task_crud or vikunja_labels. The purpose is somewhat clear but lacks specificity.
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 is provided on when to use this tool versus its siblings. The description gives no context about prerequisites, exclusions, or typical use cases for team management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'full CRUD operations,' which implies mutability but does not disclose if operations like delete are destructive, if updates are idempotent, or any auth or rate limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, given the tool's complexity (8 parameters, CRUD operations), it is underspecified and fails to earn its space by omitting crucial usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to use the subcommand enum or which parameters apply to which operation, leaving the agent without sufficient context to invoke the tool correctly.
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 description provides no information about any of the 8 parameters. Schema description coverage is 0%, so the description does not add any meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages task labels with full CRUD operations, which is a specific verb (manage) and resource (task labels). It distinguishes from siblings like vikunja_task_labels by implying this is about the labels themselves, not their assignment to tasks.
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 is provided on when to use this tool versus sibling tools like vikunja_task_labels or vikunja_projects. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists capabilities but does not mention that operations like delete or archive are destructive, require authentication, or have side effects. The description is too high-level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but sacrifices important detail. It could be expanded with structured information about subcommands without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, many subcommands, no output schema), the description is woefully incomplete. It does not explain the subcommand enum, required parameters, or return values, making it hard for the AI to use correctly.
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 schema has 20 parameters with 0% coverage (no descriptions). The description fails to explain any parameters, such as how subcommand selects the action or the meaning of id, projectId, etc. This leaves the AI without crucial context for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages projects with CRUD, hierarchy, and sharing, which matches the subcommand enum. It distinguishes from sibling tools by specifying 'projects', which are a different resource than tasks, buckets, labels, etc. However, it could be more specific about what 'manage' entails.
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 alternatives like vikunja_task_crud or vikunja_bucket. The description does not provide any context about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only mentions basic operations (add, list) but does not disclose whether comments can be edited, deleted, or if there are prerequisites like authentication or existing tasks. The schema's lack of requirement for 'comment' field when operation='comment' further obscures behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is very concise. However, this brevity sacrifices important details about parameters and operation-specific requirements, making it less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to clarify parameter roles for each operation, leading to confusion. For a tool with two distinct actions, more context is needed to ensure correct usage.
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?
Schema coverage is 0%, so description must explain parameters. The description mentions adding comments (implying 'comment' field) and listing (implying 'id' for task), but does not explain 'commentId' parameter, nor that 'comment' is effectively required for 'comment' operation. This leaves critical gaps for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages task comments with two specific operations: adding a comment and listing comments. It distinguishes from sibling tools that handle other task attributes like labels or assignees.
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 vs alternatives. While it is implied for comment management, there are no conditions or exclusions mentioned, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the operations without disclosing side effects, error handling, or permission requirements. For example, it does not state that 'add-reminder' is a write operation or what happens when removing a non-existent reminder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but it is also under-specified. It could be restructured to front-load key information, such as stating that 'id' is the task ID.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is severely incomplete. It does not clarify relationships between parameters, required fields per operation, or return values.
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?
Schema description coverage is 0%, and the description does not explain any parameter. It fails to map operations to required parameters (e.g., that 'add-reminder' requires reminderDate). The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (task reminders) and operations (add, remove, list). It is clear and distinguishes tool from siblings like vikunja_task_crud or vikunja_task_assignees. It could be improved by explicitly stating that the 'id' parameter refers to a task ID.
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 is provided on when to use this tool versus alternatives, nor on prerequisites or exclusions. The description only lists operations without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'manage webhooks' without disclosing behavioral traits like authentication needs or side effects of create/delete operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but under-informative for a tool with 6 parameters and multiple subcommands. It could be more efficient by including key actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description is insufficient. It explains neither the subcommand variants nor parameter dependencies.
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 description adds no meaning beyond the schema. With 0% schema description coverage, the agent gets no help understanding parameters like events, secret, or subcommand options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it manages webhooks for integrating events with external services, which is clear. However, it does not specify that it covers CRUD and list-events subcommands, making it slightly less precise.
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 vs alternatives. The name and sibling tools imply purpose, but explicit differentiation is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies mutation for assign/unassign but does not disclose side effects (e.g., overwrite vs. additive assignment), permission requirements, or idempotency. The 'list assignees' operation is read-only, but the description lumps it with mutations without clarifying behavioral differences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but sacrifices completeness. It front-loads the purpose but lacks detail on behavior and parameters. It could be restructured to include parameter hints without significantly increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description needs to explain return values or results. It does not mention what the tool returns for each operation, error conditions (e.g., invalid task ID), or required pre-existing state (e.g., an authenticated session). For a tool with 3 parameters and explicit operations, the description is incomplete.
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?
Schema description coverage is 0%, and the description only loosely maps to parameters: 'assign users, unassign users, list assignees' corresponds to the 'operation' enum but does not explain the 'id' (task ID?) or 'assignees' (user IDs?) parameters. This leaves ambiguity about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage task assignments: assign users, unassign users, list assignees' clearly specifies the resource (task assignees) and the three distinct operations. While it does not explicitly differentiate from sibling tools like vikunja_task_crud, the tool name and operations provide sufficient clarity.
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?
The description offers no guidance on when to use this tool versus alternatives (e.g., vikunja_task_crud). It does not state prerequisites, such as needing an existing task, or exclude scenarios where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states generic operations but omits critical behavioral details: atomicity of bulk operations, partial failure handling, authentication scoping, or whether updates merge or replace. A bulk tool needs more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, no fluff, but could be restructured to front-load key info. Adequate length but missing critical details, so not perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not cover return values, prerequisites, error handling, or how input parameters map to operations. Insufficient for an agent to reliably invoke.
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?
Schema description coverage is 0% – description adds no explanation for any of the 6 parameters. For example, 'field' and 'value' are cryptic, and 'operation' enum values are not explicitly mapped to the listed operations. Schema structure exists but description fails to clarify usage.
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?
Description states 'Manage bulk task operations: create, update, delete multiple tasks', clearly identifying the verb (manage bulk operations) and resource (tasks). This distinguishes it from siblings like vikunja_task_crud (single task) and vikunja_tasks (list).
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 bulk tool versus the many sibling tools for specific operations (e.g., vikunja_task_labels, vikunja_task_assignees). The description lacks context for choosing between bulk and single operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It lists three operations but fails to explain side effects, error conditions (e.g., what happens if a label doesn't exist, or if removing a label that isn't applied), or idempotency. The description is too minimal to convey expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise. However, it sacrifices clarity by being too minimal. It could be restructured to front-load the task context and clarify parameter usage without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema or annotations, the description should provide sufficient context for correct invocation. It does not explain which parameters are required for each operation (e.g., 'labels' is required for apply and remove but not for list). Additionally, it doesn't mention that label IDs must exist (likely created via 'vikunja_labels'). Incomplete for practical use.
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?
Schema description coverage is 0%, so the description should compensate. It merely lists operations without explaining parameter meaning. For instance, it doesn't specify that 'id' refers to the task ID, or that 'labels' is an array of label IDs relevant only for 'apply-label' and 'remove-label'. The description adds little value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage task labels: apply, remove, list labels' clearly indicates the tool is for operations on task labels. It lists three specific operations. However, it could more explicitly state that it operates on a specific task (via the 'id' parameter) to better distinguish from 'vikunja_labels' which manages labels globally.
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 siblings. For example, it doesn't clarify that this tool associates labels with tasks, while 'vikunja_labels' is for creating/deleting labels themselves. No preconditions or context for each operation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions 'validation' but does not clarify whether operations are destructive, require authentication, or have side effects. The term 'manage' is vague and fails to specify what happens during create, update, or delete actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and does not front-load critical information. While not verbose, it is too terse to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters with an enum of seven actions and no output schema, the description is incomplete. It does not explain what each action does, what parameters are required for each, or what the tool returns. It falls short of providing sufficient context for correct invocation.
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?
Schema description coverage is 0%, meaning the schema provides no parameter details. The description does not explain the 'action' enum values or the structure of the 'parameters' object. It adds no meaning beyond what the schema already conveys.
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's purpose: managing and building advanced filters for tasks and projects, with validation. This distinguishes it from sibling tools like vikunja_tasks or vikunja_projects, as no other tool is dedicated to filters. The verb 'manage and build' combined with the resource 'advanced filters' makes the purpose specific and actionable.
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?
The description provides no guidance on when to use this tool versus alternatives like vikunja_tasks or vikunja_projects. It does not mention prerequisites, exclusions, or criteria for choosing between the seven actions listed in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only gives a vague verb 'Manage'. It doesn't state that connect and disconnect change state, or that status is read-only, or what happens on error.
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?
The single sentence is concise and front-loaded, immediately conveying the tool's purpose and scope. Every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description lacks details about return values, parameter constraints, or subcommand behavior. Given its complexity (3 params, 4 subcommands), the description is incomplete.
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 input schema has no descriptions (0% coverage), and the description does not explain the parameters apiUrl or apiToken. It only lists the subcommand, which is already in the schema as an enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages authentication and lists the subcommands (connect, status, refresh, disconnect). This differentiates it from sibling tools that deal with other entities like projects or tasks.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to connect first) or when to switch between subcommands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behavioral traits such as idempotency, side effects (e.g., whether unrelating is destructive), permissions required, or rate limits. It only lists operations without clarifying behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence). While it is concise, it sacrifices necessary detail. It adequately front-loads the purpose but omits important structural elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, no annotations, and the complexity of task relationships (multiple relation types), the description is severely incomplete. It does not explain how to list relations, what response to expect, or how to properly use the relationship kinds.
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?
Schema coverage is 0%, so the description must compensate. However, it only names operations (relate, unrelate, relations) without explaining how parameters like 'otherTaskId' or 'relationKind' should be used. The meaning of the 'relationKind' enum values is not clarified.
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 uses specific verbs and resource: 'Manage task relationships: relate tasks, unrelate tasks, list relations'. It clearly distinguishes the tool from sibling tools like vikunja_task_assignees or vikunja_task_comments by explicitly naming the domain of task relationships.
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 vs. alternatives. It does not specify prerequisites, conditions, or scenarios where other tools would be more appropriate. The description lacks usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions error handling and dry-run, which are useful behavioral traits. However, it does not disclose whether the tool is destructive (mutates state), permission requirements, or behavior on duplicate imports. Bare minimum but not comprehensive.
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?
A single sentence that front-loads the action and key features. No wasted words; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (3 required), no output schema, and no annotations, the description is too brief. It lacks details on data formatting, error behavior, limits, and return values. An import tool requires more complete guidance.
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?
Schema description coverage is 0%, so the description should add meaning to parameters. It only hints at 'format' (CSV/JSON) and 'dryRun' (dry-run support). Other parameters like 'data', 'projectId', and 'skipErrors' are not explained, leaving the agent to infer from names.
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's function: importing tasks in bulk from CSV or JSON. It also mentions error handling and dry-run support, making the purpose distinct from sibling tools like vikunja_task_bulk which may handle other bulk operations.
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?
The description does not provide guidance on when to use this tool versus alternatives. No exclusions or context is given; it simply states what the tool does without recommending scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes three operations (list-views, list-buckets, move-task) and implies write operations for move-task, but it does not mention permissions, side effects, error conditions, or the effect on task state beyond moving.
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?
The description is extremely concise: two sentences that front-load the core capabilities and provide a helpful example. 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?
Given the tool's complexity (three operations, 6 parameters, no output schema or annotations), the description covers the basics but lacks details like required parameters for each operation, ordering of list operations to get IDs, and error handling. It is adequate but not thorough.
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 schema has 0% parameter description coverage, so the description should compensate. It mentions the operations and projectId implicitly, but does not explain the meaning or requirements of viewId, bucketId, taskId, or position. The agent has to infer parameter roles from the operation names.
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's purpose: list a project's views, list a view's buckets, and move a task into a bucket. It uses specific verbs and resource (buckets) and provides an example ('Backlog -> Review -> Done'), differentiating it from sibling tools that handle tasks, labels, 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 includes a clear usage directive: 'Use this to move a task between kanban columns.' This gives context for when to use the tool, though it does not explicitly mention when to use alternatives or exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vikunja-mcp MCP server](https://glama.ai/mcp/servers/4nm1tsu/vikunja-mcp/badges/card.svg)](https://glama.ai/mcp/servers/4nm1tsu/vikunja-mcp)

Score Badge

Copy to your README.md:

[![vikunja-mcp MCP server](https://glama.ai/mcp/servers/4nm1tsu/vikunja-mcp/badges/score.svg)](https://glama.ai/mcp/servers/4nm1tsu/vikunja-mcp)

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/4nm1tsu/vikunja-mcp'

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