Der beste Zammad MCP Server? basher83 vs. Softoft / OpenTicketAI im Härtetest
Das Model Context Protocol (MCP), initiiert von Anthropic, hat sich rasant als Branchenstandard etabliert, um KI-Assistenten (wie Claude Desktop, Cursor oder Copilot) mit externen Datenquellen und APIs zu verbinden. Für das beliebte Open-Source-Ticketsystem Zammad existieren mittlerweile zwei herausragende Implementierungen eines MCP-Servers, die es KI-Modellen ermöglichen, direkt und über natürliche Sprache mit Tickets, Benutzern und Organisationen zu interagieren.
Da die Integrationen unterschiedliche Schwerpunkte setzen, lohnt sich ein genauer Blick auf die Architekturen, Lizenzen und Sicherheitsfeatures. In diesem Beitrag vergleichen wir den Community-getriebenen Server von basher83 mit der produktionsbereiten Enterprise-Lösung von Softoft-Orga / OpenTicketAI.
Die Kandidaten im Überblick
1. Zammad MCP von basher83
Dieses Projekt ist eine etablierte, hochgradig interaktive Community-Lösung. Es zeichnet sich durch einen großen Funktionsumfang aus, der besonders auf Power-User und Entwickler ausgerichtet ist, die direkt aus ihren lokalen LLM-Laufzeitumgebungen auf Zammad zugreifen möchten.
- GitHub-Repository: basher83/Zammad-MCP
- PyPI-Paket:
iflow-mcp-basher83-zammad(auf unserem Hub registriert unter /packages/iflow-mcpbasher83-zammad) - Lizenz: AGPL-3.0-or-later (eng an die Open-Source-Lizenzierung des Zammad-Kernprojekts angelehnt)
2. Zammad MCP Server von Softoft-Orga / OpenTicketAI
Dieser Server wurde speziell für den produktionsreifen Einsatz in Unternehmen entwickelt. Der Fokus liegt hier auf maximaler Sicherheit (durch ein feingranulares Berechtigungskonzept), flexibler Bereitstellung (SSE-Transport für verteilte Architekturen) und der nahtlosen Integration in das größere OpenTicketAI-Ökosystem.
- GitHub-Repository: Softoft-Orga/zammad-mcp-server
- PyPI-Paket:
zammad-mcp-server - Lizenz: MIT (äußerst permissive Lizenz, ideal für kommerzielle Integrationen und Anpassungen)
Direkter Funktionsvergleich
| Feature / Eigenschaft | basher83 (iflow-mcp-basher83-zammad) | Softoft / OpenTicketAI (zammad-mcp-server) |
|---|---|---|
| Lizenz | AGPL-3.0 (Copyleft) | MIT (Permissiv) |
| Tool-Namensgebung | Präfigiert (z. B. zammad_search_tickets) | Flach/Klar (z. B. search_tickets) |
| Anzahl der Tools | ~20 standardmäßige Operationen | 30+ Tools (vollständige API-Abdeckung) |
| Zugriffssteuerung (ACL) | Einfache Blacklist über MCP_DENIED_TOOLS | Feingranulare Tiers (DENIED, READ_ONLY, WRITE, ADMIN), Kategorien- und Gruppensperren |
| SSE-Transport (Remote) | Erfordert zusätzlichen Wrapper / SSE-Proxy | Nativ eingebaut (--transport sse --port 8000) |
| Ressourcen & Prompts | Umfassende Ressourcen (zammad://ticket/{id}) & Prompt-Vorlagen | Fokus auf Kern-APIs; Integration über Open Ticket AI Plattform |
| Caching | Caching für Gruppen, Prioritäten und Ticket-Zustände | Intelligentes Caching von statischen System-Metadaten |
| Schnittstellen-Abdeckung | Tickets, Artikel, Anhänge (Base64), Tags, Benutzer, Orgas, Gruppen, States, Stats | Tickets, Artikel, Benutzer, Orgas, Gruppen, Caching, System-Health-Checks |
Detailanalyse der Unterschiede
1. Berechtigungen und Sicherheit (Access Control)
Unternehmen, die KI-Modellen Zugriff auf ihr internes Ticketsystem gewähren, müssen strenge Sicherheitsrichtlinien durchsetzen. Hier unterscheiden sich die beiden Server am deutlichsten:
- basher83 bietet eine solide, aber einfache Absicherung: Über die Umgebungsvariable
MCP_DENIED_TOOLSkönnen bestimmte Tools (wie Lösch- oder Update-Funktionen) komplett deaktiviert werden. - Softoft / OpenTicketAI implementiert ein Enterprise-Berechtigungskonzept. Neben einer Tool-Blacklist können Zugriffsrechte auf Kategorie-Ebene (z. B. Tickets schreibgeschützt, Benutzer gesperrt) oder sogar auf Zammad-Gruppen-Ebene (z. B. nur Tickets der Gruppen "Support" und "Sales" freigeben) beschränkt werden. Zudem lässt sich die Sicherheitsrichtlinie im Python-Code hochgradig deklarativ anpassen:
policy = AccessPolicy( default_permission=Permission.READ_ONLY, category_permissions={ ToolCategory.TICKETS: Permission.WRITE, ToolCategory.ADMIN: Permission.DENIED, }, denied_tools={"delete_ticket"}, )
2. Namenskonventionen und Tool-Kollisionen
Wenn Sie mehrere MCP-Server gleichzeitig in Ihrem KI-Client (z. B. in Claude Desktop) betreiben, können Tool-Namen kollidieren:
- basher83 nutzt den Präfix
zammad_für alle angebotenen Tools (z. B.zammad_get_ticket). Das verhindert Namenskonflikte im KI-Kontext zuverlässig. - Softoft / OpenTicketAI setzt auf kurze, direkte Methodennamen (z. B.
get_ticket). Dies ist für dezidierte, spezialisierte KI-Agenten angenehmer zu lesen, erfordert jedoch Aufmerksamkeit, wenn parallel andere MCP-Server mit ähnlichen generischen Tools laufen.
3. Netzwerk- und Deployment-Architektur
Wie wird der MCP-Server gestartet und angebunden?
- basher83 ist für das klassische Stdio-Szenario optimiert (direkter Aufruf über
uvxoder Docker auf derselben Maschine, auf der der Client läuft). Er lässt sich hervorragend als lokaler Helfer einrichten. - Softoft / OpenTicketAI glänzt durch seine native SSE-Unterstützung (Server-Sent Events). Damit kann der Server als eigenständiger Webservice im Firmennetzwerk betrieben werden. Externe Clients oder zentralisierte Agenten-Plattformen können sich über HTTP/SSE verbinden, anstatt dass der Prozess lokal auf dem Desktop ausgeführt werden muss.
4. Integration in die KI-Infrastruktur
- Der Server von basher83 bringt eigene MCP-Prompts (wie
analyze_ticketoderdraft_response) und Ressourcen-URIs direkt mit. Dadurch weiß der KI-Assistent sofort, wie er typische Arbeitsabläufe strukturieren soll. - Der Server von Softoft / OpenTicketAI ist als modularer Baustein konzipiert. Er integriert sich nahtlos in die Open Ticket AI Runtime und die nativen KI-Modellanbindungen von Zammad 7. Dies ermöglicht es, komplexe Automatisierungspipelines (z. B. automatisches Klassifizieren und Beantworten von Tickets durch On-Premise-Modelle) im Hintergrund laufen zu lassen, während Agenten via MCP ad-hoc Abfragen stellen.
Konfigurations-Beispiele
Damit Sie beide Server direkt testen können, finden Sie hier die entsprechenden Konfigurationen für Ihre claude_desktop_config.json bzw. für Ihre Cursor-MCP-Einstellungen.
Konfiguration für basher83 (via PyPI/uvx)
{
"mcpServers": {
"zammad-community": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/basher83/zammad-mcp.git",
"mcp-zammad"
],
"env": {
"ZAMMAD_URL": "https://ihre-instanz.zammad.com/api/v1",
"ZAMMAD_HTTP_TOKEN": "ihr_api_token",
"MCP_DENIED_TOOLS": "zammad_delete_attachment"
}
}
}
}
Konfiguration für Softoft / OpenTicketAI (via PyPI/uvx)
{
"mcpServers": {
"zammad-enterprise": {
"command": "uvx",
"args": [
"zammad-mcp-server"
],
"env": {
"ZAMMAD_URL": "https://ihre-instanz.zammad.com",
"ZAMMAD_HTTP_TOKEN": "ihr_api_token",
"MCP_DENIED_TOOLS": "delete_ticket,delete_user,delete_organization"
}
}
}
}
Fazit: Welcher Zammad MCP Server ist der richtige für Sie?
Beide Projekte demonstrieren eindrucksvoll das Potenzial von MCP im ITSM-Umfeld. Die Wahl hängt primär von Ihrem Einsatzszenario ab:
- Wählen Sie den basher83-Server, wenn Sie als Entwickler oder IT-Profi eine schnelle, funktionsreiche Anbindung für Ihren lokalen Claude- oder Cursor-Client suchen. Die eingebauten Prompts und die präfigierten Tool-Namen machen das "Hacken" im Alltag extrem komfortabel.
- Wählen Sie den Softoft / OpenTicketAI-Server, wenn Sie Zammad in einer Unternehmensumgebung anbinden. Wenn Sie feingranulare Zugriffskontrollen erzwingen müssen, den Server als zentralen SSE-Dienst im Kubernetes-Cluster betreiben wollen oder die Integration in eine umfassende KI-Pipeline (wie Open Ticket AI) planen, ist dieser Server die professionelle Wahl.
Weitere Details zu kompatiblen Erweiterungen und Plugins für Zammad finden Sie in unserem Zammad-Plugin-Verzeichnis oder auf der offiziellen OpenTicketAI-Dokumentationsseite.
