Skip to main content
Glama

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

create_task

Add one task to an existing Onplana project, with an optional assignee, due date, priority and description. Fits "add a task to book the venue by Friday" or "remind me to send the invoice next week" once the project is known. projectId and title are required; list_projects with search finds a project known only by name. A subtask is a task whose parentId is its parent's id. add_subtasks creates 2+ children under the same parent in one atomic call, and instantiate_plan commits a whole project with tasks and risks at once. Pass recurringRule to create a repeating task in one call (set dueDate too). The result includes url, a direct link to the task in Onplana. ALWAYS show it in your reply so the user can open what you just created.

Input Schema

NameRequiredDescriptionDefault
titleYesTask title, 1–500 chars. Required.
epicIdNoOptional epic grouping.
statusNoDefault TODO.
dueDateNoISO date the work must finish.
parentIdNoParent task id for subtasks.
priorityNoPriority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it. Default MEDIUM.
progressNo0–100; default 0.
sprintIdNoOptional sprint to scope the task to.
projectIdYesProject id to create the task in. Required.
startDateNoISO date the work can start.
assigneeIdNoUser id to assign. Must be a member of the org.
descriptionNoOptional description, up to 10000 chars.
isMilestoneNoMark as a milestone (shown as a diamond on Gantt).
assigneeNameNoAlternative to assigneeId - full name, first name, or email of an org member. Resolved fuzzy; ignored when assigneeId is also set.
collaboratorsNoPeople who work on the task besides its assignee, by user id, name or email. They see it in My Work and may update it but not reassign it. Added after the task is created; anyone who cannot be added is reported in warnings.
recurringRuleNoMake the task recurring: { freq: daily|weekly|monthly, interval: int>=1, endDate?: ISO|null }. Omit (or null) for a one-off task. The recurringWorker spawns the next occurrence from the due/start date, so set dueDate (or startDate) too.
estimatedHoursNoEstimated hours of effort.
idempotencyKeyNoOptional 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / collaborators
      Added value: +{
+  "description": "People who work on the task besides its assignee, by user id, name or email. They see it in My Work and may update it but not reassign it. Added after the task is created; anyone who cannot be added is reported in warnings.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / priority / description
      Previous value: -"Default MEDIUM."New value: +"Priority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it. Default MEDIUM."
    • addedInput schema / properties / recurringRule
      Added value: +{
+  "description": "Make the task recurring: { freq: daily|weekly|monthly, interval: int>=1, endDate?: ISO|null }. Omit (or null) for a one-off task. The recurringWorker spawns the next occurrence from the due/start date, so set dueDate (or startDate) too.",
+  "properties": {
+    "endDate": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "freq": {
+      "enum": [
+        "daily",
+        "weekly",
+        "monthly"
+      ],
+      "type": "string"
+    },
+    "interval": {
+      "type": "number"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare write/non-destructive/openWorld=false, so the bar is lower, yet the description still adds real behavior: idempotencyKey replays the original result within 24h with no duplicate, collaborators are added after creation with unaddable users surfaced as warnings, the recurringWorker spawns the next occurrence, and the result contains a `url` the agent must show. It stops short of failure/permission modes, but that is well beyond the annotation coverage.

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?

Front-loaded with the core action and required fields, then examples, then routing to alternatives, then the url requirement — a sensible priority order. It is long and repeats the dueDate requirement for recurringRule, but almost every sentence carries routing or behavioral value.

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?

For an 18-parameter create tool with no output schema, the description covers the essentials an agent needs: required ids, how to resolve an unknown project, sibling alternatives for bulk/atomic creation, the idempotency escape hatch, and the returned `url`. Only a fuller account of error/permission behavior is missing, which is minor here.

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 100%, so the schema already documents all 18 parameters, including the recurringRule-needs-dueDate coupling and assigneeName/assigneeId precedence. The description mostly repeats required fields and the parentId-as-subtask meaning, adding little syntax or semantics the schema does not already carry, so baseline 3 applies.

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?

States a specific verb+resource (create one task in an existing Onplana project) with the optional fields it accepts, and distinguishes itself from the closest siblings by explaining that a subtask is a task with a parentId while add_subtasks and instantiate_plan handle the multi-item cases.

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?

Gives explicit user-phrase triggers ("book the venue by Friday") and routing rules: use list_projects with `search` when only the project name is known, add_subtasks for 2+ children under one parent, instantiate_plan for a whole project at once. This is genuine when-to-use/when-to-use-something-else 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