Support custom Zammad Ticket object attributes in MCP

[kondwanidickson]

Description
Custom Ticket object attributes created in Zammad Admin are not exposed or writable through the MCP.

We added two custom ticket attributes in Zammad:

• A Single Selection field
• A Single Tree Selection field

These fields work correctly in the Zammad web UI and are enforced by Core Workflows during ticket close. However:

• get_ticket does not return the custom fields
• update_ticket does not provide a way to update arbitrary custom attributes

This prevents important production workflows such as:

• AI-assisted reporting/grouping by outage cause
• Bulk backfilling of legacy tickets after introducing mandatory custom fields
• Automation using ticket metadata

---

To Reproduce

1. Create custom Ticket object attributes in Zammad Admin
2. Populate those fields on a ticket
3. Call get_ticket through the MCP
4. Observe that the custom attributes are missing from the response
5. Attempt to update the custom fields using update_ticket
6. Observe there is no supported parameter/path for arbitrary custom fields

---

Expected behavior

Expected behavior would be either:

• Custom fields are preserved and returned automatically from get_ticket
• Or custom fields are exposed through a dedicated custom_fields object

Additionally, update_ticket should support updating arbitrary custom ticket attributes.

Possible implementation approaches could include:

• Using extra = "allow" on the Ticket model
• Adding custom_fields: dict[str, Any]
• A hybrid typed + passthrough model

---

Screenshots

• Not applicable

---

Desktop:

• OS: Ubuntu 24.04.1 LTS
• Browser: Chrome
• Environment: Production
• Primary Client Used: Claude AI

---

Additional context

We're currently using this MCP in production at an ISP in Malawi.

We noticed the repository roadmap/documentation already references:

• Bulk operations
• Expanded/union types

so this enhancement may already align with the intended architecture.

Happy to contribute a PR once implementation direction is confirmed.

— Richard, on behalf of the inq.Digital team

[kondwanidickson]

Follow-up from the inq.Digital team

We're still hitting this in production daily - our Core Workflows block ticket closure unless custom fields (single-select outage cause, tree-select service category) are set, but update_ticket has no way to write them and get_ticket silently drops them.

Having reviewed models.py, the minimal-impact path would be:

1. Ticket model - change to extra="allow" (or add custom_fields: dict[str, Any] | None = None) so the Zammad API response passthrough retains custom attributes.
2. TicketUpdateParams - add custom_fields: dict[str, Any] | None = None and pass it through to the PATCH payload in server.py.

This is backward-compatible: existing callers are unaffected; new callers opt in by passing custom_fields.

We're happy to open a draft PR implementing this if that's the preferred direction. Just let us know whether you'd prefer extra="allow" passthrough or an explicit custom_fields dict - we'll follow your lead on the approach.

Richard
inq.Digital, Malawi

[rrosson]

Confirming this independently on our own Zammad instance (self-hosted, zammad-mcp pulled as :latest). We have several custom Ticket object attributes (single-select and multi-select types) that are core to our triage workflow, and can confirm both get_ticket and search_tickets omit them entirely from their output — not just get_ticket as in the original repro. Would be a meaningful improvement for us too; happy to help test a fix if one gets picked up.

[basher83]

Type	feature request — the MCP has never modelled Zammad custom object attributes; Ticket silently drops them on read and TicketUpdateParams rejects them on write
Route	Await approval
Severity	🟡 medium — confirmed by two independent production deployments; blocks close-ticket automation where Core Workflows mandate custom fields
Confidence	high — both symptoms reproduced at the model layer and traced to specific lines; no live-instance guesswork needed
Effort	medium — small diff but spans models, client, server formatter/docstrings and tests across read + write paths
Impact	medium — a normal workflow (read/write ticket metadata) is degraded for any instance with custom attributes; workaround is the web UI, which defeats automation
Next step	Maintainer to pick the approach (recommended: extra="allow" on Ticket + explicit custom_fields dict on update/create); then plan. Reporter has offered a PR.

Understanding

Root cause (read path): Ticket in mcp_zammad/models.py:206 is a plain BaseModel with pydantic's default extra="ignore". Zammad returns custom object attributes as top-level keys on the ticket JSON (they are real columns on the tickets table), so every Ticket(**ticket_data) call discards them:

