Skip to content

fix(mcp): make move_task/bulk_move_tasks match the task-positions API - #632

Closed
DreamchaserLG wants to merge 3 commits into
Paca-AI:masterfrom
DreamchaserLG:contribution/issue-610-1792776668
Closed

DreamchaserLG wants to merge 3 commits into
Paca-AI:masterfrom
DreamchaserLG:contribution/issue-610-1792776668

Conversation

@DreamchaserLG

Copy link
Copy Markdown

Summary

move_task and bulk_move_tasks sent target_view_id / target_status_id / target_position — none of which the task-positions API recognizes (MoveTaskRequest binds only position + group_key). Every call bound as position: 0, upserted position 0 in the source view, returned 200, and the tools reported "Task moved successfully" while the task never moved.

This PR implements option 1 (reorder-only) as agreed in #610. Closes #610.

Type of Change

  • Other — bug fix: align the two MCP tools' input schemas, routes, and descriptions with the task-positions API.

Root cause & changes

  • PacaAPIViewsClient.bulkMoveTasks hit the single-task route (PUT .../task-positions/{taskId}) with fields the API's MoveTaskRequest doesn't know; bulk_move_tasks also called the single-task route instead of the bulk route (PUT .../task-positions with { items }).
  • Added moveTaskPosition(projectId, viewId, taskId, position, groupKey?) with the correct body; bulk_move_tasks now maps items: [{ taskId, position, groupKey? }] through the existing bulkMoveViewTaskPositions bulk-route helper.
  • Tool schemas/descriptions updated to reorder-only semantics ("does not change a task's view, sprint, or status — use update_task for that"); success replies now state what actually changed.
  • Types: replaced the phantom BulkMoveTasksInput / MoveTaskInput with MoveTaskPositionItem, mirroring the backend's BulkMoveTaskItem DTO.
  • Docs: fixed the mcp-server-setup example claiming bulk_move_tasks "Moves all tasks to the new sprint" — the exact misconception reported in the issue.

Breaking change

Both tools' input schemas change: targetViewId / targetStatusId / targetPosition are removed, position is required, and bulk_move_tasks takes items. As noted in #610, callers passing targetViewId were already getting a silent no-op (position reset to 0), so there is no working behavior to preserve.

Testing

  • biome lint and tsc --noEmit (deps aligned to bun.lock): clean.
  • vitest run: 635 passed (baseline 630; +5 covering client route/body shapes — including omitted vs explicit-null group_key — tool argument mapping, empty-items and missing-position rejection, and reply wording).
  • Coverage on the touched files: views-client.ts 92.3→92.52% stmts / 73.91→74.64% branch; view-tools.ts 100% stmts.
  • apps/e2e, apps/web, services/agent-runner have zero references to the old schema; audited all 67 MCP client endpoints against the Go route table — no remaining route/field mismatches after this fix.

Checklist

  • The change is focused and scoped.
  • Related documentation is updated.
  • New structure or direction is explained clearly.
  • I avoided unnecessary detail or premature abstraction.

DreamchaserLG and others added 3 commits October 24, 2026 01:39
…closes Paca-AI#610)

move_task and bulk_move_tasks sent target_view_id/target_status_id/
target_position, which the API's MoveTaskRequest (position, group_key)
ignores entirely — so the endpoint upserted position 0 in the source
view and the tools reported 'Task moved successfully' without anything
moving (see Paca-AI#610).

Align both tools with the task-positions API (reorder-only, as agreed
in the issue): move_task takes {viewId, taskId, position, groupKey?},
bulk_move_tasks takes an items array and calls the bulk route. Cross-
view/sprint/status moves now point to update_task. Tool descriptions
and the mcp-server-setup guide example updated accordingly.

Co-authored-by: ZCode Scout <noreply@zcode.local>
Flagged by biome lint/correctness/noUnusedImports; the type is exported
from types/index.ts for external consumers, the client method takes
primitives.
@pikann

pikann commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

Fixed in #629. Thanks a lot for your contribution, we really appreciate it!

@pikann pikann closed this Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] MCP: move_task and bulk_move_tasks send fields the task-positions API ignores

2 participants