taiga-mcp

Read one story, issue, epic or task

get_item

Read-only

Reads a Taiga user story, issue, epic, or task in full by its reference number, returning status, assignee, dates, description, custom fields, files, latest comments, and tasks. Optionally includes change history.

Instructions

Read one user story, issue, epic or task of a Taiga project in full, by its reference number (the #123 shown in Taiga and by the list tools): status, assignee, dates, description, custom fields, attached files, the latest comments, and for a user story its tasks. With changes also who changed what and when (status, assignee, sprint…). A project numbers stories, issues, epics and tasks from one sequence, so the number alone is enough and you need not know which kind it is. Use it after a list tool, or when the user names an item by number. To find items by words or other properties use the list tools or search.

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>",
      "ref": "<ref>"
    },
    "name": "get_item"
  }
}

Input Schema

Name	Required	Description
`ref`	Yes	Reference number without the #, e.g. 123.
`changes`	No	true: also list the latest changes to the item: who moved it to which status, reassigned it, moved it to another sprint, and when. For "when was this closed" or "who changed it".
`project`	Yes	Project slug as given by list_projects, e.g. "acme-billing". Not the display name.
`comments`	No	How many of the latest comments to read (default 5, at most 50). Raise it when the answer says there are more and the discussion matters; 0 for none.
`changes_page`	No	Which page of the changes, 20 history entries a page, newest first. Implies `changes`. The answer says how many pages there are.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: the full field set returned, that story tasks are included, what `changes` exposes, and that history is paginated newest-first at 20 per page with the answer reporting page counts. The cross-type reference-number sequence fact is a genuinely useful behavioral disclosure.

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

Conciseness4/5

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

Front-loaded with purpose, then a dense enumeration of returns, then usage and the numbering insight. Every sentence carries information, though the long comma-heavy inventory of returned fields is slightly harder to scan than bulleted phrasing would be.

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

Completeness5/5

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

No output schema exists, so the description properly compensates by naming what is returned, including tasks for stories and the optional change history. For a read-only single-record tool with fully documented parameters, nothing an agent needs is missing.

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 a 3 is the baseline, but the description adds real meaning beyond it: the shared numbering sequence across stories, issues, epics and tasks means `ref` alone suffices without knowing the item kind, and `changes` is glossed as who changed what and when. Minor gap: `comments` and `changes_page` interaction is left mostly 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?

Opens with a specific verb and resource set ('Read one user story, issue, epic or task of a Taiga project in full, by its reference number') and enumerates exactly what comes back. It is clearly distinguishable from the list_* and search siblings, which return many items rather than one.

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 explicit triggers ('Use it after a list tool, or when the user names an item by number') and an explicit exclusion routing elsewhere ('To find items by words or other properties use the list tools or search'). No inference required.

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

Deploy Server