Skip to main content
Glama

plan_task

Define task objectives, establish success criteria, and outline requirements to structure workflows effectively. Optionally reference prior tasks for continuity and improved planning.

Instructions

Initialize and detail the task flow, establish clear goals and success criteria, optionally reference existing tasks for continuation planning

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
descriptionYesComplete detailed task problem description, should include task objectives, background and expected outcomes
existingTasksReferenceNoWhether to reference existing tasks as a planning basis, used for task adjustment and continuity planning
requirementsNoSpecific technical requirements, business constraints or quality standards for the task (optional)

Implementation Reference

  • The main handler function for the plan_task tool. Prepares context (loading existing tasks if needed), generates a prompt with getPlanTaskPrompt including task details and memory directory, and returns MCP-formatted text content.
    export async function planTask({
      description,
      requirements,
      existingTasksReference = false,
    }: z.infer<typeof planTaskSchema>) {
      // Get base directory path
      const __filename = fileURLToPath(import.meta.url);
      const __dirname = path.dirname(__filename);
      const PROJECT_ROOT = path.resolve(__dirname, "../..");
      const DATA_DIR = process.env.DATA_DIR || path.join(PROJECT_ROOT, "data");
      const MEMORY_DIR = path.join(DATA_DIR, "memory");
    
      // Prepare required parameters
      let completedTasks: Task[] = [];
      let pendingTasks: Task[] = [];
    
      // When existingTasksReference is true, load all tasks from the database as reference
      if (existingTasksReference) {
        try {
          const allTasks = await getAllTasks();
    
          // Split tasks into completed and pending categories
          completedTasks = allTasks.filter(
            (task) => task.status === TaskStatus.COMPLETED
          );
          pendingTasks = allTasks.filter(
            (task) => task.status !== TaskStatus.COMPLETED
          );
        } catch (error) {}
      }
    
      // Use prompt generator to get the final prompt
      const prompt = getPlanTaskPrompt({
        description,
        requirements,
        existingTasksReference,
        completedTasks,
        pendingTasks,
        memoryDir: MEMORY_DIR,
      });
    
      return {
        content: [
          {
            type: "text" as const,
            text: prompt,
          },
        ],
      };
    }
  • Zod schema defining input parameters for plan_task: required detailed description, optional requirements and existingTasksReference flag.
    export const planTaskSchema = z.object({
      description: z
        .string()
        .min(10, {
          message: "Task description cannot be less than 10 characters, please provide a more detailed description to ensure clear task objectives",
        })
        .describe("Complete detailed task problem description, should include task objectives, background and expected outcomes"),
      requirements: z
        .string()
        .optional()
        .describe("Specific technical requirements, business constraints or quality standards for the task (optional)"),
      existingTasksReference: z
        .boolean()
        .optional()
        .default(false)
        .describe("Whether to reference existing tasks as a planning basis, used for task adjustment and continuity planning"),
    });
  • src/index.ts:229-233 (registration)
    Registration of the plan_task tool in the MCP server's ListTools handler, specifying name, description from template, and input schema.
    {
      name: "plan_task",
      description: loadPromptFromTemplate("toolsDescription/planTask.md"),
      inputSchema: zodToJsonSchema(planTaskSchema),
    },
  • src/index.ts:384-394 (registration)
    Dispatch logic in the MCP server's CallTool handler for plan_task: parses arguments with schema, calls the planTask handler if valid.
    case "plan_task":
      parsedArgs = await planTaskSchema.safeParseAsync(
        request.params.arguments
      );
      if (!parsedArgs.success) {
        throw new Error(
          `Invalid arguments for tool ${request.params.name}: ${parsedArgs.error.message}`
        );
      }
      result = await planTask(parsedArgs.data);
      return result;
  • TypeScript interface matching the planTask input args for type safety.
    export interface PlanTaskArgs {
      description: string; // Comprehensive and detailed task problem description, should include task objectives, background, and expected outcomes
      requirements?: string; // Specific technical requirements, business constraints, or quality standards for the task (optional)
    }
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 mentions 'Initialize and detail' and 'establish clear goals', which implies a creation/mutation operation, but doesn't specify if this creates a persistent task record, requires permissions, or has side effects. For a tool with no annotation coverage, this is a significant gap in transparency about its behavior and potential impacts.

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 two concise sentences that front-load key actions ('Initialize and detail', 'establish clear goals'). Every phrase earns its place by contributing to understanding the tool's purpose, though it could be slightly more structured (e.g., separating core and optional functions). No wasted words or redundancy.

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 the complexity (a planning tool with 3 parameters, no output schema, and no annotations), the description is minimally adequate. It covers the high-level purpose but lacks details on behavioral traits, output expectations, or integration with sibling tools. Without annotations or output schema, more context on what the tool returns or how it fits into the task workflow would improve 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 three parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how 'existingTasksReference' interacts with planning or provide examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.

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 with specific verbs ('Initialize and detail', 'establish clear goals and success criteria') and identifies the resource ('task flow'). It distinguishes from siblings like 'execute_task' or 'complete_task' by focusing on planning rather than execution or completion. However, it doesn't explicitly differentiate from 'analyze_task' or 'split_tasks' which might also involve task analysis or decomposition.

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 for initializing and detailing tasks with optional reference to existing tasks, which suggests it's for planning phases. However, it doesn't explicitly state when to use this versus alternatives like 'init_project_rules' for broader project setup or 'split_tasks' for breaking down tasks. No exclusions or clear alternatives are provided, leaving some ambiguity.

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/liorfranko/mcp-chain-of-thought'

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