Skip to main content
Glama

update_task

Modify a specific task by ID with new information or context, appending or replacing details as needed. Supports research-backed updates and integrates with project directories for efficient task management in AI-driven development.

Instructions

Updates a single task by ID with new information or context provided in the prompt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appendNoAppend timestamped information to task details instead of full update
fileNoAbsolute path to the tasks file
idYesID of the task (e.g., '15') to update. Subtasks are supported using the update-subtask tool.
projectRootYesThe directory of the project. Must be an absolute path.
promptYesNew information or context to incorporate into the task
researchNoUse Perplexity AI for research-backed updates
tagNoTag context to operate on

Implementation Reference

  • Registers the 'update_task' MCP tool on the server, including schema, description, and execute handler function.
    export function registerUpdateTaskTool(server) {
    	server.addTool({
    		name: 'update_task',
    		description:
    			'Updates a single task by ID with new information or context provided in the prompt.',
    		parameters: z.object({
    			id: z
    				.string() // ID can be number or string like "1.2"
    				.describe(
    					"ID of the task (e.g., '15') to update. Subtasks are supported using the update-subtask tool."
    				),
    			prompt: z
    				.string()
    				.describe('New information or context to incorporate into the task'),
    			research: z
    				.boolean()
    				.optional()
    				.describe('Use Perplexity AI for research-backed updates'),
    			append: z
    				.boolean()
    				.optional()
    				.describe(
    					'Append timestamped information to task details instead of full update'
    				),
    			file: z.string().optional().describe('Absolute path to the tasks file'),
    			projectRoot: z
    				.string()
    				.describe('The directory of the project. Must be an absolute path.'),
    			tag: z.string().optional().describe('Tag context to operate on')
    		}),
    		execute: withNormalizedProjectRoot(async (args, { log, session }) => {
    			const toolName = 'update_task';
    			try {
    				const resolvedTag = resolveTag({
    					projectRoot: args.projectRoot,
    					tag: args.tag
    				});
    				log.info(
    					`Executing ${toolName} tool with args: ${JSON.stringify(args)}`
    				);
    
    				let tasksJsonPath;
    				try {
    					tasksJsonPath = findTasksPath(
    						{ projectRoot: args.projectRoot, file: args.file },
    						log
    					);
    					log.info(`${toolName}: Resolved tasks path: ${tasksJsonPath}`);
    				} catch (error) {
    					log.error(`${toolName}: Error finding tasks.json: ${error.message}`);
    					return createErrorResponse(
    						`Failed to find tasks.json: ${error.message}`
    					);
    				}
    
    				// 3. Call Direct Function - Include projectRoot
    				const result = await updateTaskByIdDirect(
    					{
    						tasksJsonPath: tasksJsonPath,
    						id: args.id,
    						prompt: args.prompt,
    						research: args.research,
    						append: args.append,
    						projectRoot: args.projectRoot,
    						tag: resolvedTag
    					},
    					log,
    					{ session }
    				);
    
    				// 4. Handle Result
    				log.info(
    					`${toolName}: Direct function result: success=${result.success}`
    				);
    				return handleApiResult({
    					result,
    					log: log,
    					errorPrefix: 'Error updating task',
    					projectRoot: args.projectRoot
    				});
    			} catch (error) {
    				log.error(
    					`Critical error in ${toolName} tool execute: ${error.message}`
    				);
    				return createErrorResponse(
    					`Internal tool error (${toolName}): ${error.message}`
    				);
    			}
    		})
    	});
    }
  • The execute handler for the update_task tool. Resolves project paths, finds tasks.json, calls the direct update function, and handles the API result.
    execute: withNormalizedProjectRoot(async (args, { log, session }) => {
    	const toolName = 'update_task';
    	try {
    		const resolvedTag = resolveTag({
    			projectRoot: args.projectRoot,
    			tag: args.tag
    		});
    		log.info(
    			`Executing ${toolName} tool with args: ${JSON.stringify(args)}`
    		);
    
    		let tasksJsonPath;
    		try {
    			tasksJsonPath = findTasksPath(
    				{ projectRoot: args.projectRoot, file: args.file },
    				log
    			);
    			log.info(`${toolName}: Resolved tasks path: ${tasksJsonPath}`);
    		} catch (error) {
    			log.error(`${toolName}: Error finding tasks.json: ${error.message}`);
    			return createErrorResponse(
    				`Failed to find tasks.json: ${error.message}`
    			);
    		}
    
    		// 3. Call Direct Function - Include projectRoot
    		const result = await updateTaskByIdDirect(
    			{
    				tasksJsonPath: tasksJsonPath,
    				id: args.id,
    				prompt: args.prompt,
    				research: args.research,
    				append: args.append,
    				projectRoot: args.projectRoot,
    				tag: resolvedTag
    			},
    			log,
    			{ session }
    		);
    
    		// 4. Handle Result
    		log.info(
    			`${toolName}: Direct function result: success=${result.success}`
    		);
    		return handleApiResult({
    			result,
    			log: log,
    			errorPrefix: 'Error updating task',
    			projectRoot: args.projectRoot
    		});
    	} catch (error) {
    		log.error(
    			`Critical error in ${toolName} tool execute: ${error.message}`
    		);
    		return createErrorResponse(
    			`Internal tool error (${toolName}): ${error.message}`
    		);
    	}
    })
  • Input parameter schema (Zod) for the update_task tool defining id, prompt, optional research, append, file, projectRoot, and tag.
    parameters: z.object({
    	id: z
    		.string() // ID can be number or string like "1.2"
    		.describe(
    			"ID of the task (e.g., '15') to update. Subtasks are supported using the update-subtask tool."
    		),
    	prompt: z
    		.string()
    		.describe('New information or context to incorporate into the task'),
    	research: z
    		.boolean()
    		.optional()
    		.describe('Use Perplexity AI for research-backed updates'),
    	append: z
    		.boolean()
    		.optional()
    		.describe(
    			'Append timestamped information to task details instead of full update'
    		),
    	file: z.string().optional().describe('Absolute path to the tasks file'),
    	projectRoot: z
    		.string()
    		.describe('The directory of the project. Must be an absolute path.'),
    	tag: z.string().optional().describe('Tag context to operate on')
    }),
  • Response schema for update_task tool, defining the structure of the updated task object.
    import { z } from 'zod';
    import { UpdatedTaskSchema } from './update-tasks.js';
    
    export const UpdateTaskResponseSchema = z.object({
    	task: UpdatedTaskSchema
    });
  • Maps 'update_task' to its registration function in the central tool registry.
    update_task: registerUpdateTaskTool,
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 the tool 'updates' a task, implying a mutation, but doesn't clarify critical aspects like permission requirements, whether updates are reversible, how conflicts are handled, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and potential side effects.

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, well-structured sentence that efficiently conveys the core action: 'Updates a single task by ID with new information or context provided in the prompt.' It is front-loaded with the main purpose, avoids redundancy, and uses no unnecessary words, making it highly concise and easy to parse.

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 complexity (7 parameters, mutation operation) and lack of annotations or output schema, the description is insufficiently complete. It doesn't address behavioral risks, error conditions, or output expectations. For a task-update tool in a system with many sibling tools (e.g., 'update_subtask', 'set_task_status'), more context is needed to guide proper selection and usage, leaving the agent under-informed.

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 description mentions 'new information or context provided in the prompt,' which loosely relates to the 'prompt' parameter, but adds minimal semantic value beyond the schema. With 100% schema description coverage, the schema already documents all 7 parameters thoroughly. The description doesn't explain parameter interactions (e.g., how 'append' modifies 'prompt' behavior) or provide usage examples, so it meets the baseline but doesn't enhance understanding.

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: 'Updates a single task by ID with new information or context provided in the prompt.' It specifies the verb ('Updates'), resource ('a single task'), and key identifier ('by ID'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_subtask' or 'set_task_status', which would require a more specific comparison.

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 minimal guidance on when to use this tool. It mentions 'Subtasks are supported using the update-subtask tool' in the input schema, but this is not part of the description text itself. The description lacks explicit when-to-use scenarios, prerequisites, or comparisons to alternatives like 'update_subtask' or 'set_task_status', leaving the agent with little contextual direction.

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

Related 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/eyaltoledano/claude-task-master'

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