Skip to main content
Glama

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

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.

Input Schema

NameRequiredDescriptionDefault
planYes
projectIdNoOptional. 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.
projectNameNoOptional override for the auto-derived name. Ignored when projectId is set, an existing project keeps its own name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / plan / properties / tasks / items / properties / collaborators
      Added value: +{
+  "description": "People who work on this task besides its assignee, by user id, name or email. Added after the plan is built; anyone who cannot be added is reported in warnings.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / projectId
      Added value: +{
+  "description": "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.",
+  "type": "string"
+}
    • changedInput schema / properties / projectName / description
      Previous value: -"Optional override for the auto-derived name."New value: +"Optional override for the auto-derived name. Ignored when projectId is set, an existing project keeps its own name."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false and destructiveHint=false; the description goes far beyond by disclosing the destructive undo asymmetry (delete_project is safe only for a project this call created, and destroys pre-existing content on the attach path), plus owner semantics, caller-as-assignee behavior, the append-only guarantee, warning reporting for collaborators, and hard limits (20 epics / 100 tasks). Nothing here contradicts the annotations — the call itself does not destroy anything.

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 most decision-critical facts — one-call scope, create-by-default vs. attach, and the double-project trap — are front-loaded, and most sentences carry unique information. There is some redundancy: the createdProject/url meaning is stated twice, and the projectId rule is restated after the schema already covers it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex nested tool with no output schema and no annotations on result shape, the description supplies everything an agent needs: the plan payload fields, scheduling behavior, epic grouping, limits, and the return values (url, createdProject) including the instruction to surface the link. No material gap remains for correct invocation.

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?

Schema coverage is 67%, and the description compensates for the gaps: it explains that estimatedDays drives computed start/due dates, that epicRef joins one of the declared epics (with the 'Initial Scope' default when epics is omitted), and that projectName is ignored when projectId is set. The projectId explanation largely restates the schema text, which keeps it just below a 5.

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 opening sentence gives a specific verb (build/instantiate) plus the exact composite resource (project + tasks + subtasks + epics + risks with dates), and the example utterances pin down the intended intent class. It is clearly distinguished from create_project, bulk_create_tasks, add_subtasks and instantiate_template, which are named later as alternatives or extensions.

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?

It states the default path (creates a new project) and the explicit alternative (pass projectId to attach to an existing project), then calls out the exact failure mode: calling create_project first and then this tool WITHOUT projectId yields two projects, one empty. It also routes oversized plans to bulk_create_tasks / add_subtasks and dependencies to link_dependency, so the agent has both when-to-use and 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.

All Onplana toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources