Skip to main content
Glama
blizzy78

Task Manager MCP Server

by blizzy78

Update tasks

update_task

Modify task status, properties, and dependencies while capturing lessons learned to inform future work. Use before and after task execution, updating multiple tasks together when possible.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYesThe tasks to update

Implementation Reference

  • The primary handler function for the 'update_task' tool. It processes updates for multiple tasks using handleUpdateSingleTask, computes incomplete tasks order, and returns structured results.
    export async function handleUpdateTask({ tasks }: UpdateTaskArgs, taskDB: TaskDB, singleAgent: boolean) {
      const updatedTasks = new Array<Task>()
    
      for (const taskUpdate of tasks) {
        const task = handleUpdateSingleTask(taskUpdate, taskDB)
        updatedTasks.push(task)
      }
    
      const taskID = tasks.map((t) => t.taskID)[0]
      const incompleteTaskIDs = taskDB.incompleteTasksInTree(taskID).map((t) => t.taskID)
    
      const res = {
        tasksUpdated: updatedTasks.map((t) =>
          toBasicTaskInfo(t, false, t.status !== DoneStatus && t.status !== FailedStatus, t.status === TodoStatus)
        ),
        incompleteTasksIdealOrder: singleAgent ? incompleteTaskIDs : undefined,
      }
    
      return {
        content: [],
        structuredContent: res,
      } satisfies CallToolResult
    }
  • Zod schemas defining the input validation for the update_task tool: TaskUpdateSchema for single task updates and UpdateTaskArgsSchema for multiple tasks.
    const TaskUpdateSchema = z.object({
      taskID: TaskIDSchema.describe('The identifier of the task to change status'),
    
      set: z
        .object({
          status: TaskStatusSchema.optional().describe('The new status of this task'),
          title: TaskTitleSchema.optional(),
          description: TaskDescriptionSchema.optional(),
          goal: TaskGoalSchema.optional(),
          criticalPath: TaskCriticalPathSchema.optional(),
          estimatedComplexity: TaskComplexitySchema.optional(),
        })
        .optional()
        .describe('Optional properties to update on this task'),
    
      add: z
        .object({
          dependsOnTaskIDs: TaskIDSchema.array().min(1).optional().describe('New tasks that this task depends on'),
          definitionsOfDone: TaskDefinitionsOfDoneSchema.optional(),
          uncertaintyAreas: TaskUncertaintyAreasSchema.optional(),
          lessonsLearned: z
            .string()
            .min(1)
            .array()
            .min(1)
            .optional()
            .describe('Lessons learned while executing this task that may inform future tasks'),
          verificationEvidence: z
            .string()
            .min(1)
            .array()
            .min(1)
            .optional()
            .describe(
              'Verification evidence that this task was executed as planned, and that the definitions of done were met'
            ),
        })
        .optional()
        .describe('Optional properties to add to this task'),
    
      remove: z
        .object({
          dependsOnTaskIDs: TaskIDSchema.array().min(1).optional().describe('Tasks that this task no longer depends on'),
        })
        .optional()
        .describe('Optional properties to remove from this task'),
    })
    
    type TaskUpdate = z.infer<typeof TaskUpdateSchema>
    
    export const UpdateTaskArgsSchema = z.object({
      tasks: TaskUpdateSchema.array().min(1).describe('The tasks to update'),
    })
    
    type UpdateTaskArgs = z.infer<typeof UpdateTaskArgsSchema>
  • Helper function that applies a single task update, including status transition validations, property sets/adds/removes, and dependency checks.
    function handleUpdateSingleTask({ taskID, set, add, remove }: TaskUpdate, taskDB: TaskDB) {
      const task = taskDB.get(taskID)
      if (!task) {
        throw new Error(`Task not found: ${taskID}`)
      }
    
      if (set) {
        const { status: newStatus, title, description, goal, criticalPath, estimatedComplexity } = set
    
        const oldStatus = task.status
    
        const critPathDepsNotDone = task.dependsOnTaskIDs.filter((depTaskID) => {
          const depTask = taskDB.get(depTaskID)!
          return depTask.criticalPath && depTask.status !== 'done'
        })
    
        const transitionValidations: Array<{ from?: TaskStatus; to: TaskStatus; validate: () => void }> = [
          {
            from: DoneStatus,
            to: FailedStatus,
    
            validate() {
              throw new Error(`Can't transition from ${oldStatus} to ${newStatus}`)
            },
          },
    
          {
            from: FailedStatus,
            to: DoneStatus,
    
            validate() {
              throw new Error(`Can't transition from ${oldStatus} to ${newStatus}`)
            },
          },
    
          {
            to: DoneStatus,
    
            validate() {
              if (critPathDepsNotDone.length > 0) {
                throw new Error(
                  `Can't transition task ${taskID} to ${newStatus}: Critical path dependencies are not ${DoneStatus}: ${critPathDepsNotDone.join(
                    ', '
                  )}`
                )
              }
            },
          },
        ]
    
        transitionValidations
          .filter((tv) => !tv.from || tv.from === oldStatus)
          .filter((tv) => tv.to === newStatus)
          .forEach((tv) => tv.validate())
    
        if (newStatus) {
          task.status = newStatus
        }
    
        if (title) {
          task.title = title
        }
    
        if (description) {
          task.description = description
        }
    
        if (goal) {
          task.goal = goal
        }
    
        if (typeof criticalPath !== 'undefined') {
          task.criticalPath = criticalPath
        }
    
        if (estimatedComplexity) {
          task.estimatedComplexity = estimatedComplexity
        }
      }
    
      if (add) {
        const {
          definitionsOfDone: addDefinitionsOfDone,
          uncertaintyAreas: addUncertaintyAreas,
          lessonsLearned: addLessonsLearned,
          verificationEvidence: addVerificationEvidence,
        } = add
    
        if (addDefinitionsOfDone) {
          task.definitionsOfDone.push(...addDefinitionsOfDone)
        }
    
        if (addUncertaintyAreas) {
          task.uncertaintyAreas.push(...addUncertaintyAreas)
        }
    
        if (addLessonsLearned) {
          task.lessonsLearned.push(...addLessonsLearned)
        }
    
        if (addVerificationEvidence) {
          task.verificationEvidence.push(...addVerificationEvidence)
        }
      }
    
      if (remove) {
        const { dependsOnTaskIDs: removeDependsOnTaskIDs } = remove
    
        if (removeDependsOnTaskIDs) {
          task.dependsOnTaskIDs = task.dependsOnTaskIDs.filter((depTaskID) => !removeDependsOnTaskIDs.includes(depTaskID))
        }
      }
    
      return task
    }
  • tools/index.ts:34-37 (registration)
    Registration of the update_task tool in the central toolHandlers map, mapping the name to its handler and schema.
    [UPDATE_TASK]: {
      handler: handleUpdateTask,
      schema: UpdateTaskArgsSchema,
    } satisfies ToolHandlerInfo,
  • Tool definition object for update_task, used in the tools() export array for tool listing.
    export const updateTaskTool = {
      name: UPDATE_TASK,
      title: 'Update tasks',
      description: `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.`,
      inputSchema: zodToJsonSchema(UpdateTaskArgsSchema, { $refStrategy: 'none' }),
    }
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.

Install Server

Other Tools

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