redmine-mcp-server

Overview Schema Source Related Servers Discussions Admin

getIssueHistory

getIssueHistory

Read-onlyIdempotent

Retrieve an issue's chronological journal events and status intervals. Paginate with nextOffset; for full text, use getIssueJournal.

Instructions

Read an issue's chronological journal events and status intervals. Long text is shortened; use journalId with getIssueJournal for full text, and nextOffset to read any remaining events.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`offset`	No	Next page index from nextOffset
`issueId`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`offset`	Yes	Index of this page's first event.
`timeline`	No	Chronological timeline of creation and update events.
`nextOffset`	No	Pass this as offset to getIssueHistory for the next page; absent when complete.
`totalEvents`	Yes	Total creation and journal events available.
`sourceUpdatedOn`	No	Issue update timestamp; compare across pages to detect intervening edits.
`statusDurations`	No	Status intervals beginning in this page's events.
`compressionNotes`	No	What text was shortened and how to retrieve it in full.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.1.1Oct 1, 2026

addedInput schema / properties / offset

Added value: +{
+  "description": "Next page index from nextOffset",
+  "format": "int32",
+  "type": "integer"
+}

changedOutput schema / description

Previous value: -"Interpreted history timeline for an issue: human-readable field changes plus aggregated time spent in each status."New value: +"Interpreted issue history. Read pages until nextOffset is absent to cover every event."

addedOutput schema / properties / compressionNotes

Added value: +{
+  "description": "What text was shortened and how to retrieve it in full.",
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / nextOffset

Added value: +{
+  "description": "Pass this as offset to getIssueHistory for the next page; absent when complete.",
+  "format": "int32",
+  "type": [
+    "integer",
+    "null"
+  ]
+}

addedOutput schema / properties / offset

Added value: +{
+  "description": "Index of this page's first event.",
+  "format": "int32",
+  "type": "integer"
+}

addedOutput schema / properties / sourceUpdatedOn

Added value: +{
+  "description": "Issue update timestamp; compare across pages to detect intervening edits.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / statusDurations / description

Previous value: -"How long the issue stayed in each status, derived from journal entries."New value: +"Status intervals beginning in this page's events."

addedOutput schema / properties / totalEvents

Added value: +{
+  "description": "Total creation and journal events available.",
+  "format": "int32",
+  "type": "integer"
+}

addedOutput schema / required

Added value: +[
+  "offset",
+  "totalEvents"
+]

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds meaningful behavior beyond them: long text is truncated and remaining events require pagination via nextOffset, which tells the agent the result may be incomplete.

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?

Two dense sentences with zero waste: the core action is front-loaded, then truncation and the paging/alternative escape hatch follow. Nothing is redundant with structured fields.

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?

An output schema exists, so return shape needn't be explained, and the description still covers the two things an agent must know to use the result correctly (truncation and pagination). Complete for this tool's complexity.

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

Parameters3/5

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

Schema description coverage is only 50% – offset is documented in the schema, issueId is not. The description refers to nextOffset for pagination but adds no format or meaning for issueId, so it only partially compensates for the coverage gap.

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?

The description states a specific verb and resource ('Read an issue's chronological journal events and status intervals') and explicitly distinguishes itself from the sibling getIssueJournal. An agent can separate this from getIssue 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 Guidelines4/5

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

It routes the agent to getIssueJournal when full text is needed, and names nextOffset as the way to page through remaining events. That covers the main alternative and continuation path, though it doesn't say when not to use history at all.

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