redmine-mcp-workflows

redmine_bulk_create_issues

Create up to 100 Redmine issues in one call with duplicate-subject checks, skip or fail on existing matches, and optional pacing or concurrency.

Instructions

Bulk-create issues with subject idempotency.

Args: issues: list of issue spec dicts (≤ 100 per call). Each spec requires project, tracker, subject; optional fields match redmine_create_issue (description, priority, status, assigned_to_id, difficulty, due_date, start_date, done_ratio, custom_fields). on_duplicate: "skip" (default) pre-checks each subject within its project and reports existing matches as skipped with duplicate_of; "fail" reports duplicates as failures; "create_anyway" skips the pre-check entirely. pacing_seconds: sleep between POSTs (default 50ms — empirically the floor for not tripping Redmine's per-issue rate cap on small VMs). Set 0 to disable. Only used when concurrency=1. stop_on_error: True to bail at first failure; remainder lands in skipped_for_stop_on_error (sequential) or skipped (concurrent). concurrency: parallel in-flight creates (default 1 = sequential). Values > 1 use a bounded asyncio.Semaphore fan-out and are mutually exclusive with pacing — leave pacing_seconds at its default (or 0). A 5xx from any item aborts the batch.

Returns {"results": [{subject, status, id?, duplicate_of?, error?, hint?}], "summary": {total, created, skipped, failed}}. Honors REDMINE_MCP_READ_ONLY.

With quiet=True a successful result is reduced to ids + status (bulk: compact per-item rows + summary) instead of the full issue JSON. Errors are never reduced.

Input Schema

TableJSON Schema

Name	Required	Default
`quiet`	No
`issues`	Yes
`concurrency`	No
`on_duplicate`	No	skip
`stop_on_error`	No
`pacing_seconds`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.0Sep 30, 2026

addedInput schema / properties / concurrency

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

addedInput schema / properties / quiet

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

First observedv1.0.0Jul 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations available, the description carries the full behavioral burden and does so extensively: it explains duplicate pre-check semantics, rate-limit pacing rationale, stop-on-error destinations, concurrency mutual exclusion with pacing, 5xx batch aborts, read-only environment honoring, and quiet-mode return reduction.

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?

The description is long but appropriately so for a six-parameter bulk operation with complex concurrency and idempotency semantics. It is front-loaded with the core purpose and then structured into Args and Returns sections, with every sentence conveying operational detail.

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?

Given no annotations, six parameters, 0% schema description coverage, and an output schema, the description is complete: it covers purpose, parameter semantics, return summary, error handling, pacing, concurrency interactions, and environment restrictions. Nothing essential for correct invocation appears 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%, so the description must compensate, and it does so fully: it documents all six parameters, required issue spec fields, allowed duplicate modes, pacing behavior, concurrency constraints, and quiet-mode effects. This is far beyond what the schema provides.

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 starts with a specific verb and resource: 'Bulk-create issues with subject idempotency.' It immediately distinguishes this tool from single-issue creation and bulk updates by emphasizing bulk creation and the subject-based idempotency mechanism.

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 description makes clear this is for bulk creation with detailed duplicate-handling modes and a maximum of 100 issues per call. It references redmine_create_issue for matching optional fields, but it does not explicitly state when to prefer this tool over single-issue creation or when not to use it.

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

Deploy Server