Reported issues for redmine-mcp-server by jztan

Pod holds 24 of 87 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to redmine-mcp-server by jztan.

Most discussed

create_redmine_issue returns "Requested resource not found" on success, causing silent duplicate creation

Bug Description

When calling create_redmine_issue, the tool returns an error response of "Requested resource not found" even though the issue was successfully created in Redmine. The caller has no way to distinguish a genuine failure from a successful creation, leading to unnecessary retries and risk of duplicate issues.

Note: This bug report was drafted by Claude AI (Anthropic) during an active development session. The observed behavior is real and reproducible. Root cause analysis…

Read the thread · 2026-06-04 · closed · external user · 18 comments

OAuth discovery doc omits scopes_supported; tokens lack permissions for many tools

Bug Description

When REDMINE_AUTH_MODE=oauth, the OAuth discovery endpoints (/.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server) don't advertise a scopes_supported field. MCP clients therefore don't request specific scopes in the authorisation URL, and Redmine grants only Doorkeeper's default scopes (view_project, search_project, view_members).

Tools whose underlying Redmine endpoint requires any other permission then return 403, even when the…

Read the thread · 2026-05-20 · closed · external user · 11 comments

OAuth mode (v2.1.0): discovery metadata is internally inconsistent for a non-DCR upstream - client treats the MCP server as the authorization server

Bug Description

In OAuth mode (v2.1.0, RemoteAuthProvider + introspection), the two discovery documents disagree about the identity of the authorization server, and a current MCP client (VS Code 1.122.1) consequently treats the MCP server itself as the authorization server. The browser is opened to <mcp-base-url>/authorize (which the MCP server does not serve) instead of Redmine's /oauth/authorize, and the flow fails with a 404.

The two documents:

-…

Read the thread · 2026-06-01 · closed · external user · 9 comments

Add tool for sending Helpdesk plugin email replies (/helpdesk/email_note.xml)

RedmineUP's Helpdesk plugin has a dedicated endpoint for sending a ticket note as an outgoing email to the requester, separate from a plain internal journal note:

• Docs: https://www.redmineup.com/pages/help/helpdesk/rest-api-send-reply
• POST /helpdesk/email_note.xml
• Body: <message><issue_id>1</issue_id><status_id>2</status_id><content>...</content></message> (status_id optional, updates the ticket status on send)

Right now update_redmine_issue's notes field only creates a…

Read the thread · 2026-09-15 · closed · external user · 7 comments

Per-user auth for Redmine instances without Doorkeeper: bind a browser-supplied API key to a self-issued OAuth token

Problem Statement

On a Redmine that cannot offer Doorkeeper, this server has no working multi-user story. The README is explicit about the requirement — "OAuth2 is the one hard requirement: it needs Redmine 6.1+ for Doorkeeper" — and every existing auth mode fails for a different reason once Doorkeeper is off the table:

• legacy shares one REDMINE_API_KEY across everyone. Every caller acts as that account, so assigned_to_id="me" is meaningless and Redmine's own permissions stop…

Read the thread · 2026-09-02 · closed · external user · 6 comments

Add MCP ToolAnnotations so clients can distinguish read-only tools

Problem statement

The tools exposed by redmine-mcp-server do not currently include MCP ToolAnnotations. In particular, pure read tools such as list_redmine_projects, get_redmine_issue, and search_entire_redmine do not advertise readOnlyHint=true.

Clients therefore have to treat every tool conservatively as potentially mutating. For example, ChatGPT asks for approval before calling read-only query tools.

This is reproducible with v2.10.0 and current develop: tools/list…

Read the thread · 2026-08-10 · closed · outside contributor · 6 comments

Issue serializers drop top-level fields added by Redmine distributions and plugins

Some Redmine distributions and plugins add their own top-level keys to the issue JSON. Easy Redmine, for instance, returns this on every issue:

"easy_sprint": {"id": 356, "name": "June 2025", "due_date": "2025-06-30"},
"easy_story_points": 0,
"is_favorited": false

python-redmine keeps them in the decoded payload, but _issue_to_dict and _issue_to_dict_selective build the result from a fixed key set, so they never reach the client. Today the only way to get them is a second…

Read the thread · 2026-09-04 · closed · external user · 5 comments

get_redmine_issue throwing SSL errors even with verification disabled !?

Bug Description

2026-08-03 17:53:37 WARNING  SSL verification is DISABLED - use only for development!
2026-08-03 17:53:37 ERROR    SSL error during fetching issue 56789: HTTPSConnectionPool(host='redmine.local', port=443): Max retries exceeded with url: /issues/56789.json?include=journals%2Cattachments (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)')))

Steps to…

Read the thread · 2026-08-03 · closed · external user · 5 comments

Most recent

