vikunja-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: tasks, projects, and labels are cleanly separated, and remove_task/restore_task are explicitly paired as opposites. There is no meaningful overlap between any two tools.
Naming Consistency5/5
All tools follow a consistent lower_snake_case verb_noun pattern, such as list_tasks, get_task, update_task, and create_project. The naming is uniform and predictable across the whole set.
Tool Count5/5
Eleven tools is a well-scoped set for a task/project management server, covering tasks, projects, and labels without excessive fragmentation. Each tool earns its place in the API surface.
Completeness4/5
Task lifecycle coverage is strong with list/get/create/update/remove/restore and label manipulation. The main gap is project coverage, which supports list/get/create but lacks update/delete or archive operations, though these are less central to task-focused workflows.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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 passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose a significant side effect—missing labels are created—but it does not mention whether labels are added to existing ones, whether the operation is idempotent, or what happens on invalid task IDs. Partial 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?
The description is a single, tightly worded sentence with no filler. It front-loads the primary action and immediately follows with the most important behavioral nuance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers the core purpose and side effects. It does not address edge cases like duplicate labels or whether the task must already exist, but these are secondary for such a straightforward operation. The presence of an output schema further reduces the need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds a small amount of semantic value by explaining that labels will be created if absent, which enriches the 'labels' parameter meaning. This is adequate given high schema coverage.
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 states a specific verb and resource ('Attach labels to a task') and adds the key behavioral distinction ('creating any that do not exist yet'). It is clearly distinct from sibling tools like list_tasks or create_task, so an agent can immediately understand what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you want labels attached to a task. However, there is no explicit guidance about when to use this instead of an alternative, nor any mention of prerequisites or exclusions. The context is clear but not elaborated.
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 provided, the description carries the full burden of behavioral disclosure. It clearly communicates the core side effect — a new project is created — and the optional hierarchical nesting behavior, but it does not address permissions, failure modes, or effects on parent projects. This is adequate for a straightforward create operation but not deeply transparent.
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 a single, front-loaded sentence with no filler or redundancy. Every word earns its place: the verb, the target resource, and the key optionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema parameter documentation and an output schema present, this is a low-complexity create tool. The description provides enough for an agent to select and invoke it correctly; the only gap is explicit guidance about when to choose this tool over sibling creation tools, such as create_task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with descriptions, defaults, and types, so schema coverage is 100%. The description's 'optionally nested' clause adds little beyond what the schema's parent_project_id field already explains. Therefore the description contributes minimal parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Create', and a specific resource, 'project', and adds a meaningful scoping detail with 'optionally nested under a parent project'. This clearly distinguishes it from sibling tools such as list_projects, get_project, and create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case — creating a project — is implied and the optional nesting clause gives a hint about when to use parent_project_id. However, it does not explicitly mention alternatives or state when not to use this tool, so some usage context is left to inference.
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?
Annotations already provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the useful context that results are scoped to the configured token's visibility. It does not mention pagination behavior, but the schema documents page/per_page, so the added behavioral disclosure is adequate but not rich.
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 core action and resource, then adds the key scoping detail. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema present and full parameter documentation in the schema, the description is nearly complete. It identifies the tool's scope and purpose. It could be slightly stronger with an explicit pointer to get_project for single-project details, but nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (page, query, per_page, is_archived) are already documented in the schema. The description adds no new parameter-level meaning, which is acceptable given the high schema coverage. Baseline 3 applies.
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?
States a specific verb ('List'), a specific resource ('projects'), and a meaningful scope ('visible to the configured token'). It also signals that output includes numeric ids, which is useful for downstream calls. This clearly distinguishes it from sibling tools like get_project and list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to enumerate projects available to the current token. However, it does not explicitly contrast with get_project (single project lookup), create_project, or list_tasks, nor does it state when not to use this tool. The usage context is clear but not fully explicit.
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?
The description says 'Read', which matches the readOnlyHint annotation; no contradiction. It adds no further behavioral context (e.g., not-found behavior, auth needs), but for a simple getter the annotation already conveys the safety profile.
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, front-loaded sentence with no wasted words. It conveys the essential operation and scope in minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required param fully documented, readOnlyHint present, and an output schema available, the description is sufficient for an agent to use the tool correctly. Error handling and return format are covered by schema/annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; project_id is already documented as 'Numeric project id.' The description's 'by id' adds only trivial reinforcement and no new semantic meaning. Baseline 3 applies.
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?
States the verb 'Read' with a specific resource ('a single project') and selection criterion ('by id'). This clearly distinguishes it from list_projects (multiple projects) and get_task (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a single project is needed by ID, but it does not explicitly name alternatives or exclusions. The sibling list makes the distinction inferrable, but the tool description itself provides no direct usage guidance.
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?
The readOnlyHint annotation already signals this is a safe read operation, and the description reinforces that by saying 'Read'. It adds the detail that labels and assignees are included, but provides no additional behavioral context such as not-found behavior or response shape, which is acceptable given the annotation coverage.
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 a single, tight sentence with no filler. The primary action and target are front-loaded, and the included detail is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with a readOnlyHint, a complete input schema, and an output schema present, the description fully covers what an agent needs to invoke the tool correctly. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: task_id is documented as 'Numeric task id' and expand is 'Extra data to embed.' The description adds no meaningful parameter-level semantics beyond what the schema already states, so the baseline score of 3 applies.
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 a specific verb ('Read'), a specific resource ('a single task'), and a retrieval key ('by id'), making it immediately clear what this tool does. The singular scope separated from list_tasks and the mutating siblings (create/update/remove/restore) helps an agent distinguish it.
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 clearly implies the intended use case: fetch one task when you have its numeric id, rather than listing tasks. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full guidance.
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?
The readOnlyHint annotation already covers the main safety concern. The description adds the utility of labels for filter expressions but does not disclose pagination behavior or query semantics, though the output schema and parameter descriptions partially compensate.
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, front-loaded sentence communicates the operation and its practical use with no wasted words. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list tool with fully documented parameters and an output schema, the description is complete. It tells the agent what the tool does and why it would be useful, and nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have full schema descriptions, so the description does not need to explain them. The stated purpose ('need label ids') indirectly clarifies why the tool exists but adds no parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List labels') and adds a concrete purpose ('building filter expressions that need label ids'). This clearly distinguishes it from sibling tools like list_tasks and list_projects.
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 gives clear context: use this when you need label IDs for filter expressions. It does not explicitly discuss alternatives or exclusions, but the intended use case is evident and sufficient for this tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the underlying mechanism ('detaching the removal label'), which clarifies that removal is label-based and reversible rather than destructive. This adds value beyond the idempotentHint annotation, and there is no contradiction with annotations.
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 a single sentence that front-loads the purpose and includes the key mechanism. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and idempotentHint annotation, the description provides enough context to invoke it correctly. It could be more explicit about edge cases, such as restoring a task that is not currently removed, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single required parameter task_id, including its type and a numeric description. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.
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 states a clear verb ('restore') and resource ('task'), and explicitly frames the operation as undoing remove_task, which distinguishes it from the sibling remove_task tool. An agent can tell exactly what this tool does without opening the schema.
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 gives clear context for when to use the tool: after remove_task has been applied and you want to reverse it. It names the related sibling indirectly ('remove_task') but does not provide explicit exclusions or mention alternative restore paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden. It indicates a mutating operation ('Create') and discloses a non-obvious default: falling back to VIKUNJA_DEFAULT_PROJECT_ID when project_id is omitted. It does not enumerate every side effect, but the schema already documents label auto-creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded and the fallback detail is placed exactly where it adds value without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with a fully described input schema and an output schema, the description is nearly complete: it states the purpose and the only non-schema behavior that matters at selection time. A minor gap is that it doesn't mention label auto-creation or project validation, though both are partially covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds meaningful semantics beyond the schema by explaining the project_id fallback behavior, which is not stated in the parameter description.
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 a specific verb and resource: 'Create a task in a project.' This clearly distinguishes it from create_project, update_task, list_tasks, and other siblings, and the added project context narrows the scope.
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 gives a clear context (creating a task in a project) and a practical fallback rule for omitted project_id. It does not explicitly state alternatives or when-not-to-use conditions, but the action verb makes the primary use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, and the description adds a valuable non-obvious default: removed tasks are hidden unless include_removed is true, and filter_include_nulls defaults to true in that context. This goes beyond the schema and helps predict results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and then the key edge-case behavior. No filler or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage, a read-only annotation, and an output schema, the description does not need to explain returns or every parameter. It covers the main purpose and the most surprising filtering default; a slightly broader note about query/filter options would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 11 parameters are described in the schema, so the baseline is met. The description adds extra meaning for include_removed and filter_include_nulls by explaining their interaction and defaulting behavior, which is not obvious from the individual parameter descriptions.
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?
States a specific verb ('List'), a resource ('tasks'), and an optional project scope, making its function immediately clear. The plural form distinguishes it from get_task, and the resource separates it from list_projects/list_labels.
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 first sentence clearly frames when to call it: whenever a collection of tasks is needed, optionally narrowed to one project. It does not explicitly name alternatives or exclusions, so an agent must infer that get_task covers single-task lookups. That keeps this just below the most explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotentHint=true, destructiveHint=false), the description explains that nothing is actually deleted, the task remains in Vikunja, and it becomes hidden from list_tasks. This adds meaningful behavioral context about side effects and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the core action, the second clarifies the non-destructive behavior and points to the undo tool. Every sentence earns its place, and the key distinction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema present and annotations already covering idempotency/safety, the description fully covers the important context: what happens, what does not happen, and how to reverse it. No essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, task_id, is already described as a numeric task id. The tool description adds no additional parameter-level meaning, but none is needed given the schema is complete for a single simple parameter.
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 states a specific verb ('Mark') plus resource ('a task') and the exact mechanism ('attaching the configured removal label'). It clearly distinguishes itself from deletion and from restore_task, so an agent can tell it apart from siblings without ambiguity.
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 gives clear context: this tool hides a task from list_tasks without deleting it, and it names restore_task as the undo path. It implies when to use it versus alternatives, though it does not explicitly list exclusions or when another tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses important behavior: partial updates, project_id moving the task, and clear_fields resetting fields. It does not cover side effects like permissions or reversibility, but the key update semantics are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences deliver the core semantics first, then special-case behavior. No filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the detailed per-parameter schema and the presence of an output schema, the description covers the high-level behavior an agent needs: partial update, move semantics, and clearing. Nothing essential for selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds crucial meaning beyond the schema by clarifying that omitted parameters are untouched and that null/clear operations go through clear_fields, resolving the ambiguity in nullable parameters.
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 states the specific operation: 'Partially update a task' and adds the defining nuance that omitted fields are left untouched. This clearly distinguishes it from full-replacement updates and from sibling tools like create_task and remove_task.
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?
It gives clear usage context: use this for partial updates, and use clear_fields when the goal is to empty a field rather than change it. It does not explicitly compare against sibling tools, but the partial-update framing is enough to route the agent correctly.
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:

[![vikunjia-mcp MCP server](https://glama.ai/mcp/servers/semaputnik/vikunjia-mcp/badges/card.svg)](https://glama.ai/mcp/servers/semaputnik/vikunjia-mcp)

Score Badge

Copy to your README.md:

[![vikunjia-mcp MCP server](https://glama.ai/mcp/servers/semaputnik/vikunjia-mcp/badges/score.svg)](https://glama.ai/mcp/servers/semaputnik/vikunjia-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/semaputnik/vikunjia-mcp'

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