taiga-mcp

List recent activity

list_activity

Read-only

Retrieve what happened in a Taiga project, newest first: who created, changed, commented on or deleted stories, tasks, issues, epics, wiki pages or sprints. Filter by member, date range, item reference or kind.

Instructions

What happened in a Taiga project, newest first: who created, changed, commented on or deleted which story, task, issue, epic, wiki page or sprint, and what changed (status, assignee, sprint…). Use it for "what did the team do yesterday", "what has Linh done this week" (by: "Linh", from), "what changed on story 42" (ref: 42), or "the latest comments in the project" (comments_only: true). Taiga lists activity from the newest backwards, so give from when asking about a period: without it, the answer says how far back it looked. For the full history of one item, get_item with changes is shorter.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "list_activity"
  }
}

Input Schema

Name	Required	Description
`by`	No	Only what this member did: full name or username, part of it when it fits one member, accents optional.
`to`	No	Only activity on or before this day, YYYY-MM-DD (UTC).
`ref`	No	Only activity on this item (and, for a story, on its tasks), by reference number.
`from`	No	Only activity on or after this day, YYYY-MM-DD (UTC).
`kind`	No	Only activity on this kind of thing. "epic" includes linking stories to epics.
`page`	No	Which part of the matches, from 1, with the same `limit` and filters.
`by_me`	No	true: only what the signed-in user did.
`limit`	No	Most events to return (default 30, at most 100).
`project`	Yes	Project slug as given by list_projects, e.g. "acme-billing". Not the display name.
`comments_only`	No	true: only events with a comment.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: results are newest-first, and omitting `from` means the response reports how far back it looked. It stops short of describing the event payload shape or pagination limits beyond what the schema states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then examples, then the ordering caveat and the sibling alternative. Dense but every sentence carries information an agent needs; no filler or restatement of the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter read tool with no output schema, the description covers ordering, the lookback caveat, filtering examples, and the alternative tool. It could say more about what an activity event contains, but the essential calling information is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning on top: it explains why `from` matters for period questions and demonstrates `by`, `ref`, and `comments_only` in realistic queries. It does not add semantics for `to`, `kind`, `page`, or `limit`, leaving those to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('what happened in a Taiga project, newest first') and enumerates the event types and item kinds covered. It also distinguishes itself from get_item with `changes`, so an agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use phrasings mapped to specific parameters ('what did the team do yesterday', by: "Linh", ref: 42, comments_only: true) and names the alternative (get_item with `changes`) for full single-item history. Both the selection condition and the exclusion are explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server