Skip to main content
Glama
blizzy78

Task Manager MCP Server

by blizzy78
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Task Manager MCP Server

This MCP server allows agents to orchestrate task workflows through exploration. It provides structured task management capabilities for agents working on complex multi-step problems:

  • Create and organize tasks in hierarchical structures with dependencies

  • Decompose complex tasks into smaller, more manageable subtasks with sequence ordering

  • Track task progression through defined states (todo, in-progress, done, failed)

  • Orchestrate workflows with proper dependency validation and critical path tracking

The tools have been tested extensively and successfully with GitHub Copilot in VS Code, and Claude Sonnet 4. (GPT-4.1 and GPT-5 do not seem to work very well unfortunately.)

Note: When using this MCP server, you should disable the Todo List tool in VS Code.

Tools

  1. create_task

    • Creates a new task that must be executed. If decomposing a complex task is required, must use 'decompose_task' first before executing it. All tasks start in the todo status. Must use 'update_task' before executing this task, and when executing this task has finished.

    • Inputs:

      • title (string): A concise title for this task. Must be understandable out of context

      • description (string): A detailed description of this task. Must be understandable out of context

      • goal (string): The overall goal of this task. Must be understandable out of context

      • definitionsOfDone (array of strings): A detailed list of criteria that must be met for this task to be considered 'complete'. Must be understandable out of context

      • criticalPath (boolean): Whether this task is on the critical path and required for completion

      • estimatedComplexity (object): An estimate of the complexity of this task, containing:

        • level (enum): One of "trivial", "low, may benefit from decomposition before execution", "average, must decompose before execution", "medium, must decompose before execution", "high, must decompose before execution"

        • description (string): A description of the complexity of this task

      • uncertaintyAreas (array of objects): A detailed list of areas where there is uncertainty about this task's requirements or execution, each containing:

        • title (string): A concise title for this uncertainty area

        • description (string): A description of this uncertainty area

    • Behavior:

      • All tasks start in the todo status

      • Must use 'update_task' before executing this task, and when executing this task has finished

      • If decomposing a complex task is required, must use 'decompose_task' first before executing it

    • Returns: Confirmation including the created task

  2. decompose_task

    • Decomposes an existing complex task into smaller, more manageable subtasks. All tasks with complexity higher than low must always be decomposed before execution. Subtasks with the same sequence order may be executed in parallel. Subtasks should include a verification subtask.

    • Inputs:

      • taskID (string): The task to decompose

      • decompositionReason (string): The reason for decomposing this task

      • subtasks (array of objects): Array of smaller, manageable subtasks to create, each containing:

        • title (string): A concise title for this subtask. Must be understandable out of context

        • description (string): A detailed description of this subtask. Must be understandable out of context

        • goal (string): The overall goal of this subtask. Must be understandable out of context

        • definitionsOfDone (array of strings): A detailed list of criteria that must be met for this subtask to be considered 'complete'. Must be understandable out of context

        • criticalPath (boolean): Whether this subtask is on the critical path and required for completion of this task

        • uncertaintyAreas (array of objects): Areas where there is uncertainty about this subtask's requirements or execution, each containing:

          • title (string): A concise title for this uncertainty area

          • description (string): A description of this uncertainty area

        • sequenceOrder (number): The sequence order of this subtask. Subtasks with the same order may be executed in parallel

    • Behavior:

      • All tasks with complexity higher than low must always be decomposed before executing

      • Subtasks with the same sequence order may be executed in parallel

      • Creates dependency chains based on sequence order (later sequences depend on earlier ones)

      • Subtasks should include a verification subtask

    • Returns: Confirmation including the created subtasks and updated parent task

  3. update_task

    • Updates the status and/or other properties of a task

    • Inputs:

      • tasks (array of objects): The tasks to update, each containing:

        • taskID (string): The identifier of the task to change status

        • set (object, optional): Optional properties to update on this task, containing:

          • status (enum, optional): The new status ("todo", "in-progress", "done", or "failed")

          • title (string, optional): A concise title for this task. Must be understandable out of context

          • description (string, optional): A detailed description of this task. Must be understandable out of context

          • goal (string, optional): The overall goal of this task. Must be understandable out of context

          • criticalPath (boolean, optional): Whether this task is on the critical path and required for completion

          • estimatedComplexity (object, optional): An estimate of the complexity of this task

        • add (object, optional): Optional properties to add to this task, containing:

          • dependsOnTaskIDs (array of strings, optional): New tasks that this task depends on

          • definitionsOfDone (array of strings, optional): Additional criteria that must be met for this task to be considered 'complete'

          • uncertaintyAreas (array of objects, optional): Additional areas where there is uncertainty about this task's requirements or execution

          • lessonsLearned (array of strings, optional): Lessons learned while executing this task that may inform future tasks

          • verificationEvidence (array of strings, optional): Verification evidence that this task was executed as planned, and that the definitions of done were met

        • remove (object, optional): Optional properties to remove from this task, containing:

          • dependsOnTaskIDs (array of strings, optional): Tasks that this task no longer depends on

    • Behavior:

      • Must use this tool before executing a task, and when executing a task has finished

      • Can be used to set the status of multiple tasks at once if their dependencies allow it

      • Should always include lessons learned to inform future tasks, if possible

      • Tasks can only transition to "done" if all critical path dependencies are completed

      • Validates status transitions and dependencies before allowing changes

      • Cannot transition from "done" to "failed" or vice versa

    • Returns: Status transition confirmation including the updated tasks

  4. task_info

    • Returns full details for requested tasks

    • Inputs:

      • taskIDs (array of strings): A list of task IDs to retrieve information for

    • Behavior:

      • Returns full task details including all properties (status, dependencies, descriptions, etc.)

      • Handles missing task IDs gracefully by returning them in a separate list

    • Returns: Object containing arrays of found tasks and any not found task IDs

  5. current_task (single agent mode only)

    • Returns a list of tasks that are currently in progress.

    • Inputs: None

    • Behavior:

      • Only available when single agent mode is enabled (SINGLE_AGENT=true)

      • Filters tasks to return only those currently in progress

      • Useful for agents to recover task context after conversation history compacting

    • Returns: Object containing array of current tasks

