Edworking MCP

Update task

update_task

Destructive

Update supplied task fields: name, status, priority, assignees and dates. Resolve the target, status and members first. assigneeIds replaces the entire list; [] unassigns everyone. Null clears dates or priority. Use edit_task_content for the description. Preserve requestId on retries.

Input Schema

Name	Required	Description
`id`	Yes	Existing target ID returned by the matching list, read or search tool. Preserve any search type prefix. Do not invent IDs.
`name`	No	The name requested by the user. For updates, omit to keep the current name.
`deadline`	No	ISO 8601 deadline including a timezone offset. Omit to leave unchanged; null clears the deadline.
`priority`	No	Priority: 0 Low, 1 Normal, 2 High, 3 Urgent. For updates, null clears it.
`requestId`	Yes	A unique UUID for this intended action. Reuse it unchanged when retrying the same action.
`startDate`	No	ISO 8601 start date with timezone. Omit to preserve; null clears it.
`assigneeIds`	No	Full replacement list of existing project member IDs from list_project_members. [] unassigns everyone; omit to preserve.
`stateProjectId`	No	Task status ID from list_project_statuses for the destination project.

Output Schema

Name	Required	Description	Default
`task`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 14, 2026

addedInput schema / properties / assigneeIds

Added value: +{
+  "description": "Full replacement list of existing project member IDs from list_project_members. [] unassigns everyone; omit to preserve.",
+  "items": {
+    "maxLength": 100,
+    "minLength": 1,
+    "pattern": "^[A-Za-z0-9_-]+$",
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

changedInput schema / properties / id / description

Previous value: -"Existing task ID returned by list_tasks or search. Do not invent IDs."New value: +"Existing target ID returned by the matching list, read or search tool. Preserve any search type prefix. Do not invent IDs."

addedInput schema / properties / priority

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 3,
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Priority: 0 Low, 1 Normal, 2 High, 3 Urgent. For updates, null clears it."
+}

addedInput schema / properties / startDate

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "ISO 8601 start date with timezone. Omit to preserve; null clears it."
+}

addedInput schema / properties / stateProjectId

Added value: +{
+  "description": "Task status ID from list_project_statuses for the destination project.",
+  "maxLength": 100,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9_-]+$",
+  "type": "string"
+}

First observedOct 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description goes further by disclosing replacement semantics ('assigneeIds replaces the entire list; [] unassigns everyone'), null-vs-omit clearing behavior, and retry safety via requestId. It does not describe return payload or partial-failure behavior, but the destructive edge cases an agent must know are surfaced.

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?

Five tight sentences with zero filler; the field list, prerequisite ordering, alternative routing, and edge-case semantics all earn their place. Front-loaded with the core action and progressively narrows to warnings.

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?

With an output schema present the description need not explain returns, and it covers the remaining gaps: ordering constraints, the sibling boundary, destructive list replacement, null-clearing, and requestId reuse on retries. An agent has everything needed to invoke this mutation safely.

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 every parameter is already documented, including the same replacement and null-clearing rules. The description consolidates these into one readable rule set, which aids correct invocation, but it largely restates schema text rather than adding new meaning. Baseline 3 is appropriate.

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 (Update) plus the resource (task) and enumerates the mutable fields up front. It also explicitly carves out the sibling edit_task_content for the description field, so an agent can separate the two without reading either schema. No ambiguity about what this tool touches.

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 a concrete prerequisite sequence ('Resolve the target, status and members first') and routes the description-writing case to edit_task_content by name. There is no explicit when-not guidance against create_task or get_task, but the mutation context is clear enough to act on.

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

All Edworking MCP tools Inspect

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.