• zammad_get_ticket → server.py:1044
• zammad_search_tickets → server.py:950 (confirms @rrosson's report that search also omits them)
• zammad_update_ticket return → server.py:1172
• zammad_create_ticket return → server.py:1105
• ticket resource → server.py:2483

The client is not at fault: ZammadClient.get_ticket (client.py:196) calls zammad_py's ticket.find(), a plain GET /api/v1/tickets/{id} that returns all columns including custom attributes. The data arrives and is dropped at model construction. _format_ticket_detail_markdown (server.py:563) also only renders hard-coded fields, so even after a model fix the markdown output needs a "Custom fields" section; the JSON format (ticket.model_dump()) would pick extras up automatically.

Root cause (write path): TicketUpdateParams (models.py:367) extends StrictBaseModel (extra="forbid", models.py:21) and has a fixed field list; ZammadClient.update_ticket (client.py:242) builds update_data from that same fixed list. There is no way to pass an arbitrary key. The transport is a simple PUT /api/v1/tickets/{id} with a JSON body (zammad_py.api.Resource.update), and Zammad accepts custom attribute keys directly in that body — so nothing in the library blocks this; the parameter surface simply doesn't exist.

History: Ticket has only ever had typed fields; recent changes to this area (#211 time_unit, #174 tags, #206 email articles) all added individual typed fields. The extra="forbid" on input models was introduced deliberately to catch typos, which is a good reason not to switch TicketUpdateParams to extra="allow" — an explicit custom_fields dict preserves that safety.

Suggested direction (hybrid, as the reporter proposed):

1. Ticket: model_config = ConfigDict(extra="allow"). Custom attributes then survive model_dump() and are reachable via ticket.model_extra. Side effect: other unmodelled Zammad columns (preferences, escalation_at, type, …) also appear in JSON output — accurate but noisier. Existing tests construct Ticket(**kwargs) with known fields only, so nothing breaks.
2. TicketUpdateParams (and optionally TicketCreate): add custom_fields: dict[str, Any] | None = None. Validate keys against ^[a-z][a-z0-9_]*$ and reject keys that collide with typed params (state, priority, group, owner, customer, title, id) so the dict cannot be used to bypass the typed validators.
3. ZammadClient.update_ticket / create_ticket: accept custom_fields and merge into the payload (typed fields win on conflict).
4. _format_ticket_detail_markdown / _format_tickets_markdown: render ticket.model_extra (excluding well-known non-custom keys, or just render everything under a "Custom fields" heading — either is acceptable; keep it simple).
5. Docstrings for zammad_get_ticket / zammad_update_ticket / zammad_create_ticket should mention custom attributes so the LLM knows the capability exists.
6. Tests: Ticket retains extras; TicketUpdateParams accepts/validates custom_fields; client forwards them in the PUT payload; markdown includes them.

Not recommended: a dedicated custom_fields object on read that separates custom from built-in keys. That requires querying /api/v1/object_manager_attributes (admin-only permission) to know which keys are custom — extra API call, extra permission requirement, and caching concerns for little benefit.

Related PRs (conflict risk): #287 (pending_time), #318 (customer) and #313 (expand=true in get_ticket) all touch TicketUpdateParams / client.update_ticket / client.get_ticket. Sequence this work after those land or expect rebases. #15 (bulk operations) is the roadmap item the reporter references; this feature is a prerequisite for their backfill use case but independent of it.

Assumptions

• Classified as feature request, not bug: the MCP never claimed custom-attribute support and the maintainer already labelled it type:feature. Silent data drop on read is arguably a defect, but the fix is a new capability either way.
• Zammad returns custom attributes as top-level ticket keys and accepts them the same way on PUT — this is standard Zammad Object Manager behaviour and consistent with both reporters' descriptions; not re-verified against a live instance here.
• Recommended the hybrid approach (passthrough on read, explicit dict on write) over blanket extra="allow" on input models, to preserve the typo protection StrictBaseModel was introduced for.
• Effort rated medium rather than low because it touches read + write paths, two formatters, docstrings, and tests, and must be sequenced against three open PRs in the same files.
• Reproduction done at the model layer only (no live Zammad); this is sufficient because the drop happens in pure Python before any formatting.

Open questions

• Approve the hybrid approach (extra="allow" on Ticket + custom_fields dict on update/create), or prefer a different shape? The reporter is waiting on this decision before opening a PR.
• Should zammad_create_ticket get custom_fields in the same change, or update-only for now?
• Should zammad_search_tickets accept custom-attribute filters (e.g. outage_cause:fiber_cut via the existing free-text query) — likely already works through Zammad's search syntax, but worth documenting rather than adding params.

Reproduction

Model-layer reproduction (no Zammad instance required), run from the repo root:

uv run python - <<'EOF'
from datetime import datetime
from mcp_zammad.models import Ticket, TicketUpdateParams
import pydantic
base = dict(id=1, number="1001", title="t", group_id=1, state_id=1, priority_id=2, customer_id=3,
            created_by_id=1, updated_by_id=1, created_at=datetime.now(), updated_at=datetime.now())
t = Ticket(**{**base, "outage_cause": "fiber_cut", "service_category": "broadband::fttx"})
print([k for k in t.model_dump() if k in ("outage_cause", "service_category")])  # -> []
print(t.model_extra)                                                             # -> None
try:
    TicketUpdateParams(ticket_id=1, outage_cause="fiber_cut")
except pydantic.ValidationError as e:
    print(e.errors()[0]["type"], e.errors()[0]["loc"])                            # -> extra_forbidden ('outage_cause',)
EOF

Result: custom keys are dropped from Ticket and rejected by TicketUpdateParams, matching both reported symptoms.