Related MCP server: pith

Single Agent Mode

The task manager supports a special "single agent mode" that can be enabled by setting the environment variable SINGLE_AGENT=true. In this mode, the server will provide the additional current_task tool.

This is useful for long-running agents where the agent loop is compacting/summarizing the agent's conversation history to prevent exceeding the context window limit. In these cases, the agent may "forget" which tasks exist because the task IDs have been removed from the context window. Single agent mode allows the agent to use the current_task tool, enabling it to recover information about the current task tree.

Do not enable single agent mode if you plan to use this MCP server with multiple agents at the same time. If enabled, only one agent should use the MCP server at any one time.

Enabling Single Agent Mode

Set the environment variable before starting the server:

SINGLE_AGENT=true npx @blizzy/mcp-task-manager

Or in Claude Desktop configuration:

{
  "mcpServers": {
    "task-manager": {
      "command": "npx",
      "args": ["-y", "@blizzy/mcp-task-manager"],
      "env": {
        "SINGLE_AGENT": "true"
      }
    }
  }
}

Recommended Agent Prompt Snippets

Instructions section

# Agent Instructions

For any user request, DO THIS FIRST: Use the Task Management tools to create a new task for the user's request. Always add these uncertainty areas as the first ones to the task:
1. Project overview as documented in README.md and CLAUDE.md
2. Project configuration, such as test commands

Resolve the user's request completely by executing all incomplete tasks. Doing so may include:

- Gathering information or doing research
- Writing or editing code or other content
- Fixing problems
- etc.

Use all tools available to you to help you in executing tasks, as appropriate. This includes:

- Use the Task Management Tools to manage your tasks. Always use these tools to manage your tasks.
- Use the Reasoning Tools to gather information and do research, work structured and logically, and stay on track. It is very important to use these tools often to execute tasks effectively.
- Use the Web Access Tools to gather information and do research. Use these tools as needed.

Always follow the Agent Rules, especially when writing or editing code or other content.

