Skip to main content
Glama

Create task

create_task

Create a task in a project. Requires Administrator or ProjectManager role. Status values are DEFINED PER WORKSPACE — there is no fixed list. Call list_task_statuses to see this workspace's labels before setting one; a label it does not define is rejected with 400. A new workspace starts with "Open", "InProgress", "Review", "Done", but any of those may have been renamed, reordered, removed or added to. Each status also carries a progress value, and CHANGING A STATUS OVERWRITES percentComplete with it (the workspace's starting status is 0, its finished status 100). To set a status without taking its progress, send status and percentComplete together in one update_task call — except for the finished status, which always forces 100. assignedTo is the integer user id (use list_users to resolve) and must be a member of the workspace. Dates are ISO-8601 strings. An ordinary task must end up with BOTH startDate and endDate, and startDate must be on or before endDate — the server rejects a missing or inverted range with 422. A milestone needs only one of the two: the isMilestone invariants run first and copy it to the other. A child task's startDate must also be >= its parents' end dates. A milestone marks a dated gate rather than a span of work (launch date, sign-off, go/no-go). The server holds it to one date — endDate is forced to equal startDate, so naming either one is enough — with duration 0 and progress that is only ever 0 or 100 (100 exactly when it is in the workspace's finished status). Setting isMilestone on a task that already has a date range collapses it onto its start date. WORK BREAKDOWN STRUCTURE. Tasks nest via wbsParentId, and every task carries a read-only wbscode — its dotted outline number within the project ("1", "2.3", "2.3.1") — plus issummary. wbsParentId is NOT a scheduling dependency: a WBS child sits INSIDE its parent's span and in fact defines it, whereas a predecessor runs BEFORE its successor. Predecessors are their own resource — create_task_dependency — and are unrelated to nesting. A task with at least one WBS child is a SUMMARY TASK and owns none of its own schedule: its startDate, endDate, duration, percentComplete and status are all recomputed from its children (dates span the children; progress is their span-weighted average). Writing any of those on a summary returns 422 — change the children instead. wbscode is derived from tree position, so it shifts whenever tasks are reordered or re-parented: display it, never store or match on it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTask title
statusNoStatus (optional, default Open). Status values are DEFINED PER WORKSPACE — there is no fixed list. Call list_task_statuses to see this workspace's labels before setting one; a label it does not define is rejected with 400. A new workspace starts with "Open", "InProgress", "Review", "Done", but any of those may have been renamed, reordered, removed or added to. Each status also carries a progress value, and CHANGING A STATUS OVERWRITES percentComplete with it (the workspace's starting status is 0, its finished status 100). To set a status without taking its progress, send status and percentComplete together in one update_task call — except for the finished status, which always forces 100.
endDateYesEnd date, ISO-8601 (required, must be >= startDate; pass null only for a milestone that gives startDate instead; applied for Admin/ProjectManager)
durationNoDuration value (optional). In Days it is derived by the server — the working days the dates cover — so only an Hours or Minutes value is kept as sent
projectIdYesProject id the task belongs to
startDateYesStart date, ISO-8601 (required; pass null only for a milestone that gives endDate instead; applied for Admin/ProjectManager)
assignedToNoAssigned user id (optional)
descriptionNoDescription (optional)
isMilestoneNoCreate this as a milestone rather than a task (optional, default false)
wbsParentIdNoWBS parent task id — the task this one decomposes. Must be in the same project, and cannot be a milestone (optional)
durationUnitNoDuration unit, e.g. Days or Hours (optional)
targetVersionNoTarget version label (optional)
resourceNeededNoResource needed / FTE units (optional)
percentCompleteNoPercent complete 0-100 (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses role gating (Administrator/ProjectManager), specific error codes (400 for undefined status label, 422 for missing/inverted dates and for writing computed fields on a summary task), side effects (milestone forces endDate=startDate and collapses an existing range; duration 0; progress 0/100), and derived read-only fields (wbscode, issummary). This is the kind of non-obvious consequence disclosure annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and permissions are front-loaded and the acronym headings help, but the block is ~450 words and repeats the entire status-per-workspace and milestone explanations that already live in the input schema. The WBS/summary-task section is genuinely new information; the duplicated sections are not earning their space twice.

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 14-parameter creation tool with no output schema, this covers everything an agent needs: validation rules, permission gates, cross-tool prerequisites, hidden side effects, and the fact that derived fields will be populated on return. Nothing material is left to inference.

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 coverage is 100%, so the baseline is 3. The description does add real meaning the schema lacks — isMilestone's date coercion, wbsParentId being nesting rather than a scheduling dependency, assignedTo needing workspace membership, and Days durations being server-derived — but the status paragraph is largely reproduced verbatim in the schema's own status field, diluting the marginal value.

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?

Opens with a specific verb+resource ('Create a task in a project') and immediately scopes it with role requirements. It also names the sibling boundaries explicitly (update_task for combined status+percentComplete, create_task_dependency for predecessors), so an agent can distinguish it from adjacent tools without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong conditional routing: call list_task_statuses before setting a status, use list_users to resolve assignedTo, use create_task_dependency for predecessors rather than wbsParentId. It doesn't enumerate when-not-to-use create_task (e.g., templates, recurring tasks), but the in-flow guidance is concrete and actionable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources