Planning System MCP Server

fork_blueprint

Fork a blueprint into a target workspace to create a new plan with identical structure, dependencies, and instructions, but with all node statuses reset to not_started.

Instructions

Fork a plan-scope blueprint into a target workspace. Creates a new plan inside that workspace with the blueprint's structure (nodes, dependencies, agent_instructions). All node statuses reset to 'not_started'. The new plan's forked_from_blueprint_id records lineage.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "blueprint_id": "<blueprint_id>",
      "workspace_id": "<workspace_id>"
    },
    "name": "fork_blueprint"
  }
}

Input Schema

Name	Required	Description
`blueprint_id`	Yes
`workspace_id`	Yes	Target workspace the new plan will land in.
`title`	No	Optional title override for the new plan.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.5.0Jun 18, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Discloses that node statuses reset to not_started and lineage is recorded via forked_from_blueprint_id. However, with no annotations, it omits permissions, failure behavior, or side effects like overwriting existing plans.

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?

Three sentences with the action front-loaded. No redundant information. Slightly more detail could be provided without losing conciseness.

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?

For a tool with 3 parameters and no output schema, the description covers the core behavior and parameter roles. It lacks details about error handling (invalid blueprint_id, non-existent workspace) and return values.

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 67% (blueprint_id missing description). Description adds context about blueprint meaning but does not specify format or uniqueness of blueprint_id. The title parameter is adequately explained.

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 action (fork), the object (plan-scope blueprint), and the result (new plan in target workspace). It distinguishes from siblings like save_as_blueprint and create_plan by specifying the fork behavior.

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?

Implies usage for duplicating a blueprint's structure into a workspace, but does not explicitly state when to use versus alternatives (e.g., save_as_blueprint or create_plan). No when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.