[Bug]: Epic tools fail on localized Jira Server/DC (issue type name "Эпик" != "epic")

[nemkevich]

Environment: Jira Server 10.3.19 (Russian locale), issue type displayed as «Эпик», Epic Name field present (customfield_10103, field name in English: "Epic Name"). mcp-atlassian via uvx mcp-atlassian, JIRA_PERSONAL_TOKEN auth.

Symptoms

1. jira_create_issue with issue_type: "Эпик" fails with the Jira error "Epic Name обязательно" (Epic Name is required). Epic field preparation is skipped entirely: the gate at src/mcp_atlassian/jira/issues.py:415 (if issue_type == "epic":) compares the user-provided type name against the English literal, so prepare_epic_fields() never runs and the Epic Name custom field is not populated. Passing epic_name / epicName in additional_fields does not help.
2. jira_link_to_epic fails with "PROJ-123 is not an Epic": src/mcp_atlassian/jira/epics.py:326 compares issuetype.name.lower() != "epic" — always true for a localized type name, even when the target actually is an epic.
3. Same class of problem: get_required_fields("Epic", project_key) in epics.py:138 looks up required fields by the English display name.

Note: the reverse direction is already handled — issues.py:645 resolves the English "Epic" to a localized name via _find_epic_issue_type. The localized→internal direction is what's missing.

Suggested fix

Detect epic-ness without relying on the display name, e.g.:

• resolve the epic issue type per project via createmeta: the type that has the Epic Name field (com.pyxis.greenhopper.jira:gh-epic-label) is the epic type — works on Server/DC and Cloud; and/or
• reuse the existing _find_epic_issue_type resolution symmetrically in the link_to_epic check and the prepare_epic_fields gate;
• optional escape hatch: an env var like JIRA_EPIC_ISSUE_TYPE_NAME.

Workaround (for anyone hitting this)

• create: pass the Epic Name custom field id directly, e.g. additional_fields: {"customfield_10103": "My epic"};
• link: set the Epic Link field directly via jira_update_issue, e.g. fields: {"customfield_10101": "PROJ-456"}.

Both verified working on Jira Server 10.3.19.

Happy to submit a PR if the maintainers agree on the approach.

[nemkevich]

One more data point that constrains the fix options: on this Jira Server 10.3.19 instance, GET /rest/api/2/issuetype/{id} does not return untranslatedName (the field is absent from the response). So resolving the canonical type name via untranslatedName is not a viable fix for Server/DC — which strengthens the case for detecting the epic type structurally (the issue type that carries the Epic Name field, com.pyxis.greenhopper.jira:gh-epic-label, via createmeta).

For completeness: the localized names here are the stock ones a Russian-locale Server install ships with (all system types are localized consistently — Задача/Ошибка/История/Эпик — while the GreenHopper custom fields keep their English names), i.e. not a hand-renamed type.