redmine-mcp
Related Servers
Alternatives to redmine-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceProvides MCP tools for interacting with Redmine, including issues, projects, wiki pages, time entries, and more.15 npm1MIT
- AlicenseBqualityAmaintenanceExposes 30 tools to manage Redmine resources (issues, projects, users, time entries, wiki pages, news, files, roles) via the REST API using stdio transport.33320 npm4MIT
- AlicenseAqualityDmaintenanceA local STDIO server that exposes Redmine REST API as MCP tools, allowing MCP clients to browse Redmine projects and tickets.6MIT
- AlicenseNot gradedqualityCmaintenanceA read-only MCP server for querying Redmine issue data via the Redmine REST API, designed for seamless integration with AI assistants.15 npmMIT
- FlicenseNot gradedqualityCmaintenanceExposes Redmine's REST API as MCP tools, enabling AI assistants to read, create, update, and comment on issues, manage projects, and handle attachments through both HTTP and stdio transports.8 npm-
- AlicenseBqualityDmaintenanceMCP server for Redmine project management, enabling tools for managing projects, issues, users, time entries, groups, memberships, versions, wiki, news, attachments, search, and Agile sprints via the Redmine REST API.8930 npm1MIT
TDQS
Scored across 35 tools
Every tool is clearly distinct: list_* for collections, get_* for single resources, and each maps to a specific Redmine API endpoint. Even similar tools like get_project and list_projects differ obviously by cardinality. Semantic overlaps (e.g., get_version vs get_project_wiki_page_version) are unambiguous from context.
The naming pattern is overwhelmingly consistent: list_* for index endpoints, get_* for show endpoints, with clear resource nouns. Minor deviations like get_my_account instead of get_current_user and list_my_assigned_issues being slightly longer than other list_* names are easy to predict but not perfectly uniform.
With 35 tools, this is above the 15-25 range considered 'heavy' and closer to the chaotic end. While Redmine has many resource types, the count feels bloated—several read-only variants (e.g., list_project_issues vs list_all_issues) could be consolidated. Users face a steep CLI surface.
The tool set is exclusively read-only. While it covers a broad set of GET endpoints (projects, issues, wiki, memberships, etc.), there are no create, update, or delete operations. A complete Redmine integration would at least allow issue mutations, leaving major dead ends for agents that need to take actions.