Skip to main content
Glama
IDEAManagement

idea-base-mcp-server

Official

update_task

Modify an existing task's details, including title, description, estimates, dates, priority, assignees, and acceptance criteria.

Instructions

Update task details like title, description, estimates, or acceptance criteria.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew title for the task
task_idYesThe ID of the task to update
due_dateNoNew due date as YYYY-MM-DD. Pass an empty string to clear it.
priorityNoNew priority level (0-5, higher is more important)
blocked_byNoREPLACES the full set of tasks this task is blocked by. Pass [] to clear all of them. Every id must be a task in the same product; a circular chain (A blocked by B blocked by A) is rejected. While any of these is not done, the task shows as blocked whatever its stored status says.
sort_orderNoPosition among the project's tasks (lower sorts first). Drives the order returned by list_tasks and the board/list views.
start_dateNoNew start date as YYYY-MM-DD. Pass an empty string to clear it.
descriptionNoNew description
is_milestoneNoMark this task as a milestone, drawn differently on the Gantt view. Pass false to unmark it.
github_pr_urlNoURL of the GitHub Pull Request implementing this task. Used to fetch the PR diff for AI verification and to match incoming CI status back to this task. Pass an empty string to clear it.
blocked_reasonNoFree-text reason shown next to a manually-set Blocked status ("waiting on the client"). Cleared automatically when the task leaves the blocked status.
assignee_user_idNoUser ID to assign the task to, REPLACING THE WHOLE assignee set (every non-active assignment row is deleted, active workers spared) — use this only when you want exactly one owner. Must be a member of the same account. Pass an empty string to unassign everyone (active workers still spared). To ADD a second assignee without touching the first, use add_assignee instead; to remove just one, use remove_assignee.
estimated_minutesNoNew time estimate in minutes
verification_modeNoGate this task's own completion. "manual" (default) allows a plain status change to done. "ai_review" or "all" BLOCK marking the task done (403 VERIFICATION_REQUIRED) until ai_completion_score reaches 0.8 — run "Verify with AI" first. "ci_required" or "all" BLOCK it until a PR is linked (github_pr_url) with passing CI. Setting this arms a real check against your own future attempt to close the task.
required_ci_checksNoWhich named CI checks (matched case-insensitively as a substring of the check name) must pass for "ci_required"/"all" verification_mode to consider CI satisfied — e.g. ["build","test"]. Read by GET /api/tasks/:id/ci-status's resolveRequiredChecks (app/functions/api/tasks/[id]/ci-status.js:13-32), NOT by the GitHub webhook handler, which sets ci_status unconditionally from whichever single check/workflow event just arrived regardless of this field. Stored as a JSON array. Pass an empty array to require every check; this tool has no way to clear the column back to "inherit from project" (the REST API reserves that for an empty string, which this array-typed field cannot send).
acceptance_criteriaNoNew acceptance criteria

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.2.0
    • changedInput schema / properties / assignee_user_id / description
      Previous value: -"User ID to assign the task to, replacing any existing assignee. Must be a member of the same account. Pass an empty string to unassign."New value: +"User ID to assign the task to, REPLACING THE WHOLE assignee set (every non-active assignment row is deleted, active workers spared) — use this only when you want exactly one owner. Must be a member of the same account. Pass an empty string to unassign everyone (active workers still spared). To ADD a second assignee without touching the first, use add_assignee instead; to remove just one, use remove_assignee."
    • addedInput schema / properties / github_pr_url
      Added value: +{
      +  "description": "URL of the GitHub Pull Request implementing this task. Used to fetch the PR diff for AI verification and to match incoming CI status back to this task. Pass an empty string to clear it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / is_milestone
      Added value: +{
      +  "description": "Mark this task as a milestone, drawn differently on the Gantt view. Pass false to unmark it.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / required_ci_checks
      Added value: +{
      +  "description": "Which named CI checks (matched case-insensitively as a substring of the check name) must pass for \"ci_required\"/\"all\" verification_mode to consider CI satisfied — e.g. [\"build\",\"test\"]. Read by GET /api/tasks/:id/ci-status's resolveRequiredChecks (app/functions/api/tasks/[id]/ci-status.js:13-32), NOT by the GitHub webhook handler, which sets ci_status unconditionally from whichever single check/workflow event just arrived regardless of this field. Stored as a JSON array. Pass an empty array to require every check; this tool has no way to clear the column back to \"inherit from project\" (the REST API reserves that for an empty string, which this array-typed field cannot send).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / sort_order
      Added value: +{
      +  "description": "Position among the project's tasks (lower sorts first). Drives the order returned by list_tasks and the board/list views.",
      +  "type": "number"
      +}
    • addedInput schema / properties / verification_mode
      Added value: +{
      +  "description": "Gate this task's own completion. \"manual\" (default) allows a plain status change to done. \"ai_review\" or \"all\" BLOCK marking the task done (403 VERIFICATION_REQUIRED) until ai_completion_score reaches 0.8 — run \"Verify with AI\" first. \"ci_required\" or \"all\" BLOCK it until a PR is linked (github_pr_url) with passing CI. Setting this arms a real check against your own future attempt to close the task.",
      +  "enum": [
      +    "manual",
      +    "ai_review",
      +    "ci_required",
      +    "all"
      +  ],
      +  "type": "string"
      +}
  2. Changed6 schema fields changedv1.3.0
    • addedInput schema / properties / assignee_user_id
      Added value: +{
      +  "description": "User ID to assign the task to, replacing any existing assignee. Must be a member of the same account. Pass an empty string to unassign.",
      +  "type": "string"
      +}
    • addedInput schema / properties / blocked_by
      Added value: +{
      +  "description": "REPLACES the full set of tasks this task is blocked by. Pass [] to clear all of them. Every id must be a task in the same product; a circular chain (A blocked by B blocked by A) is rejected. While any of these is not done, the task shows as blocked whatever its stored status says.",
      +  "items": {
      +    "type": "number"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / blocked_reason
      Added value: +{
      +  "description": "Free-text reason shown next to a manually-set Blocked status (\"waiting on the client\"). Cleared automatically when the task leaves the blocked status.",
      +  "type": "string"
      +}
    • addedInput schema / properties / due_date
      Added value: +{
      +  "description": "New due date as YYYY-MM-DD. Pass an empty string to clear it.",
      +  "type": "string"
      +}
    • changedInput schema / properties / priority / description
      Previous value: -"New priority level"New value: +"New priority level (0-5, higher is more important)"
    • addedInput schema / properties / start_date
      Added value: +{
      +  "description": "New start date as YYYY-MM-DD. Pass an empty string to clear it.",
      +  "type": "string"
      +}
  3. First observedv1.2.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it does none of it. It never states that this is a partial update (only supplied fields change), that assignment changes delete other assignment rows, or what permissions are required — all of that lives only in scattered property descriptions.

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?

A single front-loaded sentence with no waste, and the verb+resource lead. It is appropriately sized for a description, though at 16 parameters that brevity starts to look like under-specification rather than tight writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter mutation tool with no annotations and no output schema, one sentence is not enough. The schema covers parameters, but the description omits update semantics, sibling routing (update_task_status, add_assignee, remove_assignee), and any failure/permission context.

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 the schema already documents every parameter in depth (clearing semantics, REPLACES wording, verification gates). The description's field list ('title, description, estimates, acceptance criteria') adds nothing beyond what the schema provides, so baseline 3 applies.

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 (update) and resource (task) and enumerates the kinds of fields it touches. It is clear on its own, but it never distinguishes itself from the sibling update_task_status, which an agent must choose between for status changes.

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

Usage Guidelines2/5

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

No when-to-use guidance and no exclusions. The schema hints at routing to add_assignee/remove_assignee for assignment edits and update_task_status exists as a sibling, but the description says nothing about which tool to pick or when.

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