Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Vikunja MCP Server 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.
A Model Context Protocol (MCP) server that enables AI assistants to interact with Vikunja task management instances.
Subcommand-based tools for intuitive AI interactions
Session-based authentication with automatic token management
Full task management operations implemented
Complete project management with CRUD operations
Label management for organizing tasks
Team operations for collaboration (get/update/members limited by API)
User management with settings and search
Webhook management for project automation
Batch import tasks from CSV or JSON files
Input validation for dates, IDs, and hex colors
Efficient diff-based updates for assignees
TypeScript with strict mode for type safety
Comprehensive error handling with typed errors and centralized utilities
Production-ready retry logic with opossum circuit breaker for resilience
Enhanced security with Zod-based input validation and DoS protection
Rate limiting protection against DoS attacks with configurable limits
Memory protection with pagination limits and usage monitoring
Simplified architecture with 90% code reduction for maintainability
Related MCP server: vikunja-mcp
This release represents a massive architectural simplification that eliminates technical debt while enhancing security and reliability:
Before: 33 files, 9,803 lines of over-engineered storage system
After: 4 files, essential functionality only
Eliminated: Complex orchestrators, health monitors, statistics tracking, migration systems
Result: Same external API with dramatically improved maintainability
Before: Custom tokenizer, parser, and validator with security vulnerabilities
After: Secure Zod schema validation with production-ready parsing
Enhanced: DoS protection, input sanitization, and comprehensive error handling
Result: Faster parsing, better security, and enterprise-grade reliability
Before: Custom retry logic with maintenance overhead
After: Battle-tested opossum circuit breaker library
Features: Circuit breaker state sharing, automatic recovery, comprehensive monitoring
Result: Production resilience with battle-tested patterns
All improvements maintain 100% backward compatibility with existing implementations while providing enhanced reliability and security.
Node.js 20+ (LTS versions only)
Vikunja instance with API access
API token (starting with tk_) or JWT token for authentication
The easiest way to use vikunja-mcp is through npx in your Claude Desktop or other MCP-compatible client configuration:
{
"vikunja": {
"command": "npx",
"args": ["-y", "@democratize-technology/vikunja-mcp"],
"env": {
"VIKUNJA_URL": "https://your-vikunja-instance.com/api/v1",
"VIKUNJA_API_TOKEN": "your-api-token"
}
}
}For development or customization:
git clone https://github.com/democratize-technology/vikunja-mcp.git
cd vikunja-mcp
npm install
npm run buildThen configure your MCP client:
{
"vikunja": {
"command": "node",
"args": ["/path/to/vikunja-mcp/dist/index.js"],
"env": {
"VIKUNJA_URL": "https://your-vikunja-instance.com/api/v1",
"VIKUNJA_API_TOKEN": "your-api-token"
}
}
}The server includes a structured logging system. Configure it via environment variables:
# Enable debug logging (default: false)
DEBUG=true
# Set specific log level (error, warn, info, debug)
# If not set, defaults to 'info' (or 'debug' if DEBUG=true)
LOG_LEVEL=debugLog output includes timestamps and log levels:
[2025-05-25T17:00:00.000Z] [INFO] Vikunja MCP server started
[2025-05-25T17:00:00.100Z] [DEBUG] Executing tasks tool { subcommand: 'list', args: {...} }All logs are written to stderr to keep stdout reserved for MCP protocol communication.
The Vikunja MCP server supports two authentication methods, each with different capabilities:
API tokens are the standard authentication method for Vikunja:
How to obtain: Go to Vikunja Settings → API Tokens → Create new token
Token format: Starts with tk_ (e.g., tk_abc123def456)
Capabilities: Full access to tasks, projects, labels, teams, and webhooks
Limitations: Cannot access user-specific endpoints (user profile, settings, export)
Best for: Automation, CI/CD, and general task management
JWT (JSON Web Token) authentication provides full access to all Vikunja endpoints:
How to obtain: Extract from your browser session (see instructions below)
Token format: Long string starting with eyJ (standard JWT format)
Capabilities: Full access to all endpoints including user management and export
Limitations: Tokens expire (typically after 24 hours)
Best for: User management, data export, and operations requiring user context
Log into Vikunja in your web browser
Open Developer Tools (F12 or right-click → Inspect)
Go to the Application/Storage tab
Find the JWT token:
Look in Local Storage → your Vikunja domain
Find the key named token or similar
The value is your JWT token
Copy the entire token value (it's quite long)
// Connect with JWT token - automatically detected!
vikunja_auth.connect({
apiUrl: "https://your-vikunja-instance.com/api/v1",
apiToken: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
})Important Notes:
JWT tokens expire; you'll need to extract a new one when it expires
Token type is automatically detected based on format (no flag needed)
Some tools (users, export) are only available with JWT authentication
Set up authentication (if not using environment variables):
vikunja_auth.connect({
apiUrl: "https://your-vikunja-instance.com/api/v1",
apiToken: "your-api-token"
})Create your first task:
vikunja_tasks.create({
projectId: 1,
title: "My first task via MCP!"
})List all your tasks:
vikunja_tasks.list({ allProjects: true })The MCP server exposes tools with subcommands. All operations require authentication first (either via environment variables or manual connection).
// Connect with API token (automatically detected)
vikunja_auth.connect({
apiUrl: "https://your-vikunja-instance.com/api/v1",
apiToken: "tk_your-api-token"
})
// Connect with JWT token (automatically detected, enables additional tools: users, export)
vikunja_auth.connect({
apiUrl: "https://your-vikunja-instance.com/api/v1",
apiToken: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
})
// Check authentication status
vikunja_auth.status()
// Disconnect and clean up resources
vikunja_auth.disconnect()// List all tasks across all projects
vikunja_tasks.list({ allProjects: true })
// List tasks for a specific project with pagination
vikunja_tasks.list({
projectId: 1,
page: 1,
perPage: 20,
sort: "due_date"
})
// List tasks with filters (high priority, not done)
vikunja_tasks.list({
filter: "(priority >= 4 && done = false)"
})
// List tasks with simple filter
vikunja_tasks.list({
filter: "priority >= 3"
})
// List tasks with complex filter conditions
vikunja_tasks.list({
filter: "(priority >= 3 && priority <= 5) || (done = true && updated > '2024-01-01')"
})
// Combine filter with search
vikunja_tasks.list({
filter: "priority >= 4",
search: "urgent"
})
// Create a new task with labels and assignees
vikunja_tasks.create({
projectId: 1,
title: "Complete documentation",
description: "Update README with examples",
dueDate: "2024-12-31T23:59:59Z",
priority: 3,
labels: [1, 2], // Label IDs
assignees: [1, 3] // User IDs
})
// Create a recurring task (repeats every week)
vikunja_tasks.create({
projectId: 1,
title: "Weekly team meeting",
description: "Sync up with the team",
dueDate: "2024-12-01T10:00:00Z",
repeatAfter: 7, // Number of units
repeatMode: "day" // Unit: "day", "week", "month", or "year"
})
// Create a monthly recurring task
vikunja_tasks.create({
projectId: 1,
title: "Monthly report",
repeatAfter: 1,
repeatMode: "month"
})
// Get detailed information about a task
vikunja_tasks.get({ id: 123 })
// Update a task (partial updates supported)
vikunja_tasks.update({
id: 123,
done: true,
priority: 5
})
// Update recurring settings on an existing task
vikunja_tasks.update({
id: 123,
repeatAfter: 14, // Change to bi-weekly
repeatMode: "day"
})
// Update task assignees (uses efficient diff-based approach)
vikunja_tasks.update({
id: 123,
assignees: [1, 2, 4] // Only adds/removes differences
})
// Delete a task
vikunja_tasks.delete({ id: 123 })
// Bulk assign users to a task
vikunja_tasks.assign({
id: 123,
assignees: [2, 3, 4]
})
// Remove users from a task
vikunja_tasks.unassign({
id: 123,
assignees: [2, 4] // Removes only these users
})
// List all assignees for a task
vikunja_tasks.list-assignees({ id: 123 })
// Add a comment to a task
vikunja_tasks.comment({
id: 123,
comment: "This task is now complete!"
})
// List all comments on a task
vikunja_tasks.comment({ id: 123 })
// Create a task relation (e.g., subtask, blocking, related)
vikunja_tasks.relate({
id: 123,
otherTaskId: 124,
relationKind: "subtask" // 124 is a subtask of 123
})
// Available relation kinds:
// - subtask: Other task is a subtask of this task
// - parenttask: Other task is the parent of this task
// - related: Tasks are related
// - duplicateof: This task is a duplicate of the other
// - duplicates: Other task is a duplicate of this one
// - blocking: This task blocks the other
// - blocked: This task is blocked by the other
// - precedes: This task precedes the other
// - follows: This task follows the other
// - copiedfrom: This task was copied from the other
// - copiedto: Other task was copied from this one
// Remove a task relation
vikunja_tasks.unrelate({
id: 123,
otherTaskId: 124,
relationKind: "subtask"
})
// Get all relations for a task
vikunja_tasks.relations({ id: 123 })
// Add a reminder to a task
vikunja_tasks.add-reminder({
id: 123,
reminderDate: "2024-12-25T10:00:00Z"
})
// List all reminders for a task
vikunja_tasks.list-reminders({ id: 123 })
// Remove a specific reminder from a task
vikunja_tasks.remove-reminder({
id: 123,
reminderId: 1
})
// Bulk create multiple tasks at once (max 100)
vikunja_tasks.bulk-create({
projectId: 1,
tasks: [
{
title: "Task 1",
description: "First task",
priority: 3,
labels: [1, 2]
},
{
title: "Task 2",
dueDate: "2024-12-31T23:59:59Z",
assignees: [1]
},
{
title: "Weekly standup",
repeatAfter: 7,
repeatMode: "day"
}
]
})
// Bulk update multiple tasks with the same field value
vikunja_tasks.bulk-update({
taskIds: [123, 124, 125],
field: "done", // Field to update
value: true // New value for all tasks
})
// Other bulk update examples
vikunja_tasks.bulk-update({
taskIds: [123, 124, 125],
field: "priority",
value: 5
})
vikunja_tasks.bulk-update({
taskIds: [123, 124],
field: "project_id",
value: 2 // Move tasks to different project
})
vikunja_tasks.bulk-update({
taskIds: [123, 124, 125],
field: "labels",
value: [1, 3, 5] // Set same labels on all tasks
})
// Bulk delete multiple tasks (max 100)
vikunja_tasks.bulk-delete({
taskIds: [123, 124, 125]
})
// Batch import tasks from CSV or JSON
vikunja_batch_import({
projectId: 1,
format: "json",
data: JSON.stringify([
{
title: "Task 1",
description: "First imported task",
priority: 3,
dueDate: "2024-12-31T23:59:59Z"
},
{
title: "Task 2",
labels: ["bug", "urgent"], // Will look up label IDs by name
assignees: ["john.doe"] // Will look up user IDs by username
}
])
})
// Import from CSV with headers
vikunja_batch_import({
projectId: 1,
format: "csv",
data: `title,description,priority,dueDate,labels,assignees
"Task 1","Description with, comma",3,2024-12-31T23:59:59Z,"bug;feature","john.doe"
"Task 2","Another task",5,,"urgent","john.doe;jane.smith"`
})
// Dry run to validate without creating tasks
vikunja_batch_import({
projectId: 1,
format: "json",
data: JSON.stringify([...]),
dryRun: true // Only validates, doesn't create tasks
})
// Continue on errors instead of stopping
vikunja_batch_import({
projectId: 1,
format: "csv",
data: csvData,
skipErrors: true // Skip invalid tasks and continue with valid ones
})// Export a project with all its data
vikunja_export_project({
projectId: 1,
includeChildren: false // Only export the specified project
})
// Export a project including all child projects
vikunja_export_project({
projectId: 1,
includeChildren: true // Recursively export child projects
})
// The export returns JSON data with the following structure:
// {
// project: { ... }, // Project details
// tasks: [ ... ], // All tasks in the project
// labels: [ ... ], // All labels used in tasks
// child_projects: [ ... ], // Nested child project exports (if includeChildren: true)
// exported_at: "...", // ISO timestamp of export
// version: "1.0.0" // Export format version
// }
// Request a full user data export (sent via email)
vikunja_request_user_export({
password: "your-password" // Required for security
})
// Download a previously requested user data export
vikunja_download_user_export({
password: "your-password" // Required for security
})// List all projects
vikunja_projects.list()
// List projects with search and pagination
vikunja_projects.list({
search: "frontend",
page: 1,
perPage: 10,
isArchived: false
})
// Get a specific project
vikunja_projects.get({ id: 1 })
// Create a new project
vikunja_projects.create({
title: "New Frontend Project",
description: "React-based web application",
hexColor: "#4287f5"
})
// Update a project
vikunja_projects.update({
id: 1,
title: "Updated Project Name",
isArchived: true
})
// Archive a project
vikunja_projects.archive({ id: 1 })
// Unarchive a project
vikunja_projects.unarchive({ id: 1 })
// Delete a project
vikunja_projects.delete({ id: 1 })
// --- Project Hierarchy Management ---
// Create a child project
vikunja_projects.create({
title: "Frontend Module",
description: "React components",
parentProjectId: 1, // Will be a child of project 1
hexColor: "#3498db"
})
// Get all direct children of a project
vikunja_projects.get-children({ id: 1 })
// Returns: Array of projects that have parentProjectId = 1
// Get complete project hierarchy as a tree
vikunja_projects.get-tree({ id: 1 })
// Returns: Project with nested children structure
// {
// id: 1,
// title: "Main Project",
// children: [
// {
// id: 2,
// title: "Frontend Module",
// children: [
// { id: 4, title: "Components", children: [] },
// { id: 5, title: "Styles", children: [] }
// ]
// },
// {
// id: 3,
// title: "Backend Module",
// children: []
// }
// ]
// }
// Get breadcrumb path from root to a project
vikunja_projects.get-breadcrumb({ id: 5 })
// Returns: Array of projects from root to target
// [
// { id: 1, title: "Main Project" },
// { id: 2, title: "Frontend Module" },
// { id: 5, title: "Styles" }
// ]
// Also includes a formatted path: "Main Project > Frontend Module > Styles"
// Move a project to a new parent
vikunja_projects.move({
id: 5, // Project to move
parentProjectId: 3 // New parent
})
// Validates against circular references and depth limits
// Move a project to root level (no parent)
vikunja_projects.move({
id: 5,
parentProjectId: undefined
})
// --- Project Sharing ---
// Create a read-only share link
vikunja_projects.create-share({
id: 1,
right: 0, // 0=Read, 1=Write, 2=Admin
label: "Public read-only access"
})
// Create a password-protected share with write access
vikunja_projects.create-share({
id: 1,
right: 1,
password: "securepassword123",
label: "Team collaboration link"
})
// Create an expiring share link
vikunja_projects.create-share({
id: 1,
right: 0,
expires: "2025-12-31T23:59:59Z",
label: "Temporary access until year end"
})
// List all shares for a project
vikunja_projects.list-shares({ id: 1 })
// Get details of a specific share
vikunja_projects.get-share({
id: 1,
shareId: 123
})
// Delete a share link
vikunja_projects.delete-share({
id: 1,
shareId: 123
})
// Authenticate to access a shared project
vikunja_projects.auth-share({
shareHash: "abc123def456"
})
// Authenticate to a password-protected share
vikunja_projects.auth-share({
shareHash: "abc123def456",
password: "securepassword123"
})// List all labels
vikunja_labels.list()
// Search for labels
vikunja_labels.list({
search: "bug",
page: 1,
perPage: 20
})
// Get a specific label
vikunja_labels.get({ id: 1 })
// Create a new label
vikunja_labels.create({
title: "Critical",
description: "Critical priority issues",
hexColor: "#ff0000"
})
// Update a label
vikunja_labels.update({
id: 1,
title: "High Priority",
hexColor: "#ff6600"
})
// Delete a label
vikunja_labels.delete({ id: 1 })
// --- Label Assignment to Tasks ---
// Apply multiple labels to a task
vikunja_tasks.apply-label({
id: 123,
labels: [1, 2, 3] // Apply labels with IDs 1, 2, and 3
})
// Apply a single label
vikunja_tasks.apply-label({
id: 123,
labels: [1] // Apply just the "research" label
})
// Remove specific labels from a task
vikunja_tasks.remove-label({
id: 123,
labels: [2, 3] // Remove labels 2 and 3, keep others
})
// List all labels on a task
vikunja_tasks.list-labels({ id: 123 })
// Returns: Task info with detailed label data including colors and descriptions// List all teams
vikunja_teams.list()
// Search for teams
vikunja_teams.list({
search: "frontend",
page: 1,
perPage: 10
})
// Create a new team
vikunja_teams.create({
name: "Frontend Team",
description: "Responsible for UI/UX development"
})
// Delete a team
vikunja_teams.delete({ id: 1 })
// Note: get, update, and members operations are not yet
// implemented in the node-vikunja library⚠️ Known Issue: User endpoints may fail with authentication errors even when using valid tokens. This is a known Vikunja API issue. The MCP server will provide helpful error messages when this occurs. If you encounter this issue, please contact your Vikunja server administrator.
// Get current user information
vikunja_users.current()
// Search for users
vikunja_users.search({
search: "john"
})
// Get current user settings
vikunja_users.settings()
// Update user settings
vikunja_users.update-settings({
name: "John Doe",
language: "en",
timezone: "America/New_York",
weekStart: 1 // Monday
})
// Update notification preferences
vikunja_users.update-settings({
emailRemindersEnabled: true, // Enable email reminders for tasks
overdueTasksRemindersEnabled: true, // Enable daily overdue task emails
overdueTasksRemindersTime: "09:00" // Time to send overdue task summary
})// List all available webhook events
vikunja_webhooks.list-events()
// Returns: ["task.created", "task.updated", "task.deleted", "task.assigned", ...]
// List webhooks for a project
vikunja_webhooks.list({ projectId: 1 })
// Create a webhook for task events
vikunja_webhooks.create({
projectId: 1,
targetUrl: "https://example.com/webhook",
events: ["task.created", "task.updated"],
secret: "my-secret-key" // Optional, for HMAC signing
})
// Create a webhook without secret
vikunja_webhooks.create({
projectId: 1,
targetUrl: "https://example.com/notifications",
events: ["task.assigned", "task.comment.created"]
})
// Get a specific webhook
vikunja_webhooks.get({
projectId: 1,
webhookId: 123
})
// Update webhook events
vikunja_webhooks.update({
projectId: 1,
webhookId: 123,
events: ["task.created", "task.updated", "task.deleted"]
})
// Delete a webhook
vikunja_webhooks.delete({
projectId: 1,
webhookId: 123
})// Create a saved filter for high priority tasks
vikunja_filters.create({
name: "High Priority Tasks",
description: "All undone tasks with priority 4 or 5",
filter: "done = false && priority >= 4",
isGlobal: true
})
// Alternative format using title and filters object
vikunja_filters.create({
title: "🔥 High Priority Tasks",
description: "All tasks with priority 4 or 5 that are not completed",
filters: {
filter_by: ["priority"],
filter_value: ["5"],
filter_comparator: [">="],
filter_concat: ""
},
is_favorite: true
})
// Create a filter with multiple conditions
vikunja_filters.create({
title: "Urgent & Incomplete",
filters: {
filter_by: ["priority", "done"],
filter_value: ["3", "false"],
filter_comparator: [">=", "="],
filter_concat: "&&"
}
})
// Create a project-specific filter
vikunja_filters.create({
name: "This Week's Tasks",
filter: "dueDate >= now && dueDate < now+7d",
projectId: 1,
isGlobal: false
})
// List all saved filters
vikunja_filters.list()
// List filters for a specific project
vikunja_filters.list({ projectId: 1 })
// Apply a saved filter to task listing
vikunja_tasks.list({
filterId: "550e8400-e29b-41d4-a716-446655440000"
})
// Build a filter programmatically
vikunja_filters.build({
conditions: [
{ field: "done", operator: "=", value: false },
{ field: "priority", operator: ">=", value: 3 },
{ field: "assignees", operator: "in", value: ["user1", "user2"] }
],
groupOperator: "&&"
})
// Returns: { filter: "(done = false && priority >= 3 && assignees in user1, user2)", valid: true }
// Update an existing filter
vikunja_filters.update({
id: "550e8400-e29b-41d4-a716-446655440000",
name: "Critical Tasks",
filter: "done = false && priority = 5"
})
// Validate a filter string
vikunja_filters.validate({
filter: "done = false && priority >= 3"
})
// Returns: { valid: true, errors: [] }The Vikunja filter syntax supports SQL-like queries with the following:
Fields:
done - Task completion status (boolean)
priority - Task priority (1-5)
percentDone - Completion percentage (0-100)
dueDate - Task due date
assignees - Task assignees
labels - Associated labels
created - Task creation time
updated - Task update time
Operators:
Comparison: =, !=, >, >=, <, <=
Pattern matching: like (uses % wildcard)
List matching: in, not in
Date Math:
now - Current time
now+24h - 24 hours from now
now-7d - 7 days ago
now/d - Start of current day
Supports: s (seconds), m (minutes), h (hours), d (days), w (weeks), M (months), y (years)
Examples:
priority = 4
dueDate < now
done = false && priority >= 3
assignees in user1, user2
dueDate >= now && dueDate < now+7d
title like "%urgent%"
Smart Hybrid Filtering: This MCP server implements an intelligent hybrid filtering approach that combines server-side and client-side filtering for optimal performance and reliability:
Primary: Attempts server-side filtering first for maximum performance
Fallback: Falls back to client-side filtering if server-side filtering fails or is unavailable
Transparent: Same filter syntax works regardless of which method is used
Optimized: Includes memory protection with pagination limits to prevent unbounded loading
Metadata: Response includes filtering method used (serverSideFiltering or clientSideFiltering)
Performance: Server-side filtering significantly reduces network traffic and processing time
All operations in the Vikunja MCP server follow a standardized response format for consistency and predictability:
interface StandardResponse {
success: boolean;
operation: string; // The operation performed (e.g., 'create', 'update', 'list')
message?: string; // Human-readable description of the result
data?: any; // The primary data returned (task, project, label, etc.)
metadata?: {
timestamp: string; // ISO 8601 timestamp of the operation
[key: string]: any; // Additional operation-specific metadata
};
}Success:
{
"success": true,
"operation": "create",
"message": "Task created successfully",
"data": { "id": 123, "title": "Complete documentation" },
"metadata": { "timestamp": "2025-05-25T12:00:00Z" }
}Error:
{
"success": false,
"operation": "update",
"message": "Task not found",
"error": { "code": "TASK_NOT_FOUND", "details": "No task exists with ID 999" }
}This standardized format ensures:
Consistency: All tools return responses in the same structure
Predictability: Clients always know what fields to expect
Debugging: Metadata provides context for troubleshooting
Error Handling: Clear error information with codes and messages
vikunja_auth - Authentication management
connect - Initialize connection with API token
status - Check authentication status
refresh - Refresh authentication token
vikunja_tasks - Task operations (fully implemented)
list - List tasks with filters
Filter by project or get all tasks
Support for pagination, search, sorting
Filter by completion status
Apply saved filters with filterId parameter
create - Create a new task
Required: title, projectId
Optional: description, dueDate, priority, labels, assignees
Validates date format (ISO 8601) and IDs
get - Get task details by ID
update - Update existing task
Supports partial updates
Can update title, description, dueDate, priority, done status
Can update labels and assignees (uses efficient diff-based approach)
delete - Delete a task by ID
assign - Bulk assign users to tasks
unassign - Remove users from tasks
comment - List or add comments to tasks
bulk-update - Update multiple tasks at once
Required: taskIds array, field name, value
Supported fields: done, priority, due_date, project_id, assignees, labels
Validates field types and values
⚠️ Performance: Makes API calls to fetch each updated task
bulk-delete - Delete multiple tasks at once
Required: taskIds array
Returns deleted task details for confirmation
Handles partial failures gracefully
⚠️ Performance: Makes individual delete calls for each task
Recommended: Process in batches of 20 or fewer tasks
attach - Not implemented (file handling not available in MCP)
vikunja_batch_import - Import multiple tasks from CSV or JSON (fully implemented)
Required: projectId, format ('csv' or 'json'), data
Optional: skipErrors (continue on errors), dryRun (validate only)
Batch Size Limit: Maximum 100 tasks per import
CSV Format:
Requires header row with field names
Supports quoted values and escaped quotes
Fields: title, description, priority, dueDate, labels, assignees
Labels and assignees as semicolon-separated values (semicolons used to avoid conflicts with CSV commas)
JSON Format:
Array of task objects
Same fields as CSV, plus direct support for arrays
Features:
Automatic label lookup by name
Automatic user lookup by username
Validation before creation
Detailed error reporting
Dry run mode for testing
Skip errors option for partial imports
vikunja_projects - Project operations (fully implemented)
list - List all projects with filters
Support for pagination and search
Filter by archived status
get - Get project details by ID
create - Create new project
Required: title
Optional: description, parentProjectId, isArchived, hexColor (format: #RRGGBB)
Validates parent project hierarchy depth (max 10 levels)
update - Update existing project
Supports partial updates
Can update all project fields including hexColor (format: #RRGGBB)
Validates parent project hierarchy depth when changing parent
delete - Delete a project by ID
archive - Archive a project
unarchive - Unarchive a project
Hierarchy Management (New!)
get-children - List direct children of a project
get-tree - Get complete project hierarchy as a tree
get-breadcrumb - Get path from root to a project
move - Move a project to a new parent
Validates against circular references
Enforces maximum depth of 10 levels
Project Sharing
create-share - Create share link with permissions
list-shares - List all shares for a project
get-share - Get share details
delete-share - Remove a share link
auth-share - Authenticate to access a shared project
vikunja_labels - Label operations (fully implemented)
list - List all labels with filters
Support for pagination and search
get - Get label details by ID
create - Create new label
Required: title
Optional: description, hexColor (format: #RRGGBB)
update - Update existing label
Supports partial updates
Can update title, description, hexColor
delete - Delete a label by ID
apply-label - Apply one or more labels to a task
Required: task id, labels array
Supports bulk label application
remove-label - Remove one or more labels from a task
Required: task id, labels array
Supports bulk label removal
list-labels - List all labels assigned to a task
Required: task id
Returns detailed label information
vikunja_templates - Template operations (fully implemented)
create - Create a template from existing project
Required: projectId, name
Optional: description, tags
Captures all project settings and tasks
list - List all available templates
Shows template name, tags, and author
get - Get template details by ID
update - Update template metadata
Can update name, description, tags
delete - Delete a template
instantiate - Create new project from template
Required: id (template ID), projectName
Optional: parentProjectId, variables
Supports variable substitution:
{{PROJECT_NAME}} - The new project name
{{TODAY}} - Current date (YYYY-MM-DD)
{{NOW}} - Current timestamp
Custom variables via the variables parameter
Creates all tasks with labels from template
vikunja_teams - Team operations (partially implemented)
list - List all teams with filters
Support for pagination and search
create - Create new team
Required: name
Optional: description
delete - Delete a team by ID (with fallback API support)
get - Not yet implemented in node-vikunja
update - Not yet implemented in node-vikunja
members - Not yet implemented in node-vikunja
vikunja_users - User operations (fully implemented) [Requires JWT authentication]
current - Get current authenticated user info
search - Search for users
Optional: search query, pagination
settings - Get current user settings
update-settings - Update user settings
Optional: name, language, timezone, weekStart, frontendSettings
Note: User operations require JWT authentication. When using API token authentication, these tools will not be available.
vikunja_webhooks - Webhook operations for project automation (fully implemented)
list-events - Get all available webhook event types
list - List webhooks for a project
Required: projectId
get - Get a specific webhook
Required: projectId, webhookId
create - Create a new webhook
Required: projectId, targetUrl, events (array)
Optional: secret (for HMAC signing)
Note: Events are validated against available event types
update - Update webhook events
Required: projectId, webhookId, events (array)
Note: Events are validated against available event types
delete - Delete a webhook
Required: projectId, webhookId
Event Validation: When creating or updating webhooks, the provided events are automatically validated against the list of available events from the API. Invalid events will result in a clear error message showing which events are invalid and listing all valid options. Valid events are cached for 5 minutes to improve performance.
vikunja_filters - Advanced filtering for tasks (fully implemented)
list - List saved filters
Optional: projectId (for project-specific filters), global flag
get - Get a specific filter by ID
create - Create a new saved filter
Required: name, filter (query string)
Optional: description, projectId, isGlobal
update - Update an existing filter
Required: id
Optional: name, description, filter, projectId, isGlobal
delete - Delete a saved filter
build - Build a filter string from conditions
Required: conditions array
Optional: groupOperator (&&, ||)
validate - Validate a filter string
Note: Saved filters are currently stored in memory and will be lost when the MCP server restarts. For production use, consider implementing persistent storage.
⚠️ WARNING: Memory Usage
Export operations load entire project hierarchies into memory. For very large projects with thousands of tasks or deeply nested structures, this may consume significant memory. Consider exporting smaller projects individually.
vikunja_export_project - Export project data [Requires JWT authentication]
Parameters:
projectId (required) - ID of the project to export
includeChildren (optional) - Include child projects recursively (default: false)
Returns: Complete project data including tasks, labels, and metadata
Features:
Exports all tasks with full details
Includes all labels used in the project
Optionally includes complete child project hierarchy
Circular reference detection for nested projects
Export metadata includes timestamp and version
Note: Export operations require JWT authentication. When using API token authentication, this tool will not be available.
vikunja_request_user_export - Request full user data export
Parameters:
password (required) - User password for security verification
Returns: Confirmation that export has been requested
Note: You will receive an email when the export is ready
vikunja_download_user_export - Download previously requested user data export
Parameters:
password (required) - User password for security verification
Returns: Complete user data export
Note: Export must be requested first via vikunja_request_user_export
File Attachments: The attach subcommand is not implemented due to MCP protocol limitations
Team Operations: Limited functionality due to incomplete node-vikunja API support:
Cannot get team by ID
Cannot update team information
Cannot delete teams
Cannot manage team members
Pagination: Some endpoints may not fully support pagination parameters due to API limitations
Authentication Issues: Some Vikunja API endpoints have known authentication issues:
User endpoints: May fail with token errors even with valid tokens (known Vikunja API limitation)
Bulk operations: May have authentication issues with certain Vikunja API versions
Label operations: May fail with authentication errors on some server configurations
Assignee operations: May fail with authentication errors when creating/updating tasks with assignees
The server provides detailed error messages when these issues occur, suggesting workarounds
Zod Schema Validation: Enterprise-grade input validation with comprehensive type checking
DoS Protection: Input sanitization, length limits, and character allowlisting
Credential Protection: Automatic masking of sensitive tokens and URLs in logs and error messages
Entity Resolution Service: Robust label and user mapping with defensive error handling for malformed API responses
Rate Limiting: Configurable request rate limits and payload size restrictions to prevent DoS attacks
Memory Protection: Pagination limits and memory usage monitoring to prevent resource exhaustion
Error Handling: Structured error responses that avoid exposing sensitive system information
Hybrid Filtering: Smart server-side filtering with client-side fallback for optimal performance
Connection Pooling: Efficient session management with automatic client caching
Request Batching: Optimized bulk operations with efficient diff-based updates
Memory Management: Automatic cleanup and pagination to handle large datasets safely
Thread-Safe Client Management: Async-only ClientContext API eliminates race conditions in concurrent scenarios
Opossum Circuit Breaker: Production-ready retry logic with automatic failure detection and recovery
Simplified Storage: In-memory filter storage with 90% reduced complexity and overhead
The server supports various configuration options through environment variables:
# Vikunja instance URL (required)
VIKUNJA_URL=https://your-vikunja-instance.com/api/v1
# Authentication token (required)
VIKUNJA_API_TOKEN=your-api-token
# Enable debug logging (default: false)
DEBUG=true
# Set log level (error, warn, info, debug)
LOG_LEVEL=debug# Rate limiting (default: enabled)
RATE_LIMIT_ENABLED=true
RATE_LIMIT_PER_MINUTE=60 # Requests per minute (default: 60)
RATE_LIMIT_PER_HOUR=1000 # Requests per hour (default: 1000)
# Request size limits (default: 1MB)
MAX_REQUEST_SIZE=1048576 # Maximum request payload size in bytes
MAX_RESPONSE_SIZE=10485760 # Maximum response size in bytes (default: 10MB)
# Execution timeout (default: 30 seconds)
EXECUTION_TIMEOUT=30000 # Tool execution timeout in milliseconds
# Memory protection (default: enabled)
MEMORY_PROTECTION_ENABLED=true
MAX_TASKS_PER_REQUEST=1000 # Maximum tasks to load per request
# Circuit breaker configuration (opossum)
CIRCUIT_BREAKER_ENABLED=true # Enable circuit breaker for API calls
CIRCUIT_BREAKER_TIMEOUT=60000 # Circuit breaker timeout in milliseconds (default: 60s)
CIRCUIT_BREAKER_ERRORS_THROTTLE=10 # Errors before opening circuit (default: 10)
CIRCUIT_BREAKER_RESET_TIMEOUT=30000 # Time to wait before trying half-open state (default: 30s)
# Filter security (Zod validation)
FILTER_MAX_LENGTH=1000 # Maximum filter string length (default: 1000)
FILTER_MAX_VALUE_LENGTH=200 # Maximum individual value length (default: 200)For detailed rate limiting configuration, see docs/RATE_LIMITING.md.
✅ Security hardening - Comprehensive vulnerability fixes implemented
✅ Performance optimization - Hybrid filtering and memory protection
✅ Error handling - Centralized error utilities and structured responses
✅ Test coverage - 98.91% function coverage achieved
✅ Architecture simplification - 90% code reduction with enhanced maintainability
✅ Production-ready resilience - Opossum circuit breaker and Zod validation
Add webhook subscriptions for real-time updates
Add caching for frequently accessed data
Add integration tests with real Vikunja instance
Implement persistent storage for saved filters (optional - in-memory works well)
Please see CONTRIBUTING.md for development guidelines and workflow.
MIT
Manage authentication with Vikunja API (connect, status, refresh, disconnect)
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| apiUrl | No | ||
| apiToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It only superficially mentions 'manage authentication' but fails to indicate side effects (e.g., disconnect terminates session), required authentication, or rate limits for each subcommand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that quickly conveys the tool's purpose and key actions. It is front-loaded and efficient, though it could benefit from more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of schema descriptions, output schema, and annotation support, the description is insufficient. It does not explain subcommand behavior, parameter usage, or expected outcomes, leaving the agent with critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters. It merely repeats the subcommand enum and does not clarify the role of apiUrl and apiToken or their necessity for specific subcommands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it manages authentication for Vikunja API and lists the specific subcommands (connect, status, refresh, disconnect), distinguishing it from sibling tools focused on other domains like tasks, labels, and projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or which subcommand to choose under what circumstances. There are no prerequisites or situational examples, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import tasks in bulk from CSV or JSON formats with error handling and dry-run support
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| format | Yes | ||
| data | Yes | ||
| skipErrors | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions error handling and dry-run support, but does not disclose side effects, auth requirements, or error behavior (e.g., rollback). Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key information. Structured well but could be broken into a list for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is far too minimal. Lacks parameter details, return values, and error handling specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only adds meaning for 'format' (CSV/JSON), leaving 'projectId', 'data', 'skipErrors', 'dryRun' unexplained. Fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool imports tasks in bulk from CSV or JSON formats, with error handling and dry-run support. It differentiates from sibling tools like vikunja_task_bulk by specifying formats and features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 implies bulk import, but lacks context like prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage and build advanced filters for tasks and projects with validation
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| parameters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'validation' but fails to disclose the behavioral traits of each action (e.g., list is read-only, delete is destructive) or any side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise but too brief for a tool with multiple actions and a complex parameters object. It is not wastefully long, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and the presence of a nested 'parameters' object, the description is incomplete. It does not cover the behavior for each action, the required format for parameters, or the expected output, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not explain the meaning of the 'action' enum values or the structure of the 'parameters' object. No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage and build advanced filters for tasks and projects with validation', which clearly indicates the tool deals with filters. However, it does not specify what 'manage' entails beyond the generic verb, and it does not differentiate from sibling tools that also manage project-related entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention any exclusions, prerequisites, or scenarios where other sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task labels with full CRUD operations for organizing and categorizing tasks
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| id | No | ||
| page | No | ||
| perPage | No | ||
| search | No | ||
| title | No | ||
| description | No | ||
| hexColor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states 'full CRUD operations', which is inherent from the schema's subcommand enum. No additional traits (e.g., permissions, pagination behavior, idempotency, side effects) are described, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is too vague to be concise. While short, it fails to convey essential details about the tool's functionality, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is severely incomplete. It does not cover parameter behavior, return values, or operational context, making it inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description adds no information about what each parameter (e.g., id, page, title, hexColor) means or how they interact. This leaves the agent without critical guidance for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage task labels with full CRUD operations', which clearly identifies the resource (task labels) and the operations (CRUD). It distinguishes from sibling tools like vikunja_task_labels, which likely focus on label-task associations rather than label management itself. However, the verb 'Manage' is somewhat generic; 'CRUD operations' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., vikunja_task_labels). The description lacks context for appropriate usage, prerequisites, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage projects with full CRUD operations, hierarchy management, and sharing capabilities
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| id | No | ||
| title | No | ||
| description | No | ||
| parentProjectId | No | ||
| isArchived | No | ||
| hexColor | No | ||
| page | No | ||
| perPage | No | ||
| search | No | ||
| maxDepth | No | ||
| includeArchived | No | ||
| projectId | No | ||
| shareId | No | ||
| shareHash | No | ||
| right | No | ||
| name | No | ||
| password | No | ||
| shares | No | ||
| sessionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behaviors. It mentions CRUD operations but fails to detail side effects (e.g., archive/unarchive, sharing implications, authentication needs) or hierarchy consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence), but it lacks structure and is under-informative. It could be improved by listing key subcommands or capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters, no output schema, and many suboperations, the description is extremely incomplete. It provides no details on pagination, sharing, hierarchy commands, or how to use the subcommand parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. It doesn't describe the subcommand enum or other fields like id, title, pagination, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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. It distinguishes from sibling tools which focus on other resources (tasks, labels, etc.). However, it doesn't explicitly differentiate from other project-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites or context for using specific subcommands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task assignments: assign users, unassign users, list assignees
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| id | Yes | ||
| assignees | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only implies mutation for assign/unassign and query for list, but does not explain side effects (e.g., whether duplicate assignments are ignored, or permissions required).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loads the purpose. However, it could include brief parameter explanations without becoming overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the tool description is incomplete. It does not mention return values for list-assignees, error conditions, or prerequisite states (e.g., task existence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), and the description does not explain parameters. 'id' could be task ID but is unspecified; 'assignees' is an array of numbers but not identified as user IDs. The description adds no semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage task assignments' and lists three specific operations (assign, unassign, list assignees). This distinguishes it from sibling tools like vikunja_task_crud or vikunja_labels, which handle different aspects of tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no differentiation between operations (e.g., when to assign vs unassign) and no mention of prerequisites or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage bulk task operations: create, update, delete multiple tasks
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| taskIds | No | ||
| field | No | ||
| value | No | ||
| projectId | No | ||
| tasks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It only names the three operations (create, update, delete) but does not mention side effects, idempotency, required permissions, or error behavior. Missing critical info for a bulk operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but severely under-specified. Every word is used, but the description is too short to convey necessary information for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no schema descriptions, no output schema, the description is grossly incomplete. It fails to explain operation-specific requirements (e.g., 'bulk-delete' needs 'taskIds', 'bulk-update' needs 'field' and 'value' or 'tasks').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds no parameter details. It does not explain how to use 'operation', 'taskIds', 'field', 'value', 'projectId', or 'tasks'. The agent must infer from the enum and object structure alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs bulk task operations (create, update, delete), distinguishing it from single-task siblings. However, the verb 'manage' is somewhat vague; a more active verb like 'perform' would be better.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 for single tasks or vikunja_batch_import for import. The description implies usage for bulk operations but does not explicitly state 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.
Manage task comments: add comments to tasks
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| id | Yes | ||
| comment | Yes | ||
| commentId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a write operation ('add comments') but does not disclose whether the tool also supports deletion, updating, or listing comments. No mention of side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise, but its brevity comes at the cost of completeness. It provides a basic purpose without wasting words, but could be more structured to separate overview from details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, the description is insufficient. It lacks information on how to use `commentId`, what the response contains, and how this tool fits into the broader task comment workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It only implies that `id` is a task ID and `comment` is text, but does not explain `commentId` (perhaps for deletion or update) or the `operation` enum. This leaves significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'add comments to tasks', which identifies the primary action and resource. It differentiates from sibling tools like vikunja_task_crud that handle task CRUD, but 'manage' is a broad verb that slightly obscures the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No preconditions, exclusions, or context about comment lifecycle are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage individual tasks: create, get, update, delete, list
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| title | No | ||
| description | No | ||
| projectId | No | ||
| dueDate | No | ||
| priority | No | ||
| labels | No | ||
| assignees | No | ||
| repeatAfter | No | ||
| repeatMode | No | ||
| id | No | ||
| filter | No | ||
| filterId | No | ||
| page | No | ||
| perPage | No | ||
| sort | No | ||
| search | No | ||
| allProjects | No | ||
| done | No | ||
| sessionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'manage', but does not mention required authentication, destructive nature of delete, or that specific operations need particular parameters (e.g., id for update/delete). The description lacks critical safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of essential details. It effectively restates the tool's name and enumerates operations, but contains no proactive guidance. It is minimally adequate but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters and no annotations or output schema, this description is severely incomplete. The agent cannot correctly invoke the tool without additional documentation. Context like parameter usage per operation, pagination for list, or error handling is entirely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explanation of the 20 parameters. It merely lists operations without linking them to required parameters (e.g., create requires title, delete requires id). The agent cannot understand which parameters to use for each operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage individual tasks: create, get, update, delete, list', clearly specifying the resource ('individual tasks') and the actions. It distinguishes from sibling tools like vikunja_tasks (which may handle bulk operations) by emphasizing 'individual'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many sibling tools (e.g., vikunja_task_assignees, vikunja_task_labels). The agent must infer from the tool name alone, which is insufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task labels: apply, remove, list labels
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| id | Yes | ||
| labels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'manage task labels' without explaining side effects (e.g., whether applying a non-existent label creates it), permission requirements, or what operations are idempotent. The enum implies mutation and read, but details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, front-loading the purpose. While it could be slightly more informative, it avoids fluff and gets to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is too sparse. It does not specify what 'list-labels' returns, or required parameter relationships (e.g., labels required for apply/remove). More detail is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters. It does not: 'id' is not confirmed as task ID, 'labels' as label IDs, no format or constraints. The enum values are self-explanatory, but additional context is lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 task labels with three specific operations (apply, remove, list). This is a specific verb+resource combination. However, it does not differentiate from sibling tools like vikunja_labels (which likely manages label definitions) or vikunja_task_crud, but the operation enum provides clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as vikunja_labels for creating labels. It does not mention prerequisites (e.g., task must exist, label must exist) 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.
Manage task relationships: relate tasks, unrelate tasks, list relations
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| id | Yes | ||
| otherTaskId | No | ||
| relationKind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists the three operations without mentioning any behavioral traits such as authentication needs, whether operations are reversible, side effects, or rate limits. This is insufficient for an agent to understand the behavior beyond the bare functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks structure. It lists operations but does not differentiate them or provide any hierarchical organization. While it is not verbose, it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 2 required, and no output schema or annotations, the description is incomplete. It does not specify parameter usage per operation (e.g., which params are needed for 'relate' vs 'list'). This leads to ambiguity for the agent when selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond what the schema already provides. Schema_description_coverage is 0%, and the description does not explain the parameters (e.g., what 'relationKind' values imply, or that 'otherTaskId' is needed for relate/unrelate). The enum values are uninterpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Manage task relationships: relate tasks, unrelate tasks, list relations', clearly indicating the verb (manage/relate/unrelate/list) and resource (task relationships). It distinguishes from siblings like vikunja_task_crud which handles individual tasks, thus earning a high score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for managing task relationships but does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or alternatives are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task reminders: add, remove, list reminders
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| id | Yes | ||
| reminderDate | No | ||
| reminderId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden, but it only says 'manage' without disclosing side effects (e.g., idempotency, error handling, permission requirements). The enum implies the operations but offers no behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the main purpose. However, it omits necessary details, making it efficient but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters with 0% coverage, the description is incomplete. It leaves agents guessing about parameter usage, return values, and operational nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It only lists operations, ignoring id, reminderDate, and reminderId. No format, purpose, or relationship is explained, forcing inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages task reminders with three specific operations (add, remove, list). This verb+resource combination distinguishes it from sibling tools like vikunja_task_comments or vikunja_task_crud.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, contexts, or exclusions. For example, it could clarify that reminders are per-task and that this tool complements vikunja_task_crud.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage tasks with comprehensive operations (create, update, delete, list, assign, attach files, comment, bulk operations)
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| title | No | ||
| description | No | ||
| projectId | No | ||
| dueDate | No | ||
| priority | No | ||
| labels | No | ||
| assignees | No | ||
| repeatAfter | No | ||
| repeatMode | No | ||
| id | No | ||
| filter | No | ||
| filterId | No | ||
| page | No | ||
| perPage | No | ||
| sort | No | ||
| search | No | ||
| allProjects | No | ||
| done | No | ||
| comment | No | ||
| commentId | No | ||
| taskIds | No | ||
| field | No | ||
| value | No | ||
| tasks | No | ||
| reminderDate | No | ||
| reminderId | No | ||
| otherTaskId | No | ||
| relationKind | No | ||
| sessionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It omits any mention of side effects (e.g., destructive operations like delete), authentication requirements, or read/write nature. The agent has no insight into tool behavior beyond the subcommand names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it sacrifices necessary information for brevity. It lacks structure (no bullet points, no examples) and fails to earn its place by omitting critical details expected for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (30 parameters, 20 subcommands, many sibling tools) and absence of output schema or rich annotations, the description is wholly inadequate. It provides no usage context, no subcommand-specific guidance, and no behavioral details, making it nearly useless for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The tool description adds no explanation for any of the 30 parameters, leaving the agent clueless about parameter meaning, default values, or which parameters apply to which subcommands.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Manage tasks with comprehensive operations' and lists examples, which gives a general sense. However, it doesn't distinguish this from specialized sibling tools like vikunja_task_crud or vikunja_task_assignees, making it unclear when to use this over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 specialized siblings. The description does not mention prerequisites, exclusions, or alternatives, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage teams and team memberships for collaborative project management
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| page | No | ||
| perPage | No | ||
| search | No | ||
| id | No | ||
| name | No | ||
| description | No | ||
| memberSubcommand | No | ||
| userId | No | ||
| admin | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Manage teams and team memberships,' failing to disclose authentication needs, rate limits, side effects of operations (e.g., deletion cascades), or any other behaviors beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but this is under-specification rather than conciseness. It fails to earn its place by omitting essential details about the tool's functionality and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, 2 enums, no output schema) and missing annotations, the description is severely incomplete. It does not explain the subcommand pattern, how to use the member subcommands, or any return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation of any parameter. For a tool with 10 parameters including enums like subcommand and memberSubcommand, the lack of any parameter semantics is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages teams and memberships, which indicates the general domain but lacks specificity. It does not mention the CRUD operations or the subcommand structure, making it somewhat vague. However, it is not a tautology and correctly identifies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool vs. alternatives like vikunja_projects or vikunja_task_assignees, nor does it specify prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage task templates for creating consistent tasks and project structures
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| id | No | ||
| projectId | No | ||
| name | No | ||
| description | No | ||
| tags | No | ||
| projectName | No | ||
| parentProjectId | No | ||
| variables | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description omits any behavioral traits such as mutability, authentication needs, side effects (e.g., template creation), or limits. Agent has no insight beyond basic CRUD inference from subcommand enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is extremely concise but fails to convey necessary details for a 9-parameter, subcommand-driven tool. Under-specification outweighs brevity benefits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and complex parameter set with subcommands, description is vastly incomplete. No information about return values, operation-specific requirements, or parameter interdependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description offers no explanation of parameters. The subcommand enum, required fields per operation, and parameter conditions (e.g., id for get/update/delete) are left entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the resource (task templates) and a general purpose (consistent tasks/project structures), but 'manage' is vague and does not specify the subcommand operations (CRUD, instantiate). Lacks specificity to distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like vikunja_tasks or vikunja_projects. Missing any when-to-use/when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage webhooks for integrating Vikunja events with external services
| Name | Required | Description | Default |
|---|---|---|---|
| subcommand | Yes | ||
| projectId | No | ||
| webhookId | No | ||
| targetUrl | No | ||
| events | No | ||
| secret | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as authentication needs, side effects (e.g., whether operations are destructive), or rate limits. The agent is left without critical information for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 important details. It is front-loaded with the core purpose, but the brevity undermines clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter descriptions, the description is severely incomplete. It does not explain subcommand semantics, required parameters per action, or expected responses, leaving the agent unable to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The enum for subcommand is present but not elaborated, and other fields like projectId, webhookId, etc., lack context. The agent cannot determine parameter roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's domain (webhooks) and purpose (integrating events with external services). It distinguishes from sibling tools like vikunja_tasks, vikunja_projects, etc., though 'manage' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 instead of alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The vikunja_tasks tool overlaps significantly with multiple specialized tools (e.g., vikunja_task_crud, vikunja_task_assignees, vikunja_task_comments, vikunja_task_bulk), creating ambiguity about which tool to use for common operations. Additionally, vikunja_labels and vikunja_task_labels are distinct but their names are confusingly similar.
All tools share a consistent 'vikunja_' prefix and use snake_case. Most tools follow a verb_noun pattern (e.g., vikunja_batch_import, vikunja_task_assignees), but some are just nouns (e.g., vikunja_labels, vikunja_projects). The vikunja_tasks tool is overly broad compared to others, creating a minor inconsistency.
With 16 tools, the server covers many aspects of task management, but the redundancy from vikunja_tasks duplicating other tools makes the count feel slightly inflated. Still, it remains within a reasonable range for a comprehensive API.
The tool set provides full CRUD for tasks, projects, labels, teams, and templates, plus advanced features like filters, webhooks, bulk operations, relations, reminders, and authentication. There are no obvious gaps for standard task management workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/democratize-technology/vikunja-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
