Skip to main content
Glama

plan_task

Register user requests, plan associated tasks, and manage subtasks, dependencies, and notes with a structured workflow. Automatically generate task plans and enforce user approval for task completion and request finalization.

Instructions

Register a new user request and plan its associated tasks. You must provide 'originalRequest' and 'tasks', and optionally 'splitDetails'.

Tasks can now include subtasks, which are smaller units of work that make up a task. All subtasks must be completed before a task can be marked as done.

You can also include:

  • 'dependencies': List of project or task-specific dependencies (libraries, tools, etc.)

  • 'notes': General notes about the project (preferences, guidelines, etc.)

  • 'outputPath': Path to save a Markdown file with the task plan for reference. It's recommended to use absolute paths (e.g., 'C:/Users/username/Documents/task-plan.md') rather than relative paths for more reliable file creation.

This tool initiates a new workflow for handling a user's request. The workflow is as follows:

  1. Use 'plan_task' to register a request and its tasks (with optional subtasks, dependencies, and notes).

  2. After adding tasks, you MUST use 'get_next_task' to retrieve the first task. A progress table will be displayed.

  3. Use 'get_next_task' to retrieve the next uncompleted task.

  4. If the task has subtasks, complete each subtask using 'mark_subtask_done' before marking the task as done.

  5. IMPORTANT: After marking a task as done, a progress table will be displayed showing the updated status of all tasks. The assistant MUST NOT proceed to another task without the user's approval. The user must explicitly approve the completed task.

  6. Once a task is approved, you can proceed to 'get_next_task' again to fetch the next pending task.

  7. Repeat this cycle until all tasks are done.

  8. After all tasks are completed (and approved), 'get_next_task' will indicate that all tasks are done and that the request awaits approval for full completion.

  9. The user must then approve the entire request's completion. If the user does not approve and wants more tasks, you can again use 'plan_task' to add new tasks and continue the cycle.

The critical point is to always wait for user approval after completing each task and after all tasks are done, wait for request completion approval. Do not proceed automatically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dependenciesNo
notesNo
originalRequestYes
outputPathNo
splitDetailsNo
tasksYes
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 the tool's role in initiating a workflow, the requirement for user approval after each task, and the iterative cycle until completion. However, it lacks details on error handling, performance characteristics, or what happens if inputs are invalid.

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 front-loaded with core functionality but becomes verbose with detailed workflow instructions that might be better suited for general guidelines. While informative, some sentences (e.g., the entire numbered list) could be condensed or moved to a separate context, reducing the tool-specific focus.

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 complexity (6 parameters, 0% schema coverage, no output schema, no annotations), the description does a good job explaining the tool's role, parameters, and integration into a workflow. It covers the initiation process and ties to siblings, but lacks details on return values or error conditions, which are important for a tool with no output schema.

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?

With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It explains the purpose of key parameters like 'originalRequest', 'tasks', 'dependencies', 'notes', and 'outputPath', including format recommendations for 'outputPath'. However, it does not fully detail the structure of 'tasks' objects or 'splitDetails'.

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 tool's purpose: 'Register a new user request and plan its associated tasks.' It specifies the required inputs ('originalRequest' and 'tasks') and distinguishes it from siblings by explaining it initiates a workflow, unlike tools like 'add_tasks_to_request' or 'list_requests'.

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 guidance on when to use this tool: 'This tool initiates a new workflow for handling a user's request.' It details the workflow steps, including when to use sibling tools like 'get_next_task' and 'mark_subtask_done', and explicitly states not to use it for adding tasks to existing requests (implied by the workflow initiation).

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

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