Issue tracking — four providers, one interface.
Connect Claude tasks to your tracker. Import an issue and the task file is created; complete the task and the issue closes, the MR ships, the label flips — all driven by MCP tools, the same way across every provider.
The four providers
| Provider | issue_tracking.provider | Notes |
|---|---|---|
| GitLab | gitlab | Issues + merge-request workflow. |
| Jira | jira | Jira API with markdown-to-wiki conversion. |
| GitHub | github | Issues + pull-request workflow. |
| Gitea | github | Same key — auto-detected from the base URL (/api/v1 path or a gitea host); uses label IDs, not names. |
| None | disabled | Completion shows a 4-option menu instead of a provider flow (below). |
Import, create, sync
issue_read takes an ID or full URL and writes a task file under team-management/tasks/; pass update mode to re-fetch and overwrite an existing one. issue_create goes the other way — pushes a task's title and description to a new provider issue. issue_sync pushes the current task status to the linked issue, and auto_sync does it automatically on task-lifecycle events.
Completion dispatch
With a provider configured, the completion step merges the branch, opens the MR/PR, and transitions the issue. With provider: "disabled", it instead offers a four-option menu — merge_local / push_pr / keep / discard. push_pr uses gh pr create with an idempotency precheck; discard is gated behind a typed confirmation (friction, not security). Either way, HEAD must match the task's feature branch before any local flow runs.
All of this is exposed through the issue_* tools on the MCP reference.