Zotero-MCP-Server vs. Beaver: zwei Wege zu KI-gestützter Literaturarbeit

English version

Wer mit Zotero und einer KI arbeitet, kennt meist nur den Plugin-Weg: Beaver und vergleichbare Erweiterungen laufen direkt im Zotero-Client und beantworten Fragen zur eigenen Bibliothek. Für größere Rechercheprojekte – eine Dissertation, einen systematischen Review, ein Buchprojekt mit hunderten Quellen – stößt dieser Ansatz an Grenzen. Die Alternative: ein MCP-Server (Model Context Protocol), der Zotero als Werkzeugsatz für einen externen KI-Assistenten öffnet, statt als Plugin im Zotero-Fenster zu laufen. Dieser Beitrag vergleicht beide Architekturen.

Erarbeitet von Michael Logies in Zusammenarbeit mit Kimi Code, August 2026. Aktualisierung (August 2026): Architekturanalyse des zotero-mcp-server von DeepSeek V4 Flash (Qwen Code).

Warum MCP statt Plugin?

Beaver und vergleichbare Plugins sind für schnelle Nachfragen innerhalb von Zotero ausgezeichnet. Für ein mehrtägiges oder mehrwöchiges Rechercheprojekt wollte ich aber etwas anderes:

• Ein durchgehender Kontext. Ein Kapitel oder ein Recherche-Abschnitt ist kein einzelner Chat-Turn, sondern eine Folge aus Suchen, Lesen, Entwürfen, Korrekturen und Bauschritten. Ein MCP-Client (in meinem Fall Kimi Code) hält den Projektkontext über viele Sitzungen und kehrt bei Bedarf zu denselben Quellen zurück.
• Freie Modellwahl. Die MCP-Schicht ist modellunabhängig. Ich kann zwischen Kimi K2.6, Kimi K2.7-code, Claude Code Sonnet und anderen wechseln, ohne an der Zotero-Seite etwas zu ändern.
• Eigene Vor- und Nachverarbeitung. Der MCP-Server liefert rohen Text und Metadaten zurück, die sich durch eigene Python-Skripte, Pandoc-Filter oder Build-Pipelines schicken lassen.
• Stapelverarbeitung. Mit pyzotero als Ergänzung lassen sich auch tausende Einträge lesen oder aktualisieren, wo die MCP-Schicht zu langsam wäre.

Der Preis dafür ist mehr Einrichtungsaufwand: Der MCP-Weg ist kein Point-and-Click, sondern eher eine Entwickler-Pipeline. In der Praxis fällt der Aufwand aber geringer aus, als es hier klingt: Die Installation und Konfiguration der vier Werkzeuge (zotero-mcp-server, Zoteus, cli-anything-zotero und pyzotero) wurde in diesem Projekt zu etwa 90 % von Kimi Code selbst übernommen. Der Nutzer musste primär die Windows-Grundvoraussetzungen schaffen – Zotero mit lokaler API, SSH-Zugang und ggf. eine SMB-Freigabe –, während die Linux-Seite, die MCP-Integration und die meisten Verbindungsdetails automatisch eingerichtet wurden. Wer einen KI-Agenten wie Kimi Code oder Claude Code installiert hat, kann ihm diese Seite geben und sagen: „Richte mir das auch so ein."

Architektur

+-------------------------------------------------+
| Linux-Rechner (KI-Client)                        |
|  - MCP-Client (z. B. Kimi Code)                  |
|  - eigene Analyse-/Build-Pipeline (Python, ggf.  |
|    Pandoc/XeLaTeX)                               |
|  - Projektgedächtnis (Markdown + ggf. Memory-MCP)|
+-------------------------------------------------+
                         |
                         | SSH (stdio)
                         v
+-------------------------------------------------+
| Windows-PC (Zotero 9)                            |
|  - zotero-mcp-server                             |
|  - lokale Zotero-API aktiviert                   |
|  - vollständige PDF-Bibliothek                   |
+-------------------------------------------------+

Wichtige Einstellungen auf der Windows-Seite:

• Lokale API in Zotero aktivieren: Bearbeiten → Einstellungen → Erweitert → „Anderen Anwendungen auf diesem Computer erlauben, mit Zotero zu kommunizieren“ aktivieren. Das setzt intern die beiden Optionen extensions.zotero.httpServer.enabled und extensions.zotero.httpServer.localAPI.enabled auf true.
• Alternativ kann man diese beiden Werte auch direkt in der erweiterten Konfiguration (about:config) setzen.
• Umgebungsvariable $env:ZOTERO_LOCAL = "true" vor dem Start des Servers setzen. In PowerShell sieht das so aus:

  $env:ZOTERO_LOCAL = "true"
  zotero-mcp-server

  In einem einzeiligen SSH-Befehl werden die Variablen vor dem Serveraufruf gesetzt:

  $env:ZOTERO_LOCAL="true"; $env:ZOTERO_API_KEY="..."; $env:ZOTERO_LIBRARY_ID="..."; $env:ZOTERO_LIBRARY_TYPE="user"; zotero-mcp-server

Der Server wird per SSH vom Linux-Client aus gestartet. Die gesamte MCP-Kommunikation läuft über diese SSH-Verbindung (stdio), sodass keine zusätzlichen Ports geöffnet werden müssen. Die komplette Einrichtung auf der Linux-Seite – MCP-Client, Python-Umgebung und insbesondere die SSH-Verbindung zum Windows-Host – hat Kimi Code selbst vorgenommen.

Stabile HTTP-Konfiguration (ab August 2026)

Update 17.8.2026: Die Architektur wurde von SSH stdio auf HTTP-Transport umgestellt. Der Zotero-mcp-server läuft jetzt als permanenter HTTP-Service auf Port 8000, was deutlich stabiler und schneller ist.

Warum HTTP statt SSH?

Die ursprüngliche Architektur verwendete SSH stdio-Transport. Dabei wurde der MCP-Server über eine SSH-Verbindung gestartet, die bei Inaktivität oder Netzwerkproblemen abbrechen konnte. Seit August 2026 läuft der Server als HTTP-Service:

• Permanente Verfügbarkeit: Server startet automatisch mit Windows über eine VBS-Datei im Autostart-Ordner
• Keine CMD-Fenster: Die VBS-Datei startet den Server versteckt im Hintergrund
• Stabile Verbindung: Kein SSH-Overhead, keine Timeouts, keine abbrechenden Sessions
• Schneller: Direkte HTTP-Verbindung statt SSH-Tunnel
• Multi-Client: Mehrere KI-Agenten können gleichzeitig zugreifen

Neue Architektur

+-------------------------------------------------+
| Linux-Rechner (KI-Client)                        |
|  - MCP-Client (Qwen Code, Kimi Code, Claude)    |
|  - eigene Analyse-/Build-Pipeline               |
|  - Projektgedächtnis (Memory-MCP)               |
+-------------------------------------------------+
                         |
                         | HTTP (Port 8000)
                         v
+-------------------------------------------------+
| Windows-PC (Zotero 9)                            |
|  - zotero-mcp-server (HTTP-Server Port 8000)    |
|  - lokale Zotero-API aktiviert                   |
|  - vollständige PDF-Bibliothek                   |
|  - Autostart über VBS-Datei                      |
+-------------------------------------------------+

Einrichtung auf Windows

1. Batch-Datei erstellen (mit PowerShell, nicht mit echo!):

'set ZOTERO_LOCAL=true', 
'set ZOTERO_API_KEY=DEIN_API_KEY', 
'set ZOTERO_LIBRARY_ID=DEINE_LIBRARY_ID', 
'set ZOTERO_LIBRARY_TYPE=user', 
'zotero-mcp-server serve --transport streamable-http --host 0.0.0.0 --port 8000' | 
Out-File -FilePath C:\Users\DEIN_USER\start-zotero-mcp.bat -Encoding ASCII

Illegal header value b'Bearer DEIN_ZOTERO_API_KEY_HIER '

2. VBS-Datei für versteckten Start:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "C:\Users\DEIN_USER\start-zotero-mcp.bat", 0, False

3. Autostart aktivieren: VBS-Datei in den Windows-Startup-Ordner kopieren:

C:\Users\DEIN_USER\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

4. Firewall öffnen:

New-NetFirewallRule -DisplayName "Zotero MCP Server" -Direction Inbound -Protocol TCP -LocalPort 8000 -Action Allow

Konfiguration auf Linux

Qwen Code settings.json:

{
  "mcpServers": {
    "zotero": {
      "httpUrl": "http://192.168.0.28:8000/mcp"
    }
  }
}

Nach der Konfiguration den MCP-Server neu verbinden:

qwen mcp reconnect --all

Vergleich: SSH vs. HTTP

Benötigte Software

Windows (Zotero-Host): Zotero 9 mit aktivierter lokaler HTTP-API, zotero-mcp-server (installiert über uv), ein SSH-Server, der vom Linux-Client aus erreichbar ist.

Linux (KI-/Build-Host): ein MCP-Client (z. B. Kimi Code), bei Bedarf Pandoc und XeLaTeX für eine eigene Build-Pipeline, Python 3 mit pyzotero, ein SSH-Schlüssel für passwortlosen Login auf den Windows-Host.

Zotero-Plugins für die KI-Zusammenarbeit

Neben den MCP-Servern und CLI-Werkzeugen sind die folgenden Zotero-Plugins aktiv und für die Arbeit mit KI-Agenten unentbehrlich:

• Better BibTeX for Zotero (v9.0.61) – BibTeX/BibLaTeX-Export. Wird für die Referenzverwaltung beim Schreiben des Buches benötigt; KI-Agenten können Zotero-Items über Citation Keys referenzieren.
• Better Notes for Zotero (v3.3.3) – Erweiterte Notizfunktionen direkt in Zotero.
• Beaver (v0.23.3) – Academic Research Agent für KI-gestützte Literaturarbeit im Zotero-Client.
• Zoplicate (v5.0.9) – Duplikaterkennung und -verwaltung.
• Translate for Zotero (v2.4.7) – Übersetzung von PDFs, EPubs, Metadaten und Notizen.
• Zutilo (v4.2.2) – Makros und Tastaturkürzel. Gibt die Zotero-ID jedes Items aus, was die Kommunikation mit KI-Agenten vereinfacht.

Drei KI-Agenten, ein Zotero-Host

Die in diesem Beitrag beschriebene Architektur ist nicht auf einen einzigen KI-Agenten beschränkt. In der Praxis laufen bei mir drei Agenten parallel – Kimi Code, Claude Code und Qwen Code – die alle dieselbe Zotero-Instanz auf dem Windows-Host nutzen. Jeder Agent hat seine eigene MCP-Konfiguration (eigene settings.json, eigene API-Key-Datei), aber alle verbinden sich über denselben SSH-Zugang mit derselben Zotero-Bibliothek.

Ob parallele Zugriffe mehrerer Agenten funktionieren, habe ich mit pyzotero getestet: Über die Web-API waren fünf gleichzeitige Lesezugriffe und fünf gleichzeitige Schreibzugriffe (Tag-Updates) auf dasselbe Item erfolgreich. Über local=True (lokale API) waren ebenfalls 5/5 Lesezugriffe erfolgreich – mit 0,42 s Gesamtzeit sogar 2,6× schneller als über die Web-API (1,09 s). Die MCP-Server (zotero-mcp-server, Zoteus) arbeiten sequenziell: Der alte zotero-mcp-server stürzt bei parallelen Anfragen bekanntermaßen ab; Zoteus und cli-anything-zotero sind auf sequenzielle Nutzung ausgelegt und waren in allen Tests stabil.

Der praktische Vorteil der Multi-Agenten-Architektur: Man kann den Agenten wechseln, ohne auf der Zotero-Seite etwas neu einzurichten. Mehr dazu im Beitrag „Von Kimi Code K2.7-code zu Qwen Code: Ein dritter Agent im Team". Die Infrastruktur (SSH-Server, lokale API, Zotero-Storage) bleibt gleich; nur der MCP-Client auf der Linux-Seite tauscht sich aus. Jeder Agent bringt seine eigenen Werkzeuge, Prompts und sein eigenes Sitzungs-Gedächtnis mit.