A custom field name that matches nothing is silently dropped, and the update reports success

Bug Description

update_redmine_issue and create_redmine_issue accept custom fields by name in fields (#123). When a name matches no custom field on the project, _resolve_named_custom_fields skips it (if match is None: continue). python-redmine then sends it as a top-level issue attribute, Redmine ignores it, and the call returns success without writing the value.

unapplied_fields (#369) doesn't catch this, because it only compares fields whose stored form it can predict.…

Read the thread · 2026-09-27 · closed · 0 comments

update_redmine_issue reports a write Redmine silently discarded, such as a status the workflow forbids, as success

Bug Description

update_redmine_issue reports a write Redmine discarded as a success. Called with {"status_id": 2} for a status the workflow does not allow from the current one, it returns the complete issue with no error, the old status, and no journal entry. {"status_name": "In Progress"} behaves the same way. The caller cannot tell a write that landed from one that did nothing without reading the issue back and diffing it.

The discard is Redmine's, by design…

Read the thread · 2026-09-26 · closed · outside contributor · 0 comments

The contact is_company filter is documented as broken; it needs the database adapter's own literal for true

Problem Statement

manage_contact documents is_company as create-only and tells the caller the plugin's filter is broken: it "is not a list filter: the plugin's own is_company filter returns the same wrong set for every value, so filter the is_company key on the returned contacts instead". The filters description meanwhile says to write a yes/no filter as "1", and is_company is in _CONTACT_QUERY_FILTER_NAMES, so filters={"is_company": "1"} does reach Redmine.…

Read the thread · 2026-09-26 · closed · outside contributor · 0 comments

list_project_issue_custom_fields answers [] when Redmine omits issue_custom_fields, which Redmine 6.1.4 and 7.0.1 do without view_issues

Bug Description

list_project_issue_custom_fields returns [] when Redmine's response leaves out the issue_custom_fields array, which a caller cannot tell apart from a project with no issue custom fields.

The tool reads getattr(project, "issue_custom_fields", None). issue_custom_fields is in python-redmine's Project._includes (redminelib/resources/standard.py), so when the key is missing BaseResource.__getattr__ calls refresh(itself=False, include="issue_custom_fields") --…

Read the thread · 2026-09-26 · closed · outside contributor · 0 comments

A custom field passed by name is dropped or misreported when the project's custom field list cannot be read

Bug Description

create_redmine_issue and update_redmine_issue resolve a custom field passed by name in fields ({"Department": "Engineering"}, the #123 shortcut) by reading GET /projects/{id}.json?include=issue_custom_fields. When that read cannot deliver the definitions, the tools either misreport why or lose the value silently.

The read is refused. projects#show needs view_project. Neither tool's TOOL_SCOPES entry requires it -- create_redmine_issue is…

Read the thread · 2026-09-26 · closed · outside contributor · 0 comments

An issue include Redmine leaves out re-fetches the whole issue: a leaf issue's children and withheld watchers cost two requests

Bug Description

#223 fixed relations by reading it from the payload through _included_list. The other four issue includes -- journals, attachments, watchers and children -- are still read through the python-redmine attribute, and all four are in Issue._includes. When the key is missing from the payload, BaseResource.__getattr__ does not report it missing: it calls refresh(itself=False, include=<name>), which is a second GET /issues/{id}.json for the whole issue, and…

Read the thread · 2026-09-26 · closed · outside contributor · 0 comments

manage_product and manage_document read key names their plugins do not send, and a DMSF get reports the oldest revision

Bug Description

manage_product and manage_document read several fields under key names their plugins do not send, so those fields come back empty however populated the record is. It is the pattern #227 fixed in the contact serializer, in two sibling plugin tools.

_product_to_dict (tools/products.py). The Products plugin's products/index.api.rsb and show.api.rsb render:

api.tag_list @product.tag_list

api.created_at @product.created_at
api.updated_at…

[Read the thread](https://github.com/jztan/redmine-mcp-server/issues/358) · 2026-09-26 · closed · outside contributor · 0 comments

### list_project_members drops the inherited flag on roles, so a group or parent-project role reads as held directly

### Bug Description

`list_project_members` drops Redmine's `inherited` flag from every role, so a role that comes from a group, or from the parent project of a subproject that inherits members, reads exactly like a role held directly. `manage_project_member(action="update")` returns the same shape and drops it too. (`add` shares the shape, but a membership it creates never carries an inherited role: `Member` validates `user_id` unique per project, and a group's inherited roles land on its…

[Read the thread](https://github.com/jztan/redmine-mcp-server/issues/356) · 2026-09-26 · closed · outside contributor · 0 comments

### manage_contact get forwards include but drops every array the CRM plugin returns for it

### Bug Description

`manage_contact(action="get")` takes `include` and forwards it to Redmine as `params["include"]`, but no include ever changes the response. The CRM plugin renders the arrays; the serializer throws them away.

The plugin's `contacts/show.api.rsb` (redmine_contacts 4.4.5 Pro) gates exactly four blocks on `include_in_api_response?`:

- `notes`: `{id, content, type_id, author, created_on, updated_on}`, rendered when the caller passes `authorize_for(:notes, :show)` (granted by…

[Read the thread](https://github.com/jztan/redmine-mcp-server/issues/354) · 2026-09-26 · closed · outside contributor · 0 comments

### manage_contact list returns every custom field or none, so a lookup that needs two pays for all of them

### Problem Statement

#345 gave `manage_contact(action="list")` an `include_custom_fields` flag, and it is all or nothing. Off, a row holds `custom_fields: None`; on, it holds every custom field the instance defines, with a value or not, because the CRM plugin's `contacts/index.api.rsb` renders `render_api_custom_values` unconditionally. A lookup that needs two of those fields — an account's owner and its tier, say — pays for all of them on every row.

Measured on the real serializer with a…

[Read the thread](https://github.com/jztan/redmine-mcp-server/issues/352) · 2026-09-26 · closed · outside contributor · 0 comments

### feat: interactive project timeline MCP App (show_project_timeline)

### Problem Statement

The two MCP Apps so far answer "what is the state of things": the dashboard counts issues and the triage board groups them by status. Neither shows when work is scheduled. To see whether a release is on track, you ask for `get_gantt_chart` and get raw dates back, which the model then has to describe in prose.

### Proposed Solution

A third MCP App, `show_project_timeline`, that renders a project's schedule inline:

- Issue bars from start date to due date, grouped by…

[Read the thread](https://github.com/jztan/redmine-mcp-server/issues/350) · 2026-09-26 · closed · 0 comments

### search_redmine_issues: hydration silently misses every hit on Easy Redmine, and the fallback row has an empty subject

Version: 2.16.0 (same code on `develop`), against Easy Redmine.

Easy's `/search.json` doesn't return real issue ids. It adds an offset per entity type (issues +300000000, projects +400000000, news +100000000...). The `url` still has the real id:

```json
{"id": 300024224, "type": "issue", "title": "[ML-DA] S2-51 Chiusura o rimando ADR aperte", "url": "https://<host>/issues/24224", ...}

_hydrate_search_results then asks /issues.json?issue_id=300024224,...&status_id=*. Easy answers 200…

Read the thread · 2026-09-23 · closed · outside contributor · 1 comment

manage_contact list has no output-field selector, so one attribute costs every custom field on every row

Problem Statement

manage_contact(action="list") returns every custom field on every contact, and there is no way to ask for fewer. The serializer says so itself, in tools/contacts.py:

custom_fields is unconditional here, unlike _issue_to_dict where it sits behind include_custom_fields: manage_contact has no output-field selector, so there is no way for a caller to ask for it.

include is not that selector — it is get-only and adds related data (notes, deals,…

Read the thread · 2026-09-22 · closed · outside contributor · 0 comments

create_redmine_issue silently drops a description passed in fields

What happens

create_redmine_issue silently discards a description passed inside fields. The issue is created with an empty description and the call reports success — nothing in the result says the text was dropped.

create_redmine_issue(
    project_id=1093,
    subject="…",
    fields={"tracker_id": 203, "assigned_to_id": 913, "description": "<p>…</p>"},
)
# -> issue created, every other key in `fields` applied, description == ""

The cause is in…

Read the thread · 2026-09-20 · closed · external user · 0 comments

unmapped_fields passes through css_classes on every issue, and the size cap cannot catch it

_issue_unmapped_fields passes a distribution's own top-level keys through, filtered by size. The comment above the cap names the case it was meant to handle:

Plugins hang rendering junk off the issue (Easy Redmine's css_classes, for one) that is long and of no use to a model. Size is the honest filter here; a per-plugin name list only covers the plugins we happen to have seen.

Measured against a live Easy Redmine, that key is not long. It gets through, on every issue, forever.

##…

Read the thread · 2026-09-20 · closed · external user · 0 comments

create_redmine_issue cannot take a staged description, so a long one must be written out at creation

#316 gave update_redmine_issue a description_upload_id, so a long description can be set from a file staged with create_upload_ticket instead of being written out into the tool argument. create_redmine_issue did not get the same treatment:

async def create_redmine_issue(
    project_id: int,
    subject: str,
    description: str = "",
    ...

So a long description can be changed without passing through the model, but not written in the first place. That is the wrong…

Read the thread · 2026-09-20 · closed · external user · 1 comment

The remaining reports are on the project's issue tracker.