Zammad Commander: Internal AI Chat for Your Zammad Helpdesk
Zammad Commander is an open-source internal admin chat for Zammad. Run LibreChat plus the Zammad MCP server to search tickets, summarize threads, and draft replies — in the cloud or fully on-prem with Ollama.
Zammad Commander
Zammad Commander is an open-source internal admin chat for your Zammad helpdesk. It wires LibreChat (a browser chat UI) to the Zammad MCP Server so your support agents and admins can search tickets, summarize long threads, and draft replies in plain language — without handing an AI the keys to delete anything.
It is the first setup in the “AI on Zammad” series: the same MCP server, run with different access rights, becomes a no-code automation backend or a scoped customer-facing assistant. You change the product by changing environment variables, not code.
- License: MIT
- Built on: LibreChat + Zammad MCP Server
- Runs: in the cloud (any LLM API) or fully on-prem with Ollama
- Primary use case: an internal helpdesk copilot for agents and admins
Two ways to run it
Both variants use the same LibreChat UI and the same Zammad MCP server. They differ only in where the language model runs.
| Variant A — Cloud LLM | Variant B — On-prem (Ollama) | |
|---|---|---|
| LLM | A cloud API (e.g. OpenRouter) | Ollama, local on your host |
| Data leaving your network | Prompts go to the LLM provider | Nothing — fully local |
| Needs a GPU | No | Recommended for 27B-class models |
| Best for | Fastest proof of concept | Data-residency / privacy requirements |
The on-prem variant is the right choice when ticket content must not leave your infrastructure. With a 24 GB GPU it runs Qwen 3.6 27B locally at usable speed.
Architecture
flowchart LR
Browser[Browser chat UI] --> LC[LibreChat]
LC -->|streamable HTTP /mcp| MCP[Zammad MCP server]
MCP -->|REST + API token| Z[(Your Zammad)]
LC -.Variant B only.-> Ollama[Ollama local LLM]
LC -.Variant A only.-> Cloud[Cloud LLM API]LibreChat talks to the Zammad MCP server over streamable HTTP. The MCP server holds one Zammad API token and enforces an access policy — which tool categories are allowed, which tools are denied — entirely from environment variables.
What your team can do with it
| Workflow | Example prompt |
|---|---|
| Shift handover | ”Summarize ticket #1 for a shift handover.” |
| Triage | ”List the open tickets and flag anything that looks overdue.” |
| Draft replies | ”Draft a friendly reply for ticket #1 — don’t send it, just show me the draft.” |
| Health check | ”Run a health check on Zammad and report the connected version.” |
The assistant drafts customer replies for a human to review and send; it does not send on its own.
Scoping the agent’s rights
The “internal admin” profile allows every tool category but blocks destructive deletes. Because rights are just environment variables on the MCP server, the same stack becomes a different product when you change them:
| Profile | MCP_ALLOWED_CATEGORIES | MCP_DENIED_TOOLS | Notes |
|---|---|---|---|
| Internal admin (default) | all | delete_ticket,delete_user,delete_organization | Full read/write, human-in-the-loop, no deletes |
| Read-only analyst | tickets,search,system | (default) | Look but don’t touch |
| Customer-facing | tickets,system | also deny *_user, *_organization | Plus MCP_ALLOWED_GROUPS to a public queue |
See the MCP server’s access control for the full list of categories and tools.
Hardware for the on-prem variant
The local model dominates the requirements; add these on top of the ~4 GB the rest of the stack uses (figures are for the default Q4_K_M quantization).
| Model (Ollama tag) | Download | GPU VRAM | Host RAM |
|---|---|---|---|
qwen3.5:4b | ~3.4 GB | ~5 GB | ~12 GB |
qwen3.5:9b | ~6.6 GB | ~8 GB | ~16 GB |
qwen3.6:27b (recommended) | ~17 GB | ~20 GB | ~32 GB |
A 24 GB GPU such as an NVIDIA L4 or RTX 4090 fits the 27B model comfortably.
Security notes
- Shared service account (v1). Every Commander user reaches Zammad through one API token, so all users inherit its permissions. Give that token least privilege and scope it to specific groups.
- Drafts, not auto-send. The system prompt instructs the assistant to draft replies for human review.
- Put it behind HTTPS. For anything beyond localhost, run it behind a reverse proxy with TLS and turn off open registration.
How it fits the Zammad + AI landscape
- Zammad MCP Server — the tool layer Commander is built on; also works directly from Claude Desktop and Cursor.
- Zammad Commander (this stack) — a ready-made internal chat UI on top of that MCP server.
- Open Ticket AI Runtime — on-prem inference with custom-trained classification and routing models.
FAQ
Is Zammad Commander open source?
Yes. It is MIT licensed and built entirely from open-source parts — LibreChat and the Zammad MCP Server.
Can it run without sending data to the cloud?
Yes. The on-prem variant runs the language model locally with Ollama, so ticket content never leaves your infrastructure.
Can the assistant delete tickets?
Not in the default profile — delete_ticket, delete_user, and
delete_organization are denied. You control this with MCP_DENIED_TOOLS.
Which models work on-prem?
Any model Ollama serves. The recommended default is Qwen 3.6 27B; lighter
hosts can use qwen3.5:9b.
Learn more
- Tutorial: Zammad Commander — an internal AI chat for Zammad (blog)
- Underlying tools: Zammad MCP Server
- Custom models for Zammad: Open Ticket AI for Zammad