Skip to main content
Glama

add_subtasks

Break down complex tasks into manageable subtasks within TaskFlow MCP to track progress and ensure all components are completed before marking tasks as done.

Instructions

Add subtasks to an existing task. Provide 'requestId', 'taskId', and 'subtasks' array.

Subtasks are smaller units of work that make up a task. All subtasks must be completed before a task can be marked as done.

A progress table will be displayed showing the updated task with its subtasks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestIdYes
taskIdYes
subtasksYes

Implementation Reference

  • MCP tool handler function for 'add_subtasks' that parses arguments and delegates execution to TaskFlowService.addSubtasks method.
    async add_subtasks(args: any) {
      const { requestId, taskId, subtasks } = args ?? {};
      return service.addSubtasks(String(requestId), String(taskId), subtasks ?? []);
  • Core service method implementing the logic to add subtasks to a specific task in a request: validates, generates IDs with TaskFactory, persists to file, generates progress table.
    public async addSubtasks(
      requestId: string,
      taskId: string,
      subtasks: { title: string; description: string }[]
    ) {
      await this.loadTasks();
      const req = this.getRequest(requestId);
      if (!req) return { status: "error", message: "Request not found" };
    
      const task = req.tasks.find((t) => t.id === taskId);
      if (!task) return { status: "error", message: "Task not found" };
      if (task.done) return { status: "error", message: "Cannot add subtasks to completed task" };
    
      const factory = new TaskFactory({ value: this.globalIdCounter });
      const newSubtasks = subtasks.map((s) => factory.createSubtask(s));
      this.globalIdCounter = factory["counterRef"].value;
    
      task.subtasks.push(...newSubtasks);
      await this.saveTasks();
    
      const progressTable = formatTaskProgressTableForRequest(req);
      return {
        status: "subtasks_added",
        message: `Added ${newSubtasks.length} new subtasks to task ${taskId}.\n${progressTable}`,
        newSubtasks: newSubtasks.map((s) => ({ id: s.id, title: s.title, description: s.description })),
      };
    }
  • Tool definition including name, description, and input JSON schema for validation in MCP.
    export const ADD_SUBTASKS_TOOL: Tool = {
      name: "add_subtasks",
      description:
        "Add subtasks to an existing task. Provide 'requestId', 'taskId', and 'subtasks' array.\n\n" +
        "Subtasks are smaller units of work that make up a task. All subtasks must be completed before a task can be marked as done.\n\n" +
        "A progress table will be displayed showing the updated task with its subtasks.",
      inputSchema: {
        type: "object",
        properties: {
          requestId: { type: "string" },
          taskId: { type: "string" },
          subtasks: {
            type: "array",
            items: {
              type: "object",
              properties: {
                title: { type: "string" },
                description: { type: "string" },
              },
              required: ["title", "description"],
            },
          },
        },
        required: ["requestId", "taskId", "subtasks"],
      },
    };
  • Server registration of all tools including ADD_SUBTASKS_TOOL in the listTools handler, making it discoverable via MCP.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: [
        PLAN_TASK_TOOL,
        GET_NEXT_TASK_TOOL,
        MARK_TASK_DONE_TOOL,
        OPEN_TASK_DETAILS_TOOL,
        LIST_REQUESTS_TOOL,
        ADD_TASKS_TO_REQUEST_TOOL,
        UPDATE_TASK_TOOL,
        DELETE_TASK_TOOL,
        ADD_SUBTASKS_TOOL,
        MARK_SUBTASK_DONE_TOOL,
        UPDATE_SUBTASK_TOOL,
        DELETE_SUBTASK_TOOL,
        EXPORT_TASK_STATUS_TOOL,
        ADD_NOTE_TOOL,
        UPDATE_NOTE_TOOL,
        DELETE_NOTE_TOOL,
        ADD_DEPENDENCY_TOOL,
        GET_PROMPTS_TOOL,
        SET_PROMPTS_TOOL,
        UPDATE_PROMPTS_TOOL,
        REMOVE_PROMPTS_TOOL,
        ARCHIVE_COMPLETED_REQUESTS_TOOL,
        LIST_ARCHIVED_REQUESTS_TOOL,
        RESTORE_ARCHIVED_REQUEST_TOOL,
      ],
    }));
  • Additional JSON schema definition for add_subtasks input validation (jsonSchemas.add_subtasks).
    add_subtasks: {
      type: "object",
      properties: {
        requestId: { type: "string" },
        taskId: { type: "string" },
        subtasks: { type: "array", items: subtaskJson },
      },
      required: ["requestId", "taskId", "subtasks"],
    },
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. It mentions that 'All subtasks must be completed before a task can be marked as done' and that 'A progress table will be displayed', adding some behavioral context about dependencies and output format. However, it lacks critical details like whether this is a mutation (implied by 'add'), what permissions are needed, if there are rate limits, or how errors are handled.

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 appropriately sized with three sentences. The first sentence front-loads the purpose and parameters. The second explains subtasks concisely. The third describes the output behavior. There's minimal waste, though the second sentence could be slightly more integrated.

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 0% schema coverage, the description is moderately complete. It covers the purpose, parameters at a high level, and some behavioral aspects like dependencies and output display. However, it lacks details on error handling, authentication, or the full impact of the mutation, leaving gaps for a tool with three required 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 0%, so the description must compensate. It lists the parameters ('requestId', 'taskId', and 'subtasks array') and explains that subtasks are 'smaller units of work' with 'title' and 'description', adding meaning beyond the bare schema. However, it doesn't detail the purpose of 'requestId' or 'taskId', or provide examples or constraints for the subtasks array.

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 'add' and resource 'subtasks to an existing task', making the purpose specific. It distinguishes from siblings like 'add_tasks_to_request' (which adds tasks to requests) and 'update_subtask' (which modifies existing subtasks). However, it doesn't explicitly contrast with all siblings like 'plan_task' or 'mark_task_done'.

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 by stating 'to an existing task', suggesting prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'update_task' or 'plan_task', nor does it provide exclusions or clear context about when this is the appropriate choice among sibling tools.

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/pinkpixel-dev/taskflow-mcp'

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