redmine-mcp-workflows

redmine_copy_issue

Duplicate a Redmine issue with optional field overrides, then copy selected subtasks, watchers, and relations to the new issue.

Instructions

Duplicate an issue, with optional field overrides and link copies.

Redmine has no REST copy endpoint, so the copy is reconstructed from a read of the source issue and a normal create; the requested links (subtasks / watchers / relations) are replayed afterwards.

Args: issue_id: source issue id (required). project / tracker: copy into a different project/tracker. Empty = inherit from the source. subject: override the copied subject. Empty = "Copy of <source>". priority / description / assigned_to_id / due_date / start_date / done_ratio / custom_fields: per-field overrides; omitted fields are inherited from the source. copy_subtasks: recursively copy subtasks (depth-capped). copy_watchers: re-add the source's watchers to the copy. copy_relations: recreate the source's issue relations on the copy.

Returns {"issue", "copied": {watchers, relations, subtasks}, "source"}. Honors REDMINE_MCP_READ_ONLY.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`project`	No
`subject`	No
`tracker`	No
`due_date`	No
`issue_id`	No
`priority`	No
`done_ratio`	No
`start_date`	No
`description`	No
`copy_subtasks`	No
`copy_watchers`	No
`custom_fields`	No
`assigned_to_id`	No
`copy_relations`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Sep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the read-and-create reconstruction strategy, replay of links afterward, depth-capped subtask copying, and that REDMINE_MCP_READ_ONLY is honored. This is unusually transparent for a mutation operation.

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-loads the purpose in one line, then uses structured Args and Returns sections. Given 14 undocumented parameters, the length is justified and every sentence conveys operational or argument semantics.

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?

Despite having no annotations and 0% schema descriptions, the description covers purpose, implementation approach, parameter defaults, side effects, and read-only behavior. The return summary is technically redundant with the output schema but remains useful and does not detract.

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 coverage is 0% across 14 parameters, so the description must supply all semantics. It documents every parameter and default behavior, including empty project/tracker meaning inherit, omitted overrides inheriting from source, and empty subject becoming 'Copy of <source>'.

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 ('Duplicate an issue') and scopes the operation to optional field overrides and link copies. This clearly distinguishes it from sibling tools like redmine_create_issue, which create new issues rather than reconstructing an existing one.

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

Usage Guidelines3/5

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

Implies usage when an issue needs duplicating and explains the implementation constraint (no REST copy endpoint). However, it does not explicitly compare this tool to alternatives such as redmine_create_issue or state when not to use it, leaving the choice of tool to inference.

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

Deploy Server