Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

needfix_link_existing_task

Atomically links a NeedFix to an existing finished, accepted task so managers can record integration and prevent duplicate or conflicting task links.

Instructions

Manager-only: atomically link a NeedFix to an existing, finished, accepted task.

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": {
      "needfix_id": "<needfix_id>",
      "existing_task_id": "<existing_task_id>"
    },
    "name": "needfix_link_existing_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
needfix_idYesNeedFix id, e.g. NF-2026-01447.
existing_task_idYesId of an existing task in this repository; the NeedFix must be accepted or task_planned. Re-linking the same task is a no-op; a different task conflicts.
integrated_commitNoOptional commit sha (7-40 hex characters) that must be reachable from HEAD; required to link an archived superseded task, and a verified commit resolves the NeedFix. Default empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / existing_task_id / description
      Added value: +"Id of an existing task in this repository; the NeedFix must be accepted or task_planned. Re-linking the same task is a no-op; a different task conflicts."
    • addedInput schema / properties / integrated_commit / description
      Added value: +"Optional commit sha (7-40 hex characters) that must be reachable from HEAD; required to link an archived superseded task, and a verified commit resolves the NeedFix. Default empty."
    • addedInput schema / properties / needfix_id / description
      Added value: +"NeedFix id, e.g. NF-2026-01447."
  2. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Adds 'atomically' and 'Manager-only', which are genuine behavioral facts not in the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false). But it omits error behavior on conflict, what the resulting state looks like, and whether a partial failure leaves anything changed — meaningful for a mutation tool with only annotation-level safety coverage.

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?

A single front-loaded sentence: permission scope, atomicity, and both endpoints of the link are stated with zero filler. Nothing repeated, nothing padded.

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

Completeness3/5

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

No output schema exists, so the description should say what a successful link yields (task association visible where?) and what failure modes matter. With full param docs and non-destructive annotations the basics are covered, but for a state-mutating linking operation the post-conditions are left implicit.

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 needfix_id, existing_task_id, and integrated_commit are already fully documented (including no-op re-link, conflict, and the commit-reachability rule). The description adds nothing parameter-specific; 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?

Names a precise verb (link) and resource (NeedFix → existing finished/accepted task), plus a manager-only scope qualifier. It distinguishes the operation from creation-style siblings by requiring the target task to already exist and be finished/accepted, but it never names the near-identical sibling aiworkhub_dashboard_needfix_link_existing_task or how it differs from needfix_convert / needfix_reopen_superseded_task_link.

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

Usage Guidelines3/5

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

The preconditions 'existing, finished, accepted task' implicitly tell the agent this is for attaching a NeedFix to work that is already done, rather than converting it into a new task. However, no explicit when-to-use/when-not guidance, no mention of the convert path or the dashboard equivalent, and no statement about what to do if no such task exists.

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

Deploy Server

Other Tools