Keep executing tasks until all tasks are complete. The user's request is considered resolved once all tasks are complete.

Task Management tools section

# Task Management Tools

You must use the following tools to manage and organize your tasks. This is essential for effective task tracking, prioritization, and ensuring that all steps are completed in the correct order. Using these tools will help you maintain clear oversight of your work and dependencies throughout the process.

'create_task' allows you to create a new task that needs to be executed. If decomposing a complex task is required, you must use 'decompose_task' to break it down into smaller, more manageable subtasks.

Pay attention that tasks can depend on each other. You may need to execute them in a specific order. Always check the dependencies of a task before executing it, and complete the dependencies first.

Usage with Claude Desktop (uses stdio Transport)

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "task-manager": {
      "command": "npx",
      "args": [
        "-y",
        "@blizzy/mcp-task-manager"
      ]
    }
  }
}

Usage with VS Code

For quick installation, use of of the one-click install buttons below.

Install with NPX in VS Code Install with NPX in VS Code Insiders

Install with Docker in VS Code Install with Docker in VS Code Insiders

For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).

Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.

Note that the mcp key is not needed in the .vscode/mcp.json file.

NPX

{
  "mcp": {
    "servers": {
      "task-manager": {
        "command": "npx",
        "args": ["-y", "@blizzy/mcp-task-manager"]
      }
    }
  }
}

Running from source with HTTP+SSE Transport (deprecated as of 2025-03-26)

pnpm install
pnpm run start:sse

Run from source with Streamable HTTP Transport

pnpm install
pnpm run start:streamableHttp

Running as an installed package

Install

npm install -g @blizzy/mcp-task-manager@latest

Run the default (stdio) server

npx @blizzy/mcp-task-manager

Or specify stdio explicitly

npx @blizzy/mcp-task-manager stdio

Run the SSE server

npx @blizzy/mcp-task-manager sse

Run the streamable HTTP server

npx @blizzy/mcp-task-manager streamableHttp

License

This package is licensed under the MIT license.

Available Tools

5 tools
create_taskCreate taskA

Creates a new task that must be executed. If decomposing a complex task is required, must use 'decompose_task' first before executing it. All tasks start in the todo status. Must use 'update_task' before executing this task, and when executing this task has finished.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesA concise title for this task. Must be understandable out of context
descriptionYesA detailed description of this task. Must be understandable out of context
goalYesThe overall goal of this task. Must be understandable out of context
criticalPathYesWhether this task is on the critical path and required for completion
definitionsOfDoneYesA detailed list of criteria that must be met for this task to be considered 'complete'. Must be understandable out of context.
uncertaintyAreasYesA detailed list of areas where there is uncertainty about this task's requirements or execution. Must be understandable out of context. May be empty.
estimatedComplexityYesAn estimate of the complexity of this task. All tasks with complexity higher than low must be decomposed into smaller, more manageable subtasks before execution. Caution: Don't underestimate complexity.

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that tasks start in 'todo status' and mentions prerequisites (decompose_task for complexity, update_task before/after execution), which adds useful context. However, it doesn't cover behavioral aspects like error handling, permissions, or what happens on creation (e.g., does it return an ID?). The description adds some value but leaves gaps 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.

Conciseness3/5

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

The description is 4 sentences but could be more front-loaded. The first sentence states the purpose, but the subsequent sentences about decomposition and update_task usage, while important, might be better structured. It's not overly verbose, but the flow could be improved for clarity.

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

Completeness3/5

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

Given no annotations and no output schema, the description provides good usage guidelines and some behavioral context (starting status, prerequisites). However, for a mutation tool with 7 required parameters and complex nested objects, it lacks details on what happens after creation (e.g., success response, error cases). The description is adequate but has clear gaps in completeness.

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 already documents all 7 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Creates a new task that must be executed.' It specifies the verb ('creates') and resource ('task'), but doesn't explicitly differentiate from siblings like 'update_task' or 'decompose_task' beyond mentioning them. The purpose is clear but lacks direct sibling comparison.

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

Usage Guidelines5/5

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

