redmine-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REDMINE_URL | Yes | URL of the Redmine instance, e.g. https://redmine.example.com | |
| REDMINE_API_KEY | Yes | API key of the dedicated Redmine bot user | |
| REDMINE_TIMEOUT | No | Timeout in seconds per request. Defaults to 30. | 30 |
| REDMINE_TOOLSETS | No | Comma-separated list of toolsets to enable: standard, expert_helpdesk, expert_agile, redmineup, or all. Defaults to standard. | standard |
| REDMINE_READ_ONLY | No | Set to false to enable the write tools. Defaults to true (read-only). | true |
| REDMINE_VERIFY_SSL | No | Whether to verify SSL certificates. Defaults to true. | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_userA | The Redmine user this server acts as, with its memberships. |
| list_projectsB | Projects visible to the server's Redmine user. |
| get_projectC | A project with its trackers, issue categories, enabled modules and time entry activities. |
| search_issuesA | Issues matching the filters (long descriptions are shortened, use get_issue for the full issue). |
| get_issueC | A single issue with its history (journals), attachments, relations and subtasks. |
| list_time_entriesD | Spent time entries. |
| list_versionsC | Versions (milestones/releases) of a project, including shared ones. |
| list_project_membersC | Members of a project with their roles. |
| list_usersA | Active users with their ids, needed for memberships and groups (admin only). |
| get_groupC | A group with its users and project memberships (admin only). |
| list_wiki_pagesC | Index of the wiki pages of a project. |
| get_wiki_pageC | A wiki page with its text, optionally an older version. |
| searchC | Redmine full text search across issues, wiki pages, news, documents, changesets and forum messages. |
| list_reference_dataA | Ids and names needed for filters and changes: issue statuses, trackers, priorities, time entry activities, document categories, custom fields (admin only), saved queries, roles, groups (admin only). |
| get_attachmentB | Metadata of an attachment and, for text files, optionally its content. |
| redmine_getC | Any single Redmine resource by id (read-only). |
| redmine_listC | Any Redmine resource list, filtered or all (read-only). Unknown names return the list of resources. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Specific getters and listers overlap with the generic redmine_get and redmine_list tools, which can retrieve any resource by id or list any resource. An agent may be unsure whether to use list_projects or redmine_list, or get_issue or redmine_get. Search vs search_issues is distinguishable, but the catch-all tools create real boundary ambiguity.
Most names follow a snake_case verb_noun pattern such as get_issue, list_projects, and search_issues. However, redmine_get and redmine_list introduce an inconsistent server prefix, and bare search breaks the verb_noun pattern. The set is still readable overall.
17 tools is just over the typical 3-15 range and feels heavy for a mostly read-only surface. The generic redmine_get and redmine_list tools could absorb several specific get/list tools, so not every tool clearly earns its place.
Read coverage is broad across issues, wiki pages, projects, users, groups, attachments, and generic resources. However, there are no write operations: no create/update issue, wiki edit, time logging, or attachment upload. For a Redmine server this is a significant lifecycle gap that will block common agent workflows.