Skip to main content
Glama
itmplatform

ITM Platform MCP Server

Official
by itmplatform
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_task

Update specific ITM Platform task fields by sending only changed values, such as dates, status, priority, parent, or kind, via a PATCH request.

Instructions

Update task fields via PATCH; send only the fields to change. KindId changes the task kind (1=Milestone, 2=Summary, 3=Task; not TypeId) and ParentId moves the task under a summary task; both are Waterfall-only. Converting to a milestone requires equal StartDate and EndDate in the same call. A status with AutomaticProgress (such as Completed) creates a 100% progress entry; a later lower report only takes effect with a later ReportDate (percentComplete tracks the latest entry by ReportDate).

Input Schema

NameRequiredDescriptionDefault
NameNoNew task name
KindIdNoNew kind: 1=Milestone, 2=Summary, 3=Task (Waterfall only); to milestone requires equal StartDate and EndDate in the same call
TypeIdNoNew type ID
taskIdYesThe task ID to update
DetailsNoDetails field used by v2 REST
EndDateNoNew end date (ISO 8601)
ParentIdNoNew parent task ID (Waterfall only); a regular-task parent converts to a summary unless it has assignees or dependencies
StatusIdNoNew status ID
StartDateNoNew start date (ISO 8601)
projectIdYesThe project ID containing the task
PriorityIdNoNew priority ID
DescriptionNoNew 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

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the safety/behavior burden and discloses meaningful traits: PATCH partial update, Waterfall-only KindId/ParentId changes, the milestone date-equality requirement, and AutomaticProgress side effects on progress entries. It still omits permission requirements, reversibility, and response behavior, so it is not fully complete.

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?

Four dense sentences front-load the core PATCH/partial-update rule, then spend the remainder only on non-obvious constraints. No filler or repetition; every sentence adds operational 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 a 14-parameter mutation tool with no annotations and no output schema, the description covers the most important side effects and Waterfall-only constraints while the rich schema documents all fields. It is nearly complete, but still lacks permission, error, and response context.

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 even without description-added parameter detail. The description earns a 4 by clarifying KindId vs TypeId, ParentId moving under a summary task, and StatusId's interaction with AutomaticProgress and percentComplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: update task fields via PATCH, with partial-update semantics. The KindId/ParentId/status details make clear this is a field-update tool, not a progress or bulk-status operation, but no sibling tool is explicitly named for differentiation.

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

Usage Guidelines3/5

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

Implies when to use it through 'send only the fields to change' and special-case rules, but never names alternatives such as update_task_progress or bulk_update_task_status or states when not to use this tool. Guidance is adequate but leaves alternative selection to inference.

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