The description provides explicit usage guidelines: 'If decomposing a complex task is required, must use 'decompose_task' first before executing it' and 'Must use 'update_task' before executing this task, and when executing this task has finished.' It clearly states when to use alternatives (decompose_task for complex tasks) and prerequisites (update_task before and after execution).

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

current_taskGet current taskB

Returns a list of tasks that are currently in progress.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list of in-progress tasks, which implies a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or the format of the returned list. For a tool with zero annotation coverage, this is a significant gap in transparency.

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, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded with the core action ('Returns'), making it efficient and easy to parse. Every part of the sentence earns its place by conveying essential information.

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

Completeness2/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. It states what the tool does but lacks context on usage, behavioral traits, or output details. For a tool that returns a list, without an output schema, the description should ideally hint at the return format or structure, but it doesn't, leaving gaps in completeness.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied for zero parameters, as the schema fully handles the parameter semantics without requiring description input.

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

Purpose4/5

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

The description clearly states the verb ('Returns') and resource ('list of tasks that are currently in progress'), making the purpose evident. It distinguishes from siblings like 'create_task' (creation) and 'update_task' (modification) by focusing on retrieval of in-progress tasks. However, it doesn't explicitly differentiate from 'task_info', which might also retrieve task details, leaving some ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'current_task' over 'task_info' (which might get task details) or other siblings, nor does it specify prerequisites or contexts for usage. This lack of explicit when/when-not instructions limits its utility for an AI agent.

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

decompose_taskDecompose taskA

Decomposes an existing complex task into smaller, more manageable subtasks. All tasks with complexity higher than low must always be decomposed before execution. Tasks MUST be in todo status to be decomposed. Subtasks with the same sequence order may be executed in parallel. Subtasks should include a verification subtask. Created subtasks may be decomposed later if needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskIDYesThe task to decompose
decompositionReasonYesThe reason for decomposing this task
subtasksYesArray of smaller, manageable subtasks to create

TDQS

A4.4/5.0
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 of behavioral disclosure. It effectively describes key behavioral traits: the tool creates subtasks (implying mutation), specifies prerequisites (complexity > low, todo status), explains parallel execution logic ('Subtasks with the same sequence order may be executed in parallel'), and notes recursion ('Created subtasks may be decomposed later if needed'). It lacks details on permissions or error handling, but covers substantial operational context.

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 front-loaded with the core purpose in the first sentence, followed by essential guidelines and behavioral notes in concise, bullet-like statements. Every sentence earns its place by providing critical operational rules without redundancy or fluff, making it highly efficient for an agent to parse.

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?