Werkzeuge im Vergleich: vier Zugänge zu Zotero

Nachdem der ursprüngliche zotero-mcp-server gut lief, aber bei großen PDFs, Notizen und Import-Aufgaben gelegentlich an seine Grenzen stieß, habe ich im August 2026 zwei weitere Werkzeuge getestet: Zoteus und cli-anything-zotero. Beide greifen ebenfalls auf die lokale Zotero-Instanz zu, lösen aber unterschiedliche Probleme. Die folgende Tabelle fasst die Ergebnisse zusammen und ergänzt pyzotero als vierte Säule.

Stand August 2026. Die Bewertungen beziehen sich auf den jeweiligen Stand der getesteten Versionen.

Technisch sind diese vier Werkzeuge voneinander unabhängig. Praktisch lässt sich der Mehr-Tool-Workflow aber nur mit einem sitzungsübergreifenden Gedächtnis verlässlich betreiben: Sonst müsste in jeder Sitzung neu entschieden werden, welches Tool für welche Aufgabe das richtige ist, und welche Workarounds gerade gelten. Ich nutze dafür einen Memory-MCP-Server, der den Tool-Vergleich, die Benchmarks und die Regeln über Sitzungen hinweg speichert. Mehr dazu auf der Seite zum Memory-MCP-Server.

zotero-mcp-server

Der zotero-mcp-server war unser Einstieg in den MCP-Weg. Er funktioniert für die meisten Standardaufgaben, hat sich aber in der Praxis als etwas wackelig erwiesen: einzelne Aufrufe hängen, bei parallelen Anfragen kann der Server abstürzen, und große PDFs werden bei zotero_get_item_fulltext auf etwa 50 Seiten abgeschnitten. Sein verbleibender Vorteil ist die semantische Suche über den lokal aufgebauten Index – sofern dieser Index auf dem Windows-Host einmal erfolgreich gebaut wurde. Das blockweise Lesen großer PDFs über zotero_read_pdf_pages ist weniger zwingend, sobald der Zotero-Storage zusätzlich als SMB-Freigabe im LAN verfügbar ist.

HTTP-Transport (seit 17.8.2026): Der Server lief zeitweise als permanenter HTTP-Service auf Port 8000 (statt über SSH stdio). Das eliminierte den SSH-Overhead: Die Initialisierung war 40–77× schneller (0,04 s statt 3 s), und die Verbindung war stabiler – keine SSH-Session-Abbrüche, kein CMD-Fenster. Die Datenabfragen selbst waren allerdings gleich schnell wie über SSH, weil der Flaschenhals die Zotero Local API auf dem Windows-Host ist, nicht der Transportweg.

Inzwischen nicht mehr im Einsatz. Der zotero-mcp-server war wiederholt instabil – Abstürze bei parallelen Anfragen, hängende Aufrufe, unklare Timeouts. Eine Analyse des Quellcodes durch DeepSeek V4 Flash identifizierte grundlegende Architekturprobleme: einen globalen RLock, der alle Zugriffe serialisiert, die Abhängigkeit von pyzoteros hardcodiertem 30s-Timeout und fehlendes Session-Management. Zoteus ist der vollwertige, stabile Ersatz und wird seit August 2026 ausschließlich genutzt.

Zoteus

Zoteus ist ein alternativer MCP-Server mit 30 Werkzeugen (Stand: v1.15.0, September 2026). Inzwischen gibt es auch eine schriftliche Einrichtungsanleitung (zoteus.com/docs/connect-claude-to-zotero) für Claude Desktop, claude.ai, Claude Code sowie Cursor, VS Code, Zed und Codex. In Tests war er deutlich stabiler und schneller als der ursprüngliche Server. Besonders gut funktionieren Suche, Metadaten-Abruf, CSL-Zitationen und einfache Schreiboperationen wie Tags oder Trash. Ein zusätzlicher Vorteil ist die Einbindung von OpenAlex mit semantischer Suche – vergleichbar mit der entsprechenden Funktion in Beaver.

Seit v1.2.0 (18.8.2026) hat Zoteus drei wichtige Verbesserungen erhalten, die genau die Schwächen aus unseren GitHub-Issues beheben:

• DOI-Import ohne Docker: zotero_import löst DOIs direkt über OpenAlex/Crossref auf, arXiv-IDs über die arXiv API. Kein Translation-Server mehr nötig.
• PDF-Volltext-Fallback: zotero_get_fulltext lädt jetzt automatisch das PDF und extrahiert Text on-the-fly, wenn Zotero es nicht indexiert hat. Liefert exakte Seiten-Lokatoren.
• Auto-Build für semantische Suche: zotero_semantic_search startet automatisch den Index-Build beim ersten Aufruf. Keine manuellen Schritte mehr.

ISBN/PMID/bibcode und URL-Scraping benötigen weiterhin einen Translation-Server. Ansonsten ist Zoteus jetzt ein vollwertiger Ersatz für den alten zotero-mcp-server für die meisten Anwendungsfälle.

OpenAlex und semantische Suche

Über OpenAlex greift Zoteus auf einen offenen, ständig aktualisierten akademischen Graphen zu – ein Netzwerk aus wissenschaftlichen Artikeln, Autoren, Institutionen und Konzepten, verbunden durch Zitationen, Kooperationen und thematische Verwandtschaft. Das erlaubt semantische Suchen, die nicht auf die eigene Zotero-Bibliothek beschränkt sind: Der Agent kann nach Konzepten formulieren und bekommt verwandte Arbeiten geliefert, auch wenn sie noch nicht im lokalen Bestand vorhanden sind. In unserem Workflow läuft das über zotero_scholar; gefundene DOIs werden bei Bedarf direkt nach Zotero importiert. Dafür stehen drei Wege offen: (1) Zoteus mit zotero_import (seit v1.2.0 über OpenAlex/Crossref, kein Translation-Server nötig); (2) zotero_add_item vom zotero-mcp-server, das DOIs direkt über CrossRef/DOI.org auflöst; (3) cli-anything-zotero mit add doi ... --fetch-pdf, das gleichzeitig das PDF mitlädt.

