Skip to main content
Glama
bernatch22

taskops

by bernatch22
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

taskops_update

Update task cards on a shared task board: change status, report progress, edit titles and specs, set priorities, add dependencies, and move milestones.

Instructions

Change the CARD: close it (done needs a commit, or no_code=true), hand it in for review (status=review on a card that requires it), hand it back (status=released, note= how far you got), drop it (note= why), report progress (progress=0-100, every 5-10 points), retitle, re-spec, re-prioritise, add a dependency. To talk: taskops_comment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNowith milestone= and no task=: rewrite the goal
noteNowhy THIS status change — released and dropped require it, and the next worker is shown a released note verbatim. To just say something, or to address somebody, use taskops_comment.
specNorewrite the spec
taskNotk-…
actorNowho is speaking, when it is not the session's own identity. Sub-agents share the session's ONE MCP server, so a spawned worker MUST pass the agent:<dev>/<name> its brief names on EVERY taskops call — without it the board hears the orchestrator.
afterNotk-… this card waits for
filesNoreplace the edit surface
rulesNowith milestone= and no task=: replace the chapter's rules, whole
titleNorename
labelsNorouting and search hints, e.g. ["backend", "urgent"]
reviewNothis card must pass review before it closes (flip after planning)
statusNodone needs a commit (or no_code); review hands the card in for its verdict (note= says what you did); released needs a note; dropped needs a reason
no_codeNoclosing with no commit — say what happened instead
reviewsNowith milestone= and no task=: change the chapter's review DEFAULT — it applies to cards planned after it, never retro-flags one
criteriaNowhat this card is accepted against — the other half of the spec. The worker is shown these right under it; closing says which were met and what proves it.
priorityNo0 urgent … 3 idle
progressNohow far along you are, 0–100, in your own estimate — report it every 5–10 points as you work; the board draws it. The card's worker writes it: its holder, or whoever it is assigned to
milestoneNomove the card — or, with no task=, update the milestone
repo_pathNoanother project's board, by any path inside it. Default: the board this server started in. The host runs ONE MCP server per session, pinned to the directory it opened, so without this a second project is unreachable and the work leaves through curl instead of the tools.
union_filesNowith milestone= and no task=: replace the chapter's union seam files, whole

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.7
    • addedInput schema / properties / progress
      Added value: +{
+  "description": "how far along you are, 0–100, in your own estimate — report it every 5–10 points as you work; the board draws it. The card's worker writes it: its holder, or whoever it is assigned to",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Changed1 schema field changedv0.4.2
    • addedInput schema / properties / union_files
      Added value: +{
+  "description": "with milestone= and no task=: replace the chapter's union seam files, whole",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so meaningfully: it discloses mandatory side conditions for closing, releasing, dropping, and progress reporting, and points to the comment tool for non-update communication. It does not cover response/error behavior, but the mutation semantics and key constraints are clearly stated.

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?

One concentrated sentence front-loaded with 'Change the CARD' and followed by a scannable action list; every clause contributes and there is no filler. It is dense to the point of being a run-on, but it earns its length.

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 20-parameter mutation tool with no annotations and no output schema, the description provides a sound mental model of the update surface and routes talk to the correct sibling. It omits milestone-level, chapter-level, and cross-project operations, but the schema covers those in detail, so the description is adequate as an entry point.

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?

Input schema coverage is 100% with rich per-parameter descriptions, so the baseline is 3. The description adds a small amount of semantic glue (e.g., progress=0-100 at 5-10 point intervals, done needs a commit or no_code=true), but largely restates what the schema already documents.

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 resource ('the CARD') and a verb ('Change'), then enumerates concrete update actions: close, review, released, dropped, progress, retitle, re-spec, re-prioritise, and add a dependency. It clearly differentiates itself from taskops_comment by explicitly routing talk away.

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?

Provides an explicit routing rule for the closest sibling ('To talk: taskops_comment') and embeds conditional usage cues for status transitions (done needs a commit/no_code, released and dropped need notes, progress is reported every 5-10 points). It does not contrast against assign/take/plan, so when-to-use guidance is useful but not exhaustive.

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

Install Server

Other Tools