Skip to main content
Glama
itmplatform

ITM Platform MCP Server

Official
by itmplatform
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_task

Creates tasks, milestones, or summary tasks in an ITM Platform project using provided IDs and dates to set Waterfall hierarchy or Kanban defaults.

Instructions

Create a regular task, milestone, or summary task. KindId: 1=Milestone, 2=Summary, 3/default=Task (not the TypeId). Waterfall regular tasks require StatusId, StartDate, and EndDate; milestones require EndDate; summaries require StatusId. Kanban supports regular tasks only and uses board defaults. ParentId creates Waterfall hierarchy. AutomaticProgress statuses create 100% progress; a later lower report needs a later ReportDate. Use get_reference_data for valid IDs.

Input Schema

NameRequiredDescriptionDefault
NameYesTask name (required)
KindIdNoKind: 1=Milestone, 2=Summary, 3=Task (default); 1 and 2 require a Waterfall project
TypeIdNoTask type ID (account default when omitted). Not the same as KindId.
DetailsNoDetails field used by v2 REST
EndDateNoEnd date (ISO 8601); required for Waterfall regular tasks and milestones
ParentIdNoParent task ID (Waterfall only); a regular-task parent converts to a summary unless it has assignees or dependencies
StatusIdNoStatus ID; required for Waterfall regular and summary tasks, not for milestones; Kanban uses board defaults
StartDateNoStart date (ISO 8601); required for Waterfall regular tasks. Milestones: omit or equal to EndDate.
projectIdYesThe project ID to create the task in
PriorityIdNoTask priority ID (account default when omitted)
DescriptionNoTask description (alias of Details)
TaskMembersNoComma-separated usernames or numeric UserIds (use the UserId for non-login users) added as team members. Add-only.
TaskManagersNoComma-separated usernames (search_users EmailAddress) or numeric UserIds (search_users UserId; the only option for non-login users, whose EmailAddress is empty) added as task managers; Kanban saves them as members. Add-only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does well: it states Waterfall/Kanban support boundaries, required fields by kind, Kanban board-default behavior, ParentId hierarchy effects, and AutomaticProgress behavior. It stops short of describing permissions, side effects on existing parent tasks, or failure modes.

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

Conciseness5/5

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

The description is dense but well front-loaded, opening with the core action and then layering the conditional rules that matter most. Every sentence conveys creation constraints or semantics; there is little wasted text despite the complexity.

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 a 13-parameter create tool with no annotations and no output schema, the description covers the key domain rules an agent needs to invoke it correctly. It could be stronger by mentioning the return shape or permission requirements, but the essential creation semantics are present.

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 100%, so the baseline is 3, but the description adds cross-field meaning: KindId values and the KindId/TypeId distinction, Waterfall vs. Kanban requirements for StatusId and dates, and ParentId hierarchy behavior. It still leaves several parameters such as TaskMembers, TaskManagers, and PriorityId to 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?

Starts with a specific verb and resource: 'Create a regular task, milestone, or summary task.' It immediately distinguishes the supported task kinds and clarifies KindId vs TypeId, so an agent can tell this apart from update_task or create_task_progress without opening the schema.

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?

Gives clear conditional usage by waterfall vs. Kanban and by task kind, including required fields for each case. It does not explicitly name alternatives such as update_task or create_task_progress, but the creation context is strong and unambiguous.

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

Deploy Server

Other Tools