Alternatives

Alternatives

English · 繁體中文

Taiga CLI is not the only way to drive Taiga from a machine, and for some jobs it is not the best one. This page is about which tool fits which problem, not about which is better.

Taiga's REST API with curl and jq

This is the honest baseline, and for a single call it wins: no install, no version to track, nothing between you and the request.

It stops being pleasant once a script does more than one thing. You end up writing, and then maintaining, the parts that are not the interesting bit of your job:

• Discovering the API URL for a site deployed under a subpath, then holding an auth token somewhere that is not a plaintext file.
• Resolving names to IDs. Taiga speaks in IDs; people and CI configs speak in "In progress" and alice. That is a lookup and an ambiguity decision per field.
• Reading the current version before every write and deciding what a rejection means.
• Telling apart the four ways a request fails: rejected, not found, throttled, and the connection died and it may already have happened.

Taiga CLI is that glue with a contract on it. If your script is curl plus one jq filter, keep the curl.

Other Taiga command line tools

There are others, including a .NET taiga-cli on NuGet, a Rust one, and packages on npm. They cover the same nouns: projects, epics, stories, tasks, issues.

The difference is what they optimise for. Most present a convenient terminal interface and clean output for a human or a language model to read. Taiga CLI treats the command line as a versioned automation API first: a declared JSON contract, exit codes partitioned by failure kind, JSON Schema descriptors carrying safety and idempotency, and write semantics that refuse to guess. That costs verbosity a human does not need and buys behaviour a script can rely on.

Pick on that axis. If you want to read a backlog in a terminal, several tools do it well.

An MCP server

MCP is the better fit when an agent already speaks it and you want tools discovered and invoked inside that protocol, with the server holding credentials centrally for several users.

A CLI fits differently. It needs no running service, works in any context that has a shell — a CI runner, a cron job, a Dockerfile, an SSH session — and is equally usable by a person. An agent can use it through whatever shell tool it already has, and taiga schema <command> --json gives it the same machine-readable contract an MCP tool definition would.

They are not exclusive. An MCP server could shell out to Taiga CLI and inherit its write semantics.

Where Taiga CLI is the wrong choice

• You want a UI. It has no interactive mode, no TUI, no board rendering.
• You need something Taiga's API does not expose. project archive reports unsupported_capability rather than faking it, and that will be true of anything else the REST contract leaves out.
• You are on TaigaNext. Different API, no compatibility layer. See COMPATIBILITY.md.
• You need per-item fields in bulk. Taiga's native bulk endpoints take a list of subjects and little else, so varied descriptions or assignees mean single-item calls.
• One curl would have done. Adding a dependency to save four lines is a bad trade.