Skip to main content
Glama

bulk_update_tasks

DestructiveIdempotent

Apply the same partial update to many tasks at once. Pass taskIds (max 50) and any combination of: status (TODO/IN_PROGRESS/REVIEW/DONE/BLOCKED), priority (LOW/MEDIUM/HIGH/CRITICAL, a ranking label that does not put a task on the critical path), shiftDueDateDays (positive or negative integer to add to each task's dueDate). Per-task failures are reported in errors but do not abort the whole call. Permission: task.edit.any on each task's project. Each task is written with the rules and effects of update_task (a shifted due date is a typed date: the duration is recounted and the schedule reflows). PREFER bulk_update_status when the ONLY change is status. Instead of taskIds and one patch, items takes up to 50 tasks, each with its own startDate, dueDate, originalDurationMinutes, constraintType and constraintDate (any of them), each applied with exactly the rules and effects of update_task (a duration on a dated task moves its due date, a typed date derives its constraint, the schedule reflows), in the order given; a refused row is reported in errors with its code while the rest land. The monthly allowance counts tasks, not calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bulk_update_tasks"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsNoUp to 50 tasks, each with its own schedule fields, in place of taskIds and the shared patch. Field meanings are update_task's.
dryRunNoPreview only: return the per-task diff (current vs proposed) + which tasks would be skipped, without committing. Writes nothing, fires no side effects.
statusNo
taskIdsNoUp to 50 task ids.
priorityNoPriority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it.
shiftDueDateDaysNoInteger days to add to each task's dueDate. Negative = earlier.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / items
      Added value: +{
      +  "description": "Up to 50 tasks, each with its own schedule fields, in place of taskIds and the shared patch. Field meanings are update_task's.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "constraintDate": {
      +        "description": "ISO date for the constraint, or null to clear.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "constraintType": {
      +        "enum": [
      +          "ASAP",
      +          "ALAP",
      +          "MSO",
      +          "MFO",
      +          "SNET",
      +          "SNLT",
      +          "FNET",
      +          "FNLT",
      +          null
      +        ],
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "dueDate": {
      +        "description": "ISO date or null to clear.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "originalDurationMinutes": {
      +        "description": "Planned duration in working minutes (a day is the project calendar's hoursPerDay, default 8h = 480).",
      +        "minimum": 0,
      +        "type": [
      +          "integer",
      +          "null"
      +        ]
      +      },
      +      "startDate": {
      +        "description": "ISO date or null to clear.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "taskId": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "taskId"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 50,
      +  "type": "array"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "taskIds"
      -]
  2. Changed1 schema field changed
    • addedInput schema / properties / priority / description
      Added value: +"Priority label (LOW/MEDIUM/HIGH/CRITICAL) that people set to rank work. It is not the critical path: the schedule engine computes that from dependencies, durations and the calendar, and priority does not change it."
  3. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: per-task failures land in `errors` without aborting the call, required permission is task.edit.any on each task's project, the monthly allowance counts tasks not calls, and each write triggers the same schedule reflow/constraint derivation as update_task. It does not characterize irreversibility of the schedule side effects or how partial success maps to the returned payload structure, so not a 5.

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 is front-loaded and every paragraph carries real information, but the 'rules and effects of update_task' explanation is repeated twice with overlapping phrasing (duration recount, typed date, schedule reflow), and the description balloons into a dense run-on block. Trimming the duplicate would lose nothing.

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?

Covers permissions, error semantics, quota accounting, ordering, and schedule side effects for a destructive, six-parameter mutation with no output schema. The main unresolved point is what happens when taskIds, items and the shared patch are combined or when neither is supplied (all parameters are optional per the schema), which the description only implies via 'in place of'.

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 83%, so the baseline is 3, but the description earns more by disambiguating `priority` ('a ranking label that does not put a task on the critical path'), spelling out that shiftDueDateDays accepts negative integers, and explaining that `items` rows are applied in the order given with independent failures. Minor redundancy listing status enum values that the schema already enumerates.

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, resource and scope in the first sentence ('Apply the same partial update to many tasks at once'), and later distinguishes itself from bulk_update_status and from update_task-style semantics. An agent can tell what this does and how it differs from the closest siblings without opening a 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 an explicit routing rule: 'PREFER bulk_update_status when the ONLY change is status', and explains that `items` replaces `taskIds` plus the shared patch. It lacks an explicit statement of when-not to use bulk at all (e.g., a single task should use update_task), so it stops short of full when/when-not coverage.

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.