instantiate_plan
Build a complete project plan in Onplana in one call: the project, its tasks and subtasks, epics and risks, with a start and due date on every task. Fits "plan a website launch", "turn this goal into a project with tasks and dates" and "set up a project plan for our office move". A first draft written from the conversation is a valid plan; every task stays editable afterwards. Each task carries estimatedDays, and every task gets a start and due date computed from it, laid out one after another, so the project opens with a filled timeline. This call takes no predecessors; link_dependency adds them afterwards. By default it CREATES A NEW PROJECT for the plan. Pass projectId to add the plan to a project that ALREADY EXISTS instead. Because it creates a project by default, calling create_project first and then this tool WITHOUT projectId produces two projects, one of them empty. When a project already exists, whether just created or named by the user, its id belongs in projectId. Attaching appends only: it never renames the project, never changes its owner, and never reschedules tasks that were already there. The plan carries projectTitle, scopeSummary, estimatedStart, estimatedEnd, tasks[] (title, priority, estimatedDays, optional description, subtasks[] and collaborators) and risks[]. On the create path the caller becomes project owner; attaching leaves the existing owner alone. A task the plan does not name an assignee for goes to the person the call is made for, not to the agent persona, so generating a plan does not put its tasks in the agent work queue that list_assigned_tasks reads. Optional epics[] group the tasks into phases or themes ("Design", "Build", "Launch"): each epic has a caller-defined ref, and a task joins one through task.epicRef. When epics is omitted, every task lands in the default "Initial Scope" epic (legacy behaviour). UNDO SEMANTICS DIFFER BY PATH, and the difference is destructive: a project this call CREATED is fully reversed by delete_project, because nothing else is in it. A project this call ATTACHED to is not, because delete_project destroys the pre-existing project and everything that was already in it, not just what this call added; on that path only the individual tasks this call created are safely removable. createdProject in the result distinguishes the two. Limits: up to 20 epics and 100 tasks per call (each task may carry subtasks[]); split a larger plan across calls or extend it afterward with bulk_create_tasks / add_subtasks. The result includes url, a direct link to the project in Onplana, and createdProject, false when the plan was added to a project that already existed, in which case the plan is an addition to the user's project rather than a new one. ALWAYS show that link in your reply: the user is working inside another app and has no other way to find the plan you just built.
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": {
"plan": "<plan>"
},
"name": "instantiate_plan"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | ||
| projectId | No | Optional. Add this plan to an EXISTING project instead of creating one. Use it whenever the project is already there, including one you just created. Appends only: the project keeps its name, owner, description and existing task dates. | |
| projectName | No | Optional override for the auto-derived name. Ignored when projectId is set, an existing project keeps its own name. | |
| idempotencyKey | No | Optional idempotency key. Pass a stable unique value (e.g. a UUID) to make this create safe to retry: calling again with the same key within 24h - even from a new session after a reconnect - replays the original result and creates no duplicate. Org-scoped; works across conversations. |