Given the tool's complexity (mutation with multiple behavioral rules) and lack of annotations or output schema, the description does a strong job covering usage context, prerequisites, and behavioral traits. It explains the decomposition logic, parallel execution, and recursion, though it doesn't detail the response format or error scenarios, leaving minor gaps for a mutation tool.

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 already documents all three parameters thoroughly. The description adds no specific parameter semantics beyond what the schema provides (e.g., it doesn't clarify format or constraints for taskID, decompositionReason, or subtasks). The baseline score of 3 reflects adequate coverage by the schema alone.

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

Purpose5/5

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

The description clearly states the specific action ('Decomposes an existing complex task') and resource ('into smaller, more manageable subtasks'), distinguishing it from sibling tools like create_task, update_task, or task_info which handle different task operations. The verb 'decomposes' precisely indicates breaking down rather than creating or modifying.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use criteria: 'All tasks with complexity higher than low must always be decomposed before execution' and 'Tasks MUST be in todo status to be decomposed.' It also implies alternatives by specifying prerequisites, guiding the agent away from using this tool for simple tasks or tasks not in todo status.

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

task_infoGet task infoC

Returns full details for requested tasks

ParametersJSON Schema
NameRequiredDescriptionDefault
taskIDsYesA list of task IDs to retrieve information for

TDQS

C2.6/5.0
Behavior2/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 states this is a read operation ('Returns'), which is helpful, but doesn't cover aspects like whether it requires authentication, rate limits, error handling, or what 'full details' includes (e.g., format, fields). This leaves significant gaps for a tool with no 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.

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with key distinctions from siblings to improve structure, but it's appropriately sized for its purpose.

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

Completeness2/5

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

Given the complexity of a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'full details' means in terms of return values, error cases, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.

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 description coverage is 100%, with the parameter 'taskIDs' well-documented in the schema as 'A list of task IDs to retrieve information for'. The description adds no additional meaning beyond this, such as ID format examples or constraints, so it meets the baseline for high schema coverage without compensating value.

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

Purpose3/5

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

The description 'Returns full details for requested tasks' clearly states the verb ('Returns') and resource ('full details for requested tasks'), but it's somewhat vague about what 'full details' entails and doesn't differentiate from sibling tools like 'current_task' or 'decompose_task'. It's better than a tautology but lacks specificity about what makes this tool distinct.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'current_task' (which might get current task info) or 'decompose_task' (which might break down tasks). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.

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

update_taskUpdate tasksA

Updates the status and/or other properties of one or more tasks. Must use this tool before executing tasks, and when finished executing tasks. Should always include lessons learned to inform future tasks. Important: Always update multiple tasks in a single call if dependencies allow it.

ParametersJSON Schema
NameRequiredDescriptionDefault
tasksYesThe tasks to update

TDQS

A3.8/5.0
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 mentions the tool is for updates (implying mutation) and includes operational rules (e.g., include lessons learned, batch updates), but doesn't cover permissions, error handling, or response format. It adds some context but lacks comprehensive behavioral traits.

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

Conciseness4/5

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

The description is front-loaded with the core purpose, followed by usage guidelines. Each sentence adds value (purpose, timing, content, efficiency), but the second sentence could be more concise (e.g., 'Use before and after execution'). Overall, it's efficient with minimal waste.

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

Completeness3/5

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

Given no annotations, no output schema, and a complex input schema (multiple nested objects), the description is moderately complete. It covers purpose and usage well but lacks details on behavioral aspects like side effects, error conditions, or return values, which are important for a mutation tool with rich parameters.

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 the 'tasks' parameter and its nested properties. The description adds no parameter-specific details beyond implying updates to 'status and/or other properties', which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Updates') and resource ('status and/or other properties of one or more tasks'), making the purpose specific. It distinguishes from siblings like 'create_task' (creation) and 'task_info' (read-only), but doesn't explicitly differentiate from 'decompose_task' (which modifies tasks differently).

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: 'Must use this tool before executing tasks, and when finished executing tasks' (timing), 'Should always include lessons learned' (content requirement), and 'Always update multiple tasks in a single call if dependencies allow it' (efficiency rule). This gives clear when-to-use directives without naming alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • Changedcreate_task11 fields changed
      • addedInput schema / properties / criticalPath
        Added value: +{
+  "description": "Whether this task is on the critical path and required for completion",
+  "type": "boolean"
+}
      • changedInput schema / properties / definitionsOfDone / description
        Previous value: -"A detailed list of criteria that must be met for this task to be considered complete."New value: +"A detailed list of criteria that must be met for this task to be considered 'complete'. Must be understandable out of context."
      • removedInput schema / properties / dependsOnTaskIDs
        Removed value: -{
-  "description": "A list of task identifiers this task depends on. Must be provided if these tasks must be complete before this task can be started.",
-  "items": {
-    "minLength": 1,
-    "type": "string"
-  },
-  "type": "array"
-}
      • changedInput schema / properties / description / description
        Previous value: -"A detailed description of this task."New value: +"A detailed description of this task. Must be understandable out of context"
      • addedInput schema / properties / estimatedComplexity
        Added value: +{
+  "additionalProperties": false,
+  "description": "An estimate of the complexity of this task.\nAll tasks with complexity higher than low must be decomposed into smaller, more manageable subtasks before execution.\nCaution: Don't underestimate complexity.",
+  "properties": {
+    "description": {
+      "description": "A description of the complexity of this task",
+      "minLength": 1,
+      "type": "string"
+    },
+    "level": {
+      "description": "The level of complexity for this task",
+      "enum": [
+        "trivial",
+        "low, may benefit from decomposition before execution",
+        "average, must decompose before execution",
+        "medium, must decompose before execution",
+        "high, must decompose before execution"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "level",
+    "description"
+  ],
+  "type": "object"
+}
      • changedInput schema / properties / goal / description
        Previous value: -"The overall goal of this task."New value: +"The overall goal of this task. Must be understandable out of context"
      • changedInput schema / properties / title / description
        Previous value: -"A concise title for this task."New value: +"A concise title for this task. Must be understandable out of context"
      • changedInput schema / properties / uncertaintyAreas / description
        Previous value: -"A detailed list of areas where there is uncertainty about this task's requirements or execution. May be empty. Ensure list is ordered by priority."New value: +"A detailed list of areas where there is uncertainty about this task's requirements or execution.\nMust be understandable out of context. May be empty."
      • changedInput schema / properties / uncertaintyAreas / items / properties / description / description
        Previous value: -"A description of this uncertainty area."New value: +"A description of this uncertainty area"
      • changedInput schema / properties / uncertaintyAreas / items / properties / title / description
        Previous value: -"A concise title for this uncertainty area."New value: +"A concise title for this uncertainty area"
      • changedInput schema / required
        Previous value: -[
-  "title",
-  "description",
-  "goal",
-  "definitionsOfDone",
-  "dependsOnTaskIDs",
-  "uncertaintyAreas"
-]New value: +[
+  "title",
+  "description",
+  "goal",
+  "criticalPath",
+  "definitionsOfDone",
+  "uncertaintyAreas",
+  "estimatedComplexity"
+]
    • Addedcurrent_task
    • Addeddecompose_task
    • Changedtask_info3 fields changed
      • removedInput schema / properties / taskID
        Removed value: -{
-  "description": "The identifier of a task.",
-  "minLength": 1,
-  "type": "string"
-}
      • addedInput schema / properties / taskIDs
        Added value: +{
+  "description": "A list of task IDs to retrieve information for",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "minItems": 1,
+  "type": "array"
+}
      • changedInput schema / required
        Previous value: -[
-  "taskID"
-]New value: +[
+  "taskIDs"
+]
    • Removedtransition_task_status
    • Changedupdate_task6 fields changed
      • removedInput schema / properties / newDefinitionsOfDone
        Removed value: -{
-  "description": "A detailed list of additional criteria that must be met for this task to be considered complete.",
-  "items": {
-    "minLength": 1,
-    "type": "string"
-  },
-  "minItems": 1,
-  "type": "array"
-}
      • removedInput schema / properties / newDependsOnTaskIDs
        Removed value: -{
-  "description": "A list of additional task identifiers this task depends on.",
-  "items": {
-    "$ref": "#/properties/taskID"
-  },
-  "type": "array"
-}
      • removedInput schema / properties / newUncertaintyAreas
        Removed value: -{
-  "description": "A detailed list of additional areas where there is uncertainty about this task's requirements or execution. May be empty. Ensure list is ordered by priority.",
-  "items": {
-    "additionalProperties": false,
-    "properties": {
-      "description": {
-        "description": "A description of this uncertainty area.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "title": {
-        "description": "A concise title for this uncertainty area.",
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "title",
-      "description"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}
      • removedInput schema / properties / taskID
        Removed value: -{
-  "description": "The identifier of this task.",
-  "minLength": 1,
-  "type": "string"
-}
      • addedInput schema / properties / tasks
        Added value: +{
+  "description": "The tasks to update",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "add": {
+        "additionalProperties": false,
+        "description": "Optional properties to add to this task",
+        "properties": {
+          "definitionsOfDone": {
+            "description": "A detailed list of criteria that must be met for this task to be considered 'complete'. Must be understandable out of context.",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "dependsOnTaskIDs": {
+            "description": "New tasks that this task depends on",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          },
+          "lessonsLearned": {
+            "description": "Lessons learned while executing this task that may inform future tasks",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          },
+          "uncertaintyAreas": {
+            "description": "A detailed list of areas where there is uncertainty about this task's requirements or execution.\nMust be understandable out of context. May be empty.",
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "description": {
+                  "description": "A description of this uncertainty area",
+                  "minLength": 1,
+                  "type": "string"
+                },
+                "title": {
+                  "description": "A concise title for this uncertainty area",
+                  "minLength": 1,
+                  "type": "string"
+                }
+              },
+              "required": [
+                "title",
+                "description"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "verificationEvidence": {
+            "description": "Verification evidence that this task was executed as planned, and that the definitions of done were met",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "remove": {
+        "additionalProperties": false,
+        "description": "Optional properties to remove from this task",
+        "properties": {
+          "dependsOnTaskIDs": {
+            "description": "Tasks that this task no longer depends on",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "set": {
+        "additionalProperties": false,
+        "description": "Optional properties to update on this task",
+        "properties": {
+          "criticalPath": {
+            "description": "Whether this task is on the critical path and required for completion",
+            "type": "boolean"
+          },
+          "description": {
+            "description": "A detailed description of this task. Must be understandable out of context",
+            "minLength": 1,
+            "type": "string"
+          },
+          "estimatedComplexity": {
+            "additionalProperties": false,
+            "description": "An estimate of the complexity of this task.\nAll tasks with complexity higher than low must be decomposed into smaller, more manageable subtasks before execution.\nCaution: Don't underestimate complexity.",
+            "properties": {
+              "description": {
+                "description": "A description of the complexity of this task",
+                "minLength": 1,
+                "type": "string"
+              },
+              "level": {
+                "description": "The level of complexity for this task",
+                "enum": [
+                  "trivial",
+                  "low, may benefit from decomposition before execution",
+                  "average, must decompose before execution",
+                  "medium, must decompose before execution",
+                  "high, must decompose before execution"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "level",
+              "description"
+            ],
+            "type": "object"
+          },
+          "goal": {
+            "description": "The overall goal of this task. Must be understandable out of context",
+            "minLength": 1,
+            "type": "string"
+          },
+          "status": {
+            "description": "The new status of this task",
+            "enum": [
+              "todo",
+              "in-progress",
+              "done",
+              "failed"
+            ],
+            "type": "string"
+          },
+          "title": {
+            "description": "A concise title for this task. Must be understandable out of context",
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "taskID": {
+        "description": "The identifier of the task to change status",
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "taskID"
+    ],
+    "type": "object"
+  },
+  "minItems": 1,
+  "type": "array"
+}
      • changedInput schema / required
        Previous value: -[
-  "taskID",
-  "newDependsOnTaskIDs",
-  "newUncertaintyAreas"
-]New value: +[
+  "tasks"
+]
  2. 4 tool updates
    • First observedcreate_task
    • First observedtask_info
    • First observedtransition_task_status
    • First observedupdate_task
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: create_task for creation, current_task for listing in-progress tasks, decompose_task for breaking down complex tasks, task_info for retrieving details, and update_task for modifying task properties. The descriptions clearly differentiate their roles, with no ambiguity about when to use each tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_task, decompose_task, update_task). The naming is predictable and uniform across all five tools, making it easy for an agent to understand and select the appropriate tool.

Tool Count5/5

With 5 tools, this server is well-scoped for a task management domain. The count is appropriate, covering core operations without being overwhelming or too sparse, and each tool serves a clear, necessary function in the workflow.

Completeness4/5

The tool set provides strong coverage for task management, including creation, decomposition, status updates, and information retrieval. A minor gap exists in the lack of a delete or archive tool for task lifecycle management, but agents can work around this by using update_task to mark tasks as completed or obsolete.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • task-mcp

    maxronner
    A
    license
    A
    quality
    D
    maintenance
    An MCP server for Taskwarrior that implements agent claim and lease semantics for task management. It enables agents to list, create, and modify tasks while ensuring mutual exclusion through a system where tasks must be claimed before they are updated.
    10
    17
    MIT

  • pith

    SiluPanda
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for task management that enables AI agents to read, create, update tasks, and track work sessions, allowing agents and humans to collaborate on the same task board.
    3
    8
    MIT

Appeared in Searches

Latest Blog Posts

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/blizzy78/mcp-task-manager'

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