Commonly

Official

Overview Schema Related Servers Discussions Admin

commonly_patch_task

Edits a task row's status, title, assignee, priority, dependency, or notes directly, replacing existing notes. Use it to release a claim or adjust fields without appending history.

Instructions

Edit the task row itself: status (pending, done, blocked), title, assignee (empty string to unassign), priority, dep (empty string to clear), or notes, which replaces the existing notes (commonly_update_task appends a history line instead). To release a claim, set status to pending. To claim a row use commonly_claim_task, because a claim takes a lease and this tool cannot set one; to close one use commonly_complete_task, which also records the PR. If you created the row, you may edit it while another seat holds its claim, and the edit names the claim it overrode. Any other seat gets a 409 that names the holder.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "podId": "<podId>",
      "taskId": "<taskId>"
    },
    "name": "commonly_patch_task"
  }
}

Input Schema

Name	Required	Description	Default
`dep`	No
`notes`	No
`podId`	Yes
`title`	No
`status`	No
`taskId`	Yes
`assignee`	No
`priority`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.16Nov 13, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: notes replaces existing content while commonly_update_task appends, and the concurrency model is spelled out (creator may edit over another seat's claim and the edit records the overridden claim; other seats get a 409 naming the holder). It does not address partial-update semantics for omitted fields or any permission/authorization requirements beyond the claim-override rule.

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?

The editable-field list is front-loaded and no clause is filler — every sentence either names an alternative or discloses conflict behavior. It is dense to the point of being a single continuous block, which makes the conflict rule harder to scan than it needs to be.

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 an eight-parameter mutation tool with no annotations and no output schema, the definition covers the risky parts well: destructive note replacement, lease/claim interaction, and the 409 failure mode. Remaining gaps are the identifiers (podId, taskId) and whether a call leaves unlisted fields untouched, but neither blocks correct invocation.

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 0%, so the description must compensate, and it does for six of eight parameters — most valuably the empty-string conventions for assignee (unassign) and dep (clear), which the schema does not convey, plus the replace-vs-append meaning of notes. podId and taskId are left entirely undefined in both schema and description.

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 and resource ("Edit the task row itself") and enumerates the exact editable fields: status, title, assignee, priority, dep, notes. It then explicitly distinguishes itself from three siblings (commonly_update_task, commonly_claim_task, commonly_complete_task), so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not-to-use routing: claiming goes to commonly_claim_task because a lease can't be set here, closing goes to commonly_complete_task, and a claim is released by setting status to pending. It also names the alternative for append-style history (commonly_update_task), covering both exclusions and substitutions.

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