Skip to main content
Glama

pm_create_task

Create a task. In the result, title/webUrl are for presentation; displayKey is the optional visible key. Keep key/identifier for API calls and do not expose a hidden raw key in the summary. References are name-based: status/priority/level/taskType are names; assignees are emails; tags are strings (auto-created if missing); customFields is a {name: value} map. list is the task-list identifier (tl_…). For subtasks, set parent to a task key or identifier (omit list and the parent's list is used). Task type is OPTIONAL: omit taskType to inherit the closest non-null default along the three-level chain list → folder → space. There's NO workspace-level fallback — if all three are null the task is created untyped (taskType: null in the response), which is a valid persistent state. Use pm_list_task_types to see what types this workspace has (9 SYSTEM rows seeded at workspace creation, plus any CUSTOM ones). MANDATORY CUSTOM FIELDS: a list can mark custom fields required (isMandatory, per field via pm_get_workspace_context). Populate them in customFields on create AND update — the API rejects a write that leaves one empty with HTTP 400 errorCode VALIDATION_ERROR, details.field = the field's display name; the message also names it (e.g. Mandatory custom field 'Priority' requires a value). Fix and retry; don't ask the user as a substitute. API-key scope: tasks:write.

Input Schema

NameRequiredDescriptionDefault
listNoTask-list identifier (tl_…); omit if parent is set
tagsNo
levelNo
titleYes
nextToNoTask key/identifier to position next to
parentNoParent task key or identifier (for subtasks)
statusNoStatus name (e.g. "In Progress")
accountNoMulti-account auth only: name of the account from X-Dutify-Accounts to use for this call. Ignored in single-account mode (X-API-Key header). When multiple accounts are configured and this is omitted, the call fails with ACCOUNT_REQUIRED listing the available names. list_accounts never requires a selection.
dueDateNoISO-8601 datetime
priorityNo
taskTypeNo
assigneesNoEmails
isPrivateNo
startDateNoISO-8601 datetime
workspaceNoWorkspace identifier or exact name for this call. Overrides the configured workspace. For personal keys, discover candidates with list_workspaces and select explicitly. Does not change other calls or expand a workspace key's access.
descriptionNo
customFieldsNo{fieldName: value}. Include every field the list marks mandatory (isMandatory, see pm_get_workspace_context) — a missing required field is rejected with a 400 VALIDATION_ERROR (details.field = field display name, also named in the message). Note on email: multi-value is supported but OPT-IN per field via visualSettings.allowsMultiple (default false, and settable only on the rich custom-field endpoints, not the lite ones). When enabled, pass an array of email strings and/or {email,displayName,verified} objects, max 200 elements (over that = 400 "Array value exceeds maximum size of 200 elements"). When not enabled, pass a string or object — an array is rejected with "Email field value must be a string or object", and the fix is to enable allowsMultiple, not to use a comma-separated string (that fails format validation). phone/website/location remain single-value.
estimatedTimeNoMinutes
idempotencyKeyNoOptional. Pass a UUID to dedupe retries within a 5-minute window. The same key inside the window returns 409 DUPLICATE_REQUEST regardless of body — query by name/identifier to find what was created on the first attempt; never assume the second call failed.
recurrenceRuleNoiCal RRULE string

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, it discloses important side effects and error behavior: tags are auto-created if missing, mandatory custom fields cause HTTP 400 VALIDATION_ERROR on create/update, task types inherit through list → folder → space with no workspace fallback, and API-key scope is `tasks:write`. It also explains presentation vs API identifiers and hidden key handling.

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 description is dense but appropriately sized for a 20-parameter creation tool, and it front-loads the core action. Some early presentation/security guidance about title, webUrl, displayKey, and hidden raw keys could be separated from invocation semantics, but most sentences carry useful information.

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?

Given the complexity, absence of an output schema, and 20 parameters, the description is complete enough for correct invocation: it covers task creation, subtask behavior, task-type inheritance, mandatory custom fields, error recovery, and auth scope. Return-value details are partially covered when relevant, though an output schema would still be useful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the schema: status/priority/level/taskType are names, assignees are emails, tags are auto-created strings, customFields is a name-value map with mandatory-field rules, `list` is a `tl_…` identifier, and `parent` changes list inheritance. With schema coverage at 65%, this compensates well for parameters that are only lightly documented in the schema.

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 opens with a specific verb and resource: "Create a task." It clearly distinguishes creation from sibling update/delete/comment tools, and the remaining details are scoped to task creation semantics rather than unrelated behavior.

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?

The description gives clear contextual guidance: use `parent` for subtasks, omit `list` when the parent supplies it, omit `taskType` to inherit defaults, and populate mandatory custom fields. It does not explicitly name alternative sibling tools or when-not-to-use conditions, so it falls short of the top score.

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.