redmine-mcp-workflows

redmine_bulk_update_issues

Update multiple Redmine issues with the same status, priority, assignee, or custom field values in one batch call. Use it to make bulk changes without editing each issue.

Instructions

Apply the same field updates to many issues in one call.

Args: issue_ids: list of numeric issue ids (≤ 100 per call). subject, description, status, priority, assigned_to_id, notes: same semantics as redmine_update_issue — at least one must be supplied. custom_fields: raw custom-field entries (list of {"id": N, "value": "..."} dicts). Merged into each issue's PUT. difficulty: convenience for the Difficulty custom field ("Unclassified" / "Easy" / "Normal" / "Hard"). held: reason string applied as the hold on every issue in the batch (e.g. "waiting on upstream patch"). Empty (default) means unchanged. Booleans are rejected with held_reason_required — a bare flag records nothing and would overwrite every existing reason in the batch at once. clear_held: set True to remove the hold from every issue in the batch. Mutually exclusive with a non-empty held. held_until: ISO-8601 date for the Held Until custom field. Optional and independent of held. due_date: ISO-8601 date to set on every issue. start_date: ISO-8601 date to set on every issue. done_ratio: 0-100 progress percent; -1 (default) means unchanged. stop_on_error: if True, halt at the first failure (remaining ids land in skipped); otherwise best-effort across the whole batch. concurrency: parallel in-flight PUTs (default 1 = sequential). Values > 1 use a bounded asyncio.Semaphore fan-out; a 5xx from any item aborts the batch (unstarted ids land in skipped).

Returns {total, succeeded, failed, skipped}. Honors REDMINE_MCP_READ_ONLY. Redmine has no batch endpoint — items are applied concurrency at a time.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`held`	No
`notes`	No
`status`	No
`subject`	No
`due_date`	No
`priority`	No
`issue_ids`	Yes
`clear_held`	No
`difficulty`	No
`done_ratio`	No
`held_until`	No
`start_date`	No
`concurrency`	No
`description`	No
`custom_fields`	No
`stop_on_error`	No
`assigned_to_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.0Sep 30, 2026

addedInput schema / properties / clear_held

Added value: +{
+  "default": false,
+  "title": "Clear Held",
+  "type": "boolean"
+}

addedInput schema / properties / concurrency

Added value: +{
+  "default": 1,
+  "title": "Concurrency",
+  "type": "integer"
+}

changedInput schema / properties / held / default
```
Previous value: -falseNew value: +""
```

changedInput schema / properties / held / type

Previous value: -"boolean"New value: +"string"

First observedv1.0.0Jul 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: stop_on_error vs. best-effort with unstarted ids landing in 'skipped', concurrency fan-out via a bounded semaphore, a 5xx aborting the batch, empty-vs-unchanged semantics for 'held' and done_ratio=-1, the reason-string requirement that rejects booleans with held_reason_required, the clear_held/held mutual exclusion, and honoring REDMINE_MCP_READ_ONLY. These are exactly the mutation, partial-failure, and auth behaviors an agent needs and cannot derive from the schema.

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 a one-line summary followed by an Args block, and given 17 parameters the length is largely justified. A few lines are verbose (the held rationale spans multiple clauses) but each sentence carries operational information rather than filler.

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?

For a complex bulk mutation with no annotations and a 0%-coverage schema, this is complete: partial-failure handling, concurrency semantics, error/abort behavior, read-only env gating, and the note that Redmine has no batch endpoint are all present. The return shape is restated and an output schema exists, so nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0% across 17 parameters, so the description must compensate and does: it caps issue_ids at 100, gives custom_fields the {'id': N, 'value': '...'} shape, enumerates difficulty values, documents default-equivalents (held empty = unchanged, done_ratio -1 = unchanged), and explains the date params. Nearly every parameter receives meaning beyond its bare type.

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 opening sentence states a specific verb and resource with scope: 'Apply the same field updates to many issues in one call.' This cleanly distinguishes it from the single-issue sibling redmine_update_issue and from redmine_bulk_create_issues without the agent needing to open any 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?

The bulk framing implies when to reach for it over redmine_update_issue, and it anchors semantics by referencing that sibling ('same semantics as redmine_update_issue'). It also states the precondition that at least one updatable field must be supplied. It stops short of an explicit 'use X for one issue, Y for many' routing sentence, so it is clear context rather than explicit alternatives.

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

Deploy Server