Skip to main content
Glama

initializePlan

Create or replace a complete task plan by defining goals and structured tasks with dependencies and reasoning for AI agent management.

Instructions

初始化或完全替换一个新的任务计划。

Args: goal (str): 描述计划总体目标的字符串。 tasks (List[TaskInput]): 任务对象的列表。每个任务的结构如下: - name (str): 任务的名称,在一个计划中应唯一。 - dependencies (List[Union[str, int]]): 依赖的任务名称或ID列表。 - reasoning (str): 阐述为何需要此任务。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYes
tasksYes

Implementation Reference

  • The main MCP tool handler function, decorated with @mcp.tool() for automatic registration. It validates inputs using Pydantic models (TaskInput) and delegates execution to the PlanManager instance.
    @mcp.tool()
    def initializePlan(goal: str, tasks: List[TaskInput]) -> ToolResponse[dict]:
        """
        初始化或完全替换一个新的任务计划。
    
        Args:
            goal (str): 描述计划总体目标的字符串。
            tasks (List[TaskInput]): 任务对象的列表。每个任务的结构如下:
              - name (str): 任务的名称,在一个计划中应唯一。
              - dependencies (List[Union[str, int]]): 依赖的任务名称或ID列表。
              - reasoning (str): 阐述为何需要此任务。
        """
        task_dicts = [task.model_dump() for task in tasks]
        return plan_manager.initializePlan(goal, task_dicts)
  • Pydantic schema/model for the 'tasks' input parameter in initializePlan tool, defining the structure and validation for each task.
    class TaskInput(BaseModel):
        """
        用于初始化计划时,定义单个任务输入的Pydantic模型。
        这为Agent提供了一个清晰、可验证的数据结构。
        """
        name: str
        dependencies: List[Union[str, int]]
        reasoning: str
  • Generic Pydantic response wrapper used as the return type for initializePlan (ToolResponse[dict]), standardizing tool outputs.
    class ToolResponse(BaseModel, Generic[T]):
        """
        一个通用的工具响应模型,用于标准化所有工具的返回结构。
        """
        success: bool = Field(True, description="操作是否成功。")
        message: Optional[str] = Field(None, description="关于操作结果的可读消息。")
        data: Optional[T] = Field(None, description="操作返回的主要数据负载。")
  • Core implementation logic in PlanManager class. Handles plan initialization: validates input, assigns IDs, resolves string dependencies to IDs, detects circular dependencies, and sets up the plan data structure.
    def initializePlan(self, goal: str, tasks: List[Dict]) -> Dict:
        """
        初始化计划
        """
        if not tasks:
            return {"success": False, "message": "At least one task is required"}
        
        current_time = datetime.now().isoformat()
        
        # 重置计划数据
        self.plan_data = {
            "meta": {
                "goal": goal,
                "created_at": current_time,
                "updated_at": current_time
            },
            "state": {
                "current_task_id": None,
                "status": "idle"
            },
            "tasks": []
        }
        
        # 处理任务列表
        try:
            # First pass: create tasks and map names to IDs
            processed_tasks, task_name_to_id = self._process_tasks_pass_one(tasks)
            # Second pass: resolve dependencies
            self._process_tasks_pass_two(tasks, processed_tasks, task_name_to_id)
            # Third pass: detect circular dependencies
            self._check_all_circular_dependencies(processed_tasks)
        except ValueError as e:
            return {"success": False, "message": str(e)}
    
        self.plan_data["tasks"] = processed_tasks
        self._update_timestamp()
        
        return {
            "success": True,
            "message": "Plan initialized successfully",
            "data": self.plan_data
        }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. While it mentions the tool can '初始化或完全替换' (initialize or completely replace), it doesn't disclose critical behavioral traits: whether this overwrites existing plans, what permissions are needed, whether the operation is reversible, what happens to incomplete tasks in replaced plans, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.

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 and front-loaded: the first sentence states the core purpose, followed by structured parameter explanations. Every sentence earns its place by clarifying parameter usage. Minor improvement could be integrating the parameter details more seamlessly, but it's highly efficient.

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 tool's complexity (creating/replacing entire plans with nested task structures), no annotations, and no output schema, the description is partially complete. It covers purpose, usage, and parameters well, but lacks behavioral details (e.g., mutation effects, error conditions, return values). For a tool with this scope, more context about the operation's impact would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that 'goal' describes the plan's overall objective, and 'tasks' is a list where each task has a unique name, dependencies (as names or IDs), and reasoning explaining why the task is needed. This adds essential meaning beyond the bare schema.

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 with specific verbs ('初始化或完全替换') and resource ('任务计划'), distinguishing it from siblings like 'loadPlan' (which presumably loads existing plans) and 'addTask' (which adds to existing plans). It explicitly indicates this tool creates or replaces entire plans, not incremental modifications.

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 by stating this tool is for '初始化或完全替换一个新的任务计划' (initialize or completely replace a new task plan), which clearly distinguishes when to use this versus alternatives like 'addTask' (for incremental additions), 'loadPlan' (for loading existing plans), or 'editDependencies' (for modifying dependencies in existing plans). The scope is well-defined.

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/donway19/MCPlanManager'

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