Um importierte Einträge von bestehenden zu unterscheiden, versehen wir sie mit dem Tag imported by Kimi. Das klingt banal, erleichtert aber die Nachverfolgung erheblich: Alle neu hinzugekommenen Titel lassen sich über diesen Tag auf einen Blick anzeigen, ihre Anhänge gezielt prüfen und fehlende PDFs gezielt nachladen. Wer viel importiert, merkt schnell, dass diese kleine Konvention der entscheidende Unterschied zwischen „irgendwo in der Bibliothek gelandet" und „bewusst im Workflow aufgenommen" ist.

Volltexte beschaffen

OpenAlex liefert in vielen Fällen direkt einen Link zum Open-Access-PDF. Ist das der Fall, holt der Agent das PDF gleich mit. Wenn OpenAlex keinen direkten Volltext anbietet, greifen wir auf cli-anything-zotero zurück: Der Befehl add doi 10.xxxx/xxxxx --fetch-pdf importiert den Eintrag über die DOI und versucht gleichzeitig, das PDF herunterzuladen. Alternativ lässt sich der Eintrag über zotero_add_item vom zotero-mcp-server mit der DOI importieren; das ist schneller und erfordert keinen Translation-Server, holt aber im Gegensatz zu cli-anything-zotero nicht automatisch das PDF. Das funktioniert in unseren Tests zuverlässig, solange eine frei verfügbare Quelle existiert. Bleibt der Anhang leer, weil das Werk hinter einer Paywall steckt, bleiben zwei manuelle Wege: der Zotero-Connector im Browser oder das gezielte Nachladen über die eigene Institution. Sobald der Eintrag in Zotero landet, wird er mit imported by Kimi getaggt; an diesem Tag erkennen wir später, welche Volltexte noch geprüft oder ergänzt werden müssen.

Universitäts-VPN. Wenn der Windows-Rechner, auf dem cli-anything-zotero läuft, über ein Universitäts-VPN mit dem Netz verbunden ist, können auch viele nicht frei verfügbare Zeitschriftenartikel automatisch bezogen werden – sofern die Hochschule entsprechende Lizenzen hält. Der VPN-Tunnel muss dabei auf dem Zotero-Host aktiv sein, nicht auf dem Linux-Client. Manche Verlage verlangen zusätzlich Shibboleth/SSO oder Cookies; dann funktioniert der automatische Download nicht und der Zotero-Connector im Browser mit VPN ist der zuverlässigere Weg.

cli-anything-zotero

cli-anything-zotero ist kein MCP-Server, sondern ein Python-CLI-Toolkit, das über eine JavaScript-Bridge direkt mit Zotero spricht. Es muss deshalb über SSH als Shell-Befehl aufgerufen werden. Dafür ist es sehr leistungsfähig: DOI-Import inklusive PDF-Download, vollständige Volltextsuche, Notizen lesen und schreiben, Tags, Zitationen und sogar DOCX-Zitationen funktionieren. Wer tiefer in Zotero hineinprogrammieren will, kann mit zotero-cli js ... direkt JavaScript-Code an Zotero senden.

Empfohlene Kombination

In der Praxis ergänzen sich die drei aktiven Werkzeuge:

• Zoteus als Standard-MCP-Server für schnelle, stabile Lesezugriffe (Suche, Metadaten, Zitationen), DOI-Import, PDF-Volltext (auch nicht indexiert) und einfache Schreibzugriffe. Seit v1.2.0 ein vollwertiger Ersatz für den alten zotero-mcp-server.
• cli-anything-zotero als Spezialwerkzeug für Import mit PDF-Fetch, Volltextsuche, Notizen und komplexe Aufgaben, die direkten Zotero-Zugriff erfordern.
• pyzotero als Python-Bibliothek für Massenoperationen (Export, Tag-Updates, Volltext-Lesen). Besonders geeignet für parallele Zugriffe und große Datenmengen, wo MCP-Server an ihre Grenzen stoßen. Läuft in der venv /home/ml/.venv-zotero/.

Der zotero-mcp-server wird nicht mehr genutzt. Aufgrund wiederholter Stabilitätsprobleme (Abstürze, Timeouts, hängende Aufrufe) wurde der Server durch Zoteus ersetzt. Eine Architekturanalyse des Quellcodes bestätigte grundlegende Designschwächen (globaler RLock, fehlende Session-Isolation, pyzotero-Abhängigkeit). Der HTTP-Transport (Port 8000) half gegen SSH-Abbrüche, löste aber nicht die zugrundeliegenden Server-Probleme.

Welches Tool für welche Aufgabe?

Stand 23.8.2026. Zotero-MCP-Server wird nicht mehr genutzt; Zoteus ist der aktive Standard.

Ergänzung: pyzotero für Stapelverarbeitung

Für Massenlese- oder -schreibvorgänge kann die MCP-Schicht langsam sein. Kimi Code hat sich dafür selbst die Python-Bibliothek pyzotero eingerichtet und setzt sie eigenständig ein, wenn ihr das sinnvoller erscheint als der Weg über MCP – etwa für Massenexport von Abstracts, Hochladen fertiger Notizen als Zotero-Kindnotizen oder Massenänderungen an Tags und Metadaten.

Gemessen im August 2026 über einen SSH-Tunnel zur lokalen Zotero-API auf einem Windows-Host. Der MCP-Server muss für jeden Aufruf neu gestartet werden; die angegebenen Zeiten enthalten diesen Start-Overhead. Die pyzotero-Werte beziehen sich auf eine bereits laufende Python-Sitzung.

Wichtig: pyzotero kann grundsätzlich auf zwei Arten betrieben werden. Über die Web-API bei zotero.org spricht es mit den synchronisierten Bibliotheksdaten – ohne dort hinterlegte Volltexte gibt es hier keine PDF-Inhalte. Alternativ lässt sich mit dem Parameter local=True die lokale Zotero-HTTP-API auf demselben Rechner ansprechen; das geht aber derzeit nur lesend (Stand August 2026, pyzotero 1.13.5). Ein entsprechendes offenes Issue für Schreibzugriffe existiert auf GitHub (#344). Schreibzugriffe und der Literaturverzeichnis-Export überlässt Kimi Code deshalb weiterhin dem MCP-Server, weil nur dieser im lokalen Modus Schreiboperationen bereitstellt.

PDF-Volltexte: Text ja, Binärdatei nein. Über pyzotero local=True und den Endpunkt /fulltext lassen sich PDF-Volltexte als reiner Text extrem schnell auslesen – für ein ca. 40.000 Zeichen langes PDF waren es etwa 0,06 s, für ein 442-seitiges Lehrbuch mit über 1,6 Millionen Zeichen problemlos in einem Aufruf. Der direkte Download der Original-PDF-Datei über pyzotero.file() oder den API-Endpunkt /file scheitert aus der Linux-VM: Zotero antwortet mit einem Redirect auf file://localhost/C:/Users/..., also einen lokalen Windows-Pfad. Die Linux-VM kann diesen Pfad nicht auflösen. Wer das Original-PDF braucht, nutzt besser den SMB-Zugriff auf den Zotero-Storage.

Wann welchen Weg nehmen? Für reine Leseoperationen an Metadaten oder PDF-Text ist pyzotero local=True deutlich schneller und spart MCP-Overhead. Der MCP-Server bleibt der bequemere Weg, wenn Kimi Code den Parent-Item-Key hat und der Server intern den passenden Attachment-Key auflösen soll, oder wenn Schreibzugriffe, Annotationen und der Literaturverzeichnis-Export nötig sind.

Pflegezustand: pyzotero wird aktiv gepflegt. Die aktuelle Version 1.13.5 erschien am 5. August 2026 auf PyPI; der Quellcode liegt auf GitHub. Über PyPI-Updates oder GitHub-Releases lässt sich verfolgen, ob eine neue Zotero-Version Änderungen am lokalen API-Verhalten erfordert.

Benchmark-Ergebnisse

Die folgenden Zeiten wurden im August 2026 in einem lokalen Netzwerk gemessen: Der KI-Client läuft in einer Linux-VM, Zotero auf einem Windows-Host. Alle vier Werkzeuge wurden am 16. August 2026 mit denselben Benchmark-Skripten erneut getestet – die Ergebnisse sind mit den Messungen vom 11. August stabil reproduzierbar (siehe Hinweis zur Reproduktion).

HTTP-Transport: zotero-mcp-server ohne SSH-Overhead (17.8.2026)

Seit dem 17. August 2026 läuft der zotero-mcp-server als permanenter HTTP-Service auf Port 8000 (statt über SSH stdio). Der Vergleich zeigt: Meta-Operationen sind 40–77× schneller, weil der SSH-Overhead entfällt. Die Datenabfragen selbst bleiben gleich schnell – der Flaschenhals ist die Zotero Local API auf dem Windows-Host, nicht der Transportweg.

Gemessen am 17.8.2026 über HTTP (Port 8000) bzw. am 16.8.2026 über SSH-Tunnel. Zwei Durchläufe über HTTP zeigten identische Zeiten – kein Cache-Warmup-Effekt messbar. Die Datenabfragen sind transport-unabhängig, weil die Zotero Local API der Flaschenhals ist.

Praktische Bedeutung: Für die interaktive Arbeit bedeutet der HTTP-Transport vor allem einen spürbaren Vorteil beim Verbindungsaufbau – die Session steht sofort, ohne SSH-Timeouts oder Abbrüche. Sobald die Session etabliert ist, bestimmt die Zotero Local API das Tempo. Für schnelle Lesezugriffe bleibt Zoteus die erste Wahl (< 0,01 s); der zotero-mcp-server lohnt sich dort, wo seine spezifischen Fähigkeiten gebraucht werden (semantische Suche, Annotationen, PDF-Layout).

Sequenzielle Benchmarks: Alle vier Werkzeuge im Vergleich

Getestet wurden dieselben Operationen über alle vier Zugriffswege. Die Tabelle zeigt die gemessenen Einzelzeiten in Sekunden. Pro Tool wird exakt angegeben, welche Operationen im Benchmark getestet wurden.

¹ cli-anything-zotero: app ping als Proxy für Init+Verbindung. ² pyzotero: keine Init-Kosten (Python-Bibliothek, kein Server-Start). ³ Zoteus: zotero_get_item liefert Kinder direkt mit. ⁴ cli-anything-zotero: search-fulltext durchsucht alle PDFs, nicht nur ein einzelnes. ⁵ cli-anything-zotero: keine direkte Such-API, nur search-fulltext. ⁶ pyzotero: items(limit=20), nicht identisch mit MCP-Suche.

Gemessen am 16.8.2026 über SSH-Tunnel zur lokalen Zotero-API auf einem Windows-Host. MCP-Server (zotero-mcp-server, Zoteus) werden für jeden Aufruf über SSH+PowerShell gestartet; die Init-Zeit enthält diesen Overhead. pyzotero läuft in einer bereits offenen Python-Sitzung. „—" = Operation wurde im Benchmark für dieses Tool nicht getestet.

Parallele Zugriffe: pyzotero (5 gleichzeitige Threads)

Während die MCP-Server sequenziell arbeiten müssen (der alte zotero-mcp-server stürzt bei parallelen Anfragen ab), kann pyzotero parallele Zugriffe bedienen. Getestet mit 5 gleichzeitigen Threads:

pyzotero local=True ist damit 2,6× schneller als die Web-API bei parallelen Lesezugriffen (0,42 s vs. 1,09 s). Die Threads laufen nahezu identisch (0,33–0,35 s), was zeigt, dass die lokale API parallele Zugriffe ohne Contention verarbeitet. Schreibzugriffe über die Web-API funktionieren ebenfalls stabil – pyzotero holt in jedem Thread das Item neu (mit aktueller Version), bevor es aktualisiert, wodurch Versionskonflikte vermieden werden.

Hinweis zur Reproduktion

Das sequenzielle Benchmark-Skript (mcp_zotero_benchmark.py) wurde am 11.8.2026 und am 16.8.2026 mit identischer Konfiguration ausgeführt. Die Ergebnisse sind stabil reproduzierbar:

Die Abweichungen liegen im Bereich von Netzwerk-Latenz und SSH-Handshake-Schwankungen. Die Init-Zeit des MCP-Servers variiert stärker (2,98 s → 4,47 s), weil PowerShell-Start und SSH-Verbindungsaufbau nicht deterministisch sind. Nach dem Init sind alle Operationen stabil.

Härtetest: semantische Suche im Vollindex — Zoteus vs. zotero-mcp-server (28.8.2026)

Am 28. August 2026 lief Zoteus erstmals mit einem vollständigen Index: 10.184 Items, 255.703 Passagen (222.514 davon aus PDF-Volltexten), Embedding-Modell text-embedding-3-large (3072 Dimensionen), SQLite-Backend (Node 24 mit FTS5). Der direkte Vergleich mit dem ChromaDB-Index des zotero-mcp-servers (~120.000 Dokumente, derselbe Embedding-Anbieter) über fünf identische Suchanfragen zeigte ein unerwartetes Bild: Bei der semantischen Suche ist der operativ viel schnellere Zoteus rund 8× langsamer.

Eine RAM-Messung (Abtastung alle 3 Sekunden über die komplette Laufzeit einer Abfrage) grenzt die Ursache ein: Der Speicher bleibt während der gesamten Suche flach (~110 MB Working Set, identisch zur Baseline). Zoteus lädt die Vektoren also nicht ins RAM, sondern iteriert alle 255.000 Vektor-Zeilen einzeln aus SQLite und berechnet die Ähnlichkeit in JavaScript — konstanter Speicher, CPU-gebunden, linear in der Korpusgröße. ChromaDB hält dagegen einen persistenten ANN-Index (HNSW) und zahlt pro Abfrage logarithmische statt linearer Kosten.

Update 29.8.2026: Der Zoteus-Maintainer hat das Problem inzwischen auf main behoben (ausgeliefert in v1.10.0): zweistufige Suche mit 1-Bit-Binärcodes (Hamming-Scan) und exaktem Nachranken — gemessen 2,3 s statt ~95 s bei exakt dieser Geometrie, Faktor 42.

Update 31.8.2026 (live verifiziert): Zoteus v1.12.0 ist auf dem Windows-Host installiert: nach einmaligem Aufbau der ANN-Codes bei der ersten Abfrage (266 s) liegen alle Folgeabfragen bei 0,33–0,84 s — besser als die prognostizierten 42×. Kein Re-Embedding nötig.

Die Trefferqualität ist auf beiden Seiten brauchbar, aber unterschiedlich gewichtet: Beide fanden die zentralen Treffer (etwa die ZE-Zeitplanungs-Notiz bzw. das FZ-Kompendium), die Top-5-Überlappung lag jedoch nur bei etwa 1/5 — Zoteus mischt über Reciprocal Rank Fusion (BM25 + Vektor) und findet dafür tiefe Volltext-Passagen, der zotero-mcp-server liefert konsistent fünf Treffer mit Seiten-Lokatoren.

Folgerung für den Werkzeugeinsatz: Die Wahl hängt vom Anwendungsfall ab. Für alle Lese-, Schreib- und Verwaltungsoperationen bleibt Zoteus rund 100–700× schneller (< 0,01 s statt 2–7 s) — für die semantische Suche galt der zotero-mcp-server mit ChromaDB bis zur Verifikation von Zoteus v1.12.0 als die praktikable Wahl. Update 31.8.2026: Zoteus v1.12.0 ist installiert und live verifiziert (0,33–0,84 s pro Abfrage) — die semantische Suche läuft jetzt vollständig über Zoteus; der zotero-mcp-server wurde deaktiviert (ChromaDB-Dateien bleiben für einen Rollback erhalten). Beide Befunde wurden als Feature-Requests an Zoteus gemeldet — und sind inzwischen (29.8.2026) vom Maintainer auf main implementiert, ausgeliefert in v1.10.0: Robuste Volltext-Extraktion (#29) (lokale Fallback-Extraktion inkl. PDF-Outline und EPUB) und ANN-Index für die semantische Suche (#30) (zweistufige Suche mit 1-Bit-Binärcodes: 2,3 s statt ~95 s bei unserer Geometrie).

Prompt-Strategie: Daueranweisungen statt Wiederholung

Für wiederkehrende Zotero-Aufgaben lohnt sich eine feste Standardanweisung, die nicht bei jeder Anfrage neu formuliert werden muss. Typische Bausteine:

• Sprache und Zielgruppe (z. B. Fachpublikum mit erklärungsbedürftiger Terminologie)
• Evidenzhierarchie und GRADE-Logik bei wissenschaftlicher oder medizinischer Literatur
• aktiver Widerspruch bei Sachfehlern statt stillschweigender Übernahme
• Präzisionsregeln für die Wiedergabe von Zahlen und Daten
• ein festes Ablaufprotokoll für Notizen (Recherche → Volltextprüfung → Verfassen)
• Formatierungsregeln für Zotero-Notizen (Markdown beim Anlegen, vereinfachtes HTML beim Aktualisieren)

Eine solche Anweisung lässt sich in einem Memory-Server ablegen und automatisch zu Beginn jeder Zotero-Aufgabe laden – siehe dazu die Seite zum Memory-MCP-Server.

Kosten und Datenschutz

• Zotero-MCP-Server: kostenlos und quelloffen.
• KI-Modelle: Abrechnung über den jeweiligen API-Anbieter, abhängig von Kontextlänge und Anzahl der Aufrufe.
• Kein Upload an Dritte: Läuft der Server lokal auf dem Zotero-Host, verlassen die Volltexte nie das eigene Netzwerk.
• Semantische Suche: Der Server kann lokale Embeddings oder externe Anbieter nutzen. Der Index wird typischerweise einmal aufgebaut und danach nur gelesen, nicht automatisch neu berechnet.

Tipps und Stolpersteine

Parallele Zugriffe und HTTP-Transport

Seit dem HTTP-Transport (17.8.2026) läuft der zotero-mcp-server als permanenter Service auf Port 8000 und ist multi-client-fähig. Parallele Anfragen sind jetzt möglich – im Gegensatz zur alten SSH-stdio-Version (0.9.0), die bei parallelen Aufrufen abstürzen konnte. Zoteus und cli-anything-zotero waren auch in der alten Version stabil bei parallelen Zugriffen.

Dennoch gilt als Daumenregel: Für die meisten Aufgaben ist sequenzielle Abarbeitung schneller, weil die Zotero Local API der Flaschenhals ist, nicht der Transport. Parallele Aufrufe lohnen sich vor allem bei pyzotero über die Web-API, wo sie getestet wurden (5 parallele Lesezugriffe in 0,88 s).

Große PDFs seitenweise lesen

Wenn der Zotero-Storage als SMB-Freigabe im LAN verfügbar ist, liest Kimi Code große PDFs am liebsten direkt aus dem Dateisystem. Das ist schneller und liefert das komplette Dokument. Der Weg über zotero_read_pdf_pages im alten zotero-mcp-server bleibt nur als Fallback, wenn kein SMB-Zugriff eingerichtet ist oder wenn sehr gezielt einzelne Seiten gebraucht werden. Wer pyzotero mit local=True verwendet, bekommt den kompletten Volltext üblicherweise in einem Aufruf (fulltext_item) – das war bei einem 442-seitigen Lehrbuch mit über 1,6 Millionen Zeichen problemlos möglich.

Build-Warnungen ernst nehmen

Wer aus recherchierten Quellen ein Dokument baut (z. B. mit Pandoc/Citeproc), sollte Zitier-Warnungen nicht ignorieren: Eine Meldung wie [WARNING] Citeproc: citation ... not found bedeutet fast immer eine Textstelle ohne verknüpfte Quelle.

Erreichbarkeit bei Sitzungsstart prüfen

Es lohnt sich, bei jedem Start automatisch zu prüfen, ob Zotero-MCP – und ein eventueller Memory-MCP – erreichbar sind, bevor die eigentliche Arbeit beginnt. So bleibt ein Ausfall nicht unbemerkt, bis mitten in der Recherche ein Werkzeugaufruf fehlschlägt.

Verbindungsarten: HTTP und SSH

Der zotero-mcp-server läuft seit dem 17.8.2026 als permanenter HTTP-Service auf Port 8000. Die Kommunikation erfolgt direkt über HTTP, nicht über SSH. Der Server startet automatisch beim Windows-Login (versteckt über eine VBS-Datei) und ist multi-client-fähig.

Zoteus und cli-anything-zotero werden weiterhin über SSH als Subprozesse auf dem Windows-Host gestartet. Die Kommunikation läuft über stdio durch die SSH-Verbindung. Der SSH-Benutzer ml kann dabei beliebige Befehle auf dem Windows-Rechner ausführen – alles, was ein normaler Windows-Benutzer darf.

Die einzige Einschränkung sind die Benutzerrechte von ml: Dieser Account hat bewusst keine Administratorrechte. Damit sind Systemdateien, Registry-Änderungen und geschützte Bereiche des Windows-Dateisystems nicht zugreifbar. Innerhalb der normalen Benutzerrechte hat die KI jedoch vollen Zugriff – sie kann Dateien lesen, schreiben, Programme starten und natürlich die Zotero-Schnittstelle nutzen.

Für den reinen Zotero-Betrieb ist das ausreichend: Die MCP-Server sprechen mit der lokalen Zotero-API (Port 23119, nur an localhost gebunden), und für den Zugriff auf die Original-PDFs steht die SMB-Freigabe des Zotero-Storage zur Verfügung. Weitere Port-Weiterleitungen oder separate Zugriffswege sind dafür nicht nötig.

Grafiken und Abbildungen aus PDFs auswerten

Die vier getesteten Tools (zotero-mcp-server, Zoteus, cli-anything-zotero, pyzotero) decken die meisten PDF-Aufgaben ab: Volltext lesen, Metadaten, Annotationen, Suche. Für Grafiken, Karten, Tabellen oder historische Abbildungen reicht reiner Text jedoch nicht immer. Hier bietet der direkte Dateizugriff über SMB zusätzliche Möglichkeiten:

¹ Zoteus liefert nur Volltexte, die Zotero bereits indexiert hat. ² pyzotero file() scheitert aus der Linux-VM (Redirect auf lokalen Windows-Pfad).

Für den direkten Dateizugriff ist der Zotero-Ordner als SMB-Freigabe eingebunden:

• /mnt/zotero-storage – die Storage-Ordner mit den PDFs und Anhängen, sortiert nach Zotero-Item-Key (z. B. /mnt/zotero-storage/222BTP99/article.pdf).

Voraussetzung sind die SMB-Freigaben und eine Credentials-Datei auf dem Linux-Client (~/.smbcredentials). Das Passwort steht nur in dieser lokalen Datei, nicht in Befehlen oder Dokumentation:

username=DEIN_BENUTZERNAME
password=DEIN_PASSWORT

Damit lassen sich zwei Dinge tun:

• Seiten als Bilder rendern: Mit pdftoppm -png datei.pdf prefix wird jede PDF-Seite zu einer PNG-Datei, die das Sprachmodell direkt analysieren kann.
• Eingebettete Bilder extrahieren: Mit pdfimages -j datei.pdf prefix werden die ursprünglich in die PDF eingebetteten Rasterbilder (JPEG, PNG, PPM) wieder herausgelöst. Das ist präziser als das Seitenrendering, wenn nur einzelne Abbildungen interessieren.

Geschwindigkeit über SMB: Gemessen an einer 3 MB großen PDF mit mehreren eingebetteten Bildern (August 2026, SMB-Mount auf /mnt/zotero-storage):

Die Zeiten beziehen sich auf einzelne Testdurchläufe; sie schwanken je nach Netzwerklast und PDF-Komplexität.

Getestet wurde das mit einem Text-PDF (Titelseite gerendert) und einem bildreichen PDF, in dem historische Darstellungen und Karten extrahiert und beschrieben wurden. Der Weg ist vor allem dann nützlich, wenn Zusatzmaterialien wie .docx-Dateien oder Original-PDFs nicht über die Zotero-API, sondern direkt aus dem Dateisystem verarbeitet werden müssen.

Lokale API vs. zotero.org

Der wichtigste Konfigurationsfallstrick betrifft die Frage, wo der MCP-Server die Daten herbekommt. Der Server kann im lokalen Modus direkt auf die Zotero-Instanz auf dem Windows-Host zugreifen – oder im Web-Modus über die Zotero-Sync-Server bei zotero.org. Für Volltexte macht das einen dramatischen Unterschied.

• Voraussetzung für den lokalen Modus: Vor dem Start des Servers muss die Umgebungsvariable $env:ZOTERO_LOCAL = "true" gesetzt sein. Ohne diese Variable greift der Server auf zotero.org zu.
• Volltexte müssen lokal verfügbar sein. Wer – wie ich – die PDF-Volltexte in den Zotero-Synchronisationseinstellungen gezielt von zotero.org ausschließt, hat in der Web-API keine PDF-Inhalte vorliegen. Ein Aufruf wie zotero_get_item_fulltext würde dann leer ausgehen oder nur Abstracts liefern. Standardmäßig synchronisiert Zotero Volltexte sehr wohl; die Entscheidung, sie nicht zu synchronisieren, muss bei der Einrichtung bewusst getroffen werden.
• pyzotero ist nicht auf zotero.org beschränkt. Mit dem Parameter local=True kann pyzotero auch die lokale Zotero-HTTP-API auf demselben Rechner nutzen. Das ist praktisch für lesende Massenoperationen an Metadaten, liefert aber derzeit keine Schreibzugriffe. Für Schreiboperationen und Annotationen muss der Weg über den MCP-Server mit aktivierter lokaler API genommen werden. PDF-Volltexte als reiner Text können über pyzotero local=True sehr schnell abgerufen werden; der Download der Original-PDF-Datei als Binärdatei scheitert aus einer entfernten Linux-VM, weil Zotero einen Redirect auf einen lokalen Windows-Pfad (file://localhost/...) liefert.
• Zotero bindet die lokale API an localhost. Der Port 23119 ist absichtlich nur an 127.0.0.1 gebunden. Ein direkter Zugriff über die LAN-IP funktioniert auch mit geöffneter Firewall nicht. Wer von einem anderen Rechner im LAN aus zugreifen will, braucht einen SSH-Tunnel oder einen Reverse-Proxy auf dem Zotero-Host.

Als Faustregel gilt: Sobald PDF-Inhalte, Annotationen oder große Bücher ins Spiel kommen, muss der Server im lokalen Modus laufen. Nur für reine Metadaten-Operationen ist der Web-Modus akzeptabel.

Vergleich: Plugin vs. MCP-Server

Für eine einzelne Literaturfrage ist Beaver schneller eingerichtet und schneller am Ziel. Für ein umfangreiches Projekt mit hunderten Quellen ist die MCP-Pipeline die flexiblere Wahl.

Wann lohnt sich der MCP-Weg?

Der MCP-Ansatz lohnt sich, wenn eine oder mehrere dieser Bedingungen zutreffen:

• Es handelt sich um ein Langform-Projekt (Buch, Dissertation, systematischer Review).
• Dieselben Quellen werden in mehreren Formaten gebraucht – Notizen, Textabschnitte, Literaturverzeichnis.
• Eine eigene Build-Pipeline ist gewünscht (Pandoc, LaTeX, eigene Filter).
• Die PDFs sollen auf einem lokalen Rechner bleiben, während die KI auf einem anderen Host läuft.

Ein konkretes Beispiel für einen so aufgebauten Workflow – von der thematischen Clusterbildung bis zum fertigen Buch aus 198 Quellen – beschreibt das Cliodynamics-Buchprojekt.

Benchmark-Skript zum Nachvollziehen

Die auf dieser Seite genannten Zeiten wurden mit einem reproduzierbaren Python-Benchmark gemessen. Das Skript vergleicht den Zotero-MCP-Server über SSH, direkte Aufrufe der lokalen Zotero-HTTP-API und pyzotero mit local=True. Es ist absichtlich so gebaut, dass es in unter zwei Minuten durchläuft und hängende MCP-Aufrufe mit einem Timeout abbricht.

• mcp_zotero_benchmark.py – das Benchmark-Skript
• requirements-mcp-benchmark.txt – benötigte Python-Pakete
• mcp_zotero_benchmark_report.md – beispielhafter Report
• installationsanleitung-zotero-tools-windows.md – Schritt-für-Schritt-Anleitung für Zoteus und cli-anything-zotero unter Windows
• Arbeitsbericht_Tool-Evaluation_2026-08-13.md – vollständiger Arbeitsbericht der Evaluation
• vergleich-zotero-tools.md – Kurzvergleich aller drei Tools
• benchmark_cli_anything_zotero.py – Benchmark-Skript für cli-anything-zotero
• benchmark_cli_anything_zotero.json – beispielhafte Benchmark-Rohdaten

Die herunterladbaren Dateien enthalten keine persönlichen Zugangsdaten. SSH-Host, Benutzername, Zotero-Item-Key und Bibliotheks-ID sind als Platzhalter ausgewiesen; die eigene mcp.json wird zur Laufzeit eingelesen.

Werkzeuge und Links

• zotero-mcp-server: stevenyuyy.com/zotero-mcp
• pyzotero: pyzotero.readthedocs.io
• Zotero-Lokal-API-Dokumentation: zotero.org
• Zoteus: github.com/oscardvs/zoteus
• cli-anything-zotero: github.com/PiaoyangGuohai1/cli-anything-zotero
• Zotero-MCP-Server: Architekturanalyse einer instabilen Codebasis – DeepSeek V4 Flash untersucht die Ursachen der Instabilität
• 📄 Zotero-MCP-Knowledge für KI-Agenten – Komprimierte Erfahrungen, Workflow-Regeln, Tool-Vergleiche und Benchmark-Ergebnisse als Markdown-Datei zum Import in jedes KI-Memory-System

Dieser Workflow wurde für ein konkretes Projekt aufgebaut. Toolversionen, Serververhalten und API-Preise ändern sich schnell – vor produktivem Einsatz die eigene Einrichtung testen.