update_epic / update_issue: expose assigneesWidget and iterationWidget

[Hakihiro]

Problem

Two related Work Items widgets are currently unreachable through the MCP tools, forcing a drop back to glab api graphql with hand-built workItemUpdate mutations for two of the most routine sprint-planning operations: assigning epics/issues and setting iterations.

(a) assigneesWidget missing from update_epic / update_issue

Native assignees on Work Items go through assigneesWidget. Neither update_epic nor update_issue exposes an assignee_ids param that actually lands on the server:

• PUT /groups/:group/epics/:iid with assignee_ids silently does nothing.
• mcp__gitlab__update_epic has no assignee param at all.
• mcp__gitlab__update_issue accepts assignee_ids only for the REST path, which is equally silent on Work Items in recent GitLab versions.

Workaround currently required:

mutation {
  workItemUpdate(input: {
    id: "gid://gitlab/WorkItem/$WI_ID",
    assigneesWidget: { assigneeIds: ["gid://gitlab/User/$USER_ID"] }
  }) { workItem { id } errors }
}

(b) iterationWidget missing from update_issue

Setting an iteration on an issue (= assigning it to a sprint) also goes through a widget:

• PUT /projects/:id/issues/:iid with iteration_id silently does nothing (returns null fields).
• mcp__gitlab__update_issue has no iteration param.

Workaround currently required:

mutation {
  workItemUpdate(input: {
    id: "gid://gitlab/WorkItem/$WI_ID",
    iterationWidget: { iterationId: "gid://gitlab/Iteration/$ITER_ID" }
  }) { workItem { id } errors }
}

Impact

• (a) every epic and issue created or updated during sprint planning needs an assignee — today this is a routine manual GraphQL fallback.
• (b) assigning an iteration is the core action of sprint planning. Breaking out of MCP for this step defeats most of the point of preferring MCP.

Both are daily-use operations in a normal planning workflow.

Proposal

Extend the existing update_epic and update_issue tools:

Tool	New param(s)	GraphQL widget
update_epic	assignee_ids (array of numeric user IDs, resolved to GIDs server-side)	assigneesWidget.assigneeIds
update_issue	assignee_ids (same) + iteration_id (numeric iteration ID, resolved to GID)	assigneesWidget.assigneeIds, iterationWidget.iterationId

Accept numeric IDs as input and do the GID construction server-side (same pattern as other tools).

Ideally pair with companion lookup helpers if they don't already exist:

• list_iterations already exists — good.
• search_users already exists — good. So callers can resolve names → IDs before calling.

Why combine in one issue

Same root cause (Work Items widget surface not yet exposed by MCP update tools), same fix shape (add param → plug into widget in the existing mutation path), same set of affected tools. Splitting would triple the PR review overhead for essentially identical work.

Effort

Low per widget. Both are straightforward param additions on existing mutations.

[Hakihiro]

Implemented — update_epic now supports assignee_ids via assigneesWidget, and update_issue supports iteration_id via iterationWidget.