redmine-mcp-server
Related Servers
Alternatives to redmine-mcp-server
No user-submitted related servers found.
Related Servers
- FlicenseAqualityDmaintenanceMCP server for Redmine integration, enabling AI assistants to manage issues, upload files, automate workflows, and handle wiki pages.18-
- AlicenseAqualityAmaintenanceEnables AI assistants to manage Redmine issues, projects, time tracking, wiki, and files via the MCP protocol.338 npm5Apache 2.0
- AlicenseBqualityBmaintenanceMCP server to operate self-hosted Redmine from Claude Code, enabling project and issue management, search, and metadata retrieval via natural language.24MIT
- FlicenseAqualityDmaintenanceMCP server for Redmine that lets coding agents read and write Redmine: search issues, view histories, comment, log time, browse wiki, and download attachments. Enforces explicit user permission for any write operations.181-
- AlicenseCqualityDmaintenanceModel Context Protocol (MCP) server for Redmine that provides comprehensive access to the Redmine REST API, enabling users to operate Redmine from MCP clients such as Claude Desktop.9020 npmMIT
- FlicenseNot gradedqualityCmaintenanceEnables AI clients (Cursor, Claude Desktop) to manage Redmine issues, projects, time tracking, and wiki pages through natural language.6 npm1-
TDQS
Scored across 32 tools
Every tool targets a distinct resource or analytical use case. Overlapping areas such as getIssue versus getIssueTree, searchIssues versus searchAll, and version summary versus release risk are clearly differentiated by their descriptions.
All tool names follow a consistent lower_snake_case verb_noun pattern using get, list, search, or compare. There are no mixed casing conventions or vague generic verbs.
With 32 tools, this exceeds the 25+ threshold and feels heavy even for a broad Redmine integration. Several metadata-discovery tools such as listPriorities, listStatuses, listTrackers, and listTimeEntryActivities could be consolidated or grouped.
The read and analytics surface is extensive, but the tool descriptions repeatedly reference createIssue, updateIssue, createTimeEntry, and updateWikiPage, none of which are actually exposed. This creates significant dead ends and leaves the server without any write lifecycle coverage.