Taiga MCP

taiga-mcp

A Model Context Protocol server for Taiga. It lets an AI assistant such as Claude, ChatGPT, Copilot or Cursor answer questions about your Taiga projects without you opening Taiga: sprints, user stories, tasks, issues, epics and the wiki. It reads by default; if you switch it on, it can also create items, change them and comment. It can never delete anything.

Try it in 30 seconds

Nothing to install. In Claude, open Settings → Connectors → Add custom connector and paste:

https://taiga.kietnguyen.io.vn/mcp

Sign in with your own Taiga account, on Taiga cloud or any Taiga reachable from the internet, then ask:

• "What is left in the current sprint?"
• "What does #123 say, and who has it?"
• "Read the spreadsheet attached to #456 and list the rows marked urgent."

Other apps (ChatGPT, Claude Code, Cursor, VS Code, Gemini CLI, Codex, Windsurf): see Connecting an app. Your password is passed to Taiga once and never stored (how signing in works); if you would rather nobody else's server saw it, run it on your machine or host your own.

Why this one

• Reads what is attached. PDFs, Word, Excel, PowerPoint, CSV and pictures attached to an item, in parts when they are large.
• Nothing to install for a team. One address, and each person signs in with their own Taiga account (OAuth). No keys to hand around, no database.
• Writes only when allowed, never deletes. Creating, changing and commenting are off until switched on, refuse to overwrite someone else's change, and show every field before and after.
• Sprints the way a team talks about them. Points done, stories done, burndown day by day, and what happened this week, by person.
• Names, not ids. Statuses, people, sprints and tags by name (no accents needed), items by #123; errors say what to try next.
• Any Taiga. Taiga cloud or self-hosted (for a Taiga inside a company network, host your own); sign-in pages in English and Vietnamese.

How it works inside, flow by flow, with links into the code: docs/how-it-works.md.

It runs in two ways:

• On your machine (stdio), for one person, with the Taiga account in its settings. See Setup.
• Hosted (HTTP), for a team, including people who never open a terminal: they paste one address into their AI assistant and sign in with their own Taiga account. See Hosted server.

Status: fourteen tools that read and three that write (off unless switched on), covered by tests against a fake Taiga; the reading tools are also checked against a public project on Taiga cloud. A hosted instance runs at taiga.kietnguyen.io.vn.

Tools

The four list tools for items share their filters:

Plus sprint (a name, current or backlog) and epic on stories, story and sprint on tasks, type, severity and priority on issues.

How the tools are meant to be used by a model:

• Names in, names out. project is the slug from list_projects; statuses, severities, sprints, tags and people are given by name (case does not matter); items are addressed by the #123 reference number. Internal ids never appear.
• Counting needs no paging. Every list starts with the number of all matches (Acme Billing · assigned to me · finished 2026-10-01 to 2026-10-31: 14 tasks), so "how many" is one call with a small limit.
• Long lists come in pages. An answer that does not hold everything says which part it is (31 to 60 shown, page 2 of 5) and how to ask for the next.
• `get_item` needs no type. Taiga numbers stories, tasks, issues and epics of a project from one sequence, so the number says which kind it is.
• Short answers. Long descriptions, comments and wiki pages are cut, with a note saying how much is missing.
• Activity is read backwards. Taiga lists it from the newest event and cannot jump to a day, so list_activity reads back up to 1,000 events and, when it stops before the period asked for, says how far back it looked.
• Errors say what to do next, for example: "Linh" matches several members of project "Acme Billing": Linh Tran (linh.tran), Võ Thị Linh (vtlinh). Pass the full name or the username.

Tools that write

Off unless switched on: TAIGA_WRITE=true on your machine; on a hosted server, ALLOW_WRITES=true and then a box each person ticks when signing in. Without that, the server sends Taiga nothing but GET requests and the sign-in itself.

How they are kept safe:

• Nothing can be deleted. The server has no way to send a DELETE. To close an item, set a closed status.
• Only on request. The tools tell the model to write only when the user asks for that change in the conversation, never because a title, description, comment, wiki page or file in Taiga says to (text there is written by others and may try to give the model orders). They are marked as writing in MCP, so apps ask before calling them; update_item is marked as overwriting.
• No half-done creates. Every name (status, person, sprint, story, epic, type…) is checked before anything is sent; a wrong one is answered with the valid names and nothing is created.
• No silent overwrites. get_item shows the item's version and update_item sends it: if someone changed the same fields since, Taiga refuses and the model is told to read the item again.
• Every answer shows what changed, field by field, before and after, with a link to the item in Taiga. A description is shown by its length, not repeated.
• A second lock. Even if a tool were called on a read-only connection, the code that talks to Taiga refuses to send anything but a read.
• As you. Changes are made with the signed-in person's own Taiga account and appear in Taiga under their name, with Taiga's own history and notifications.

Reading attached files

get_item numbers the files attached to an item; get_attachment reads one, by that number or by its name.

| Exce