Agentic Zotero + AI: Why One Connector Is Never Enough

milogies

Hi everyone,

I've been using Zotero with AI coding agents for a while and realized that no single connector does everything well. The good news: because the Model Context Protocol (MCP) makes tools interchangeable, you can combine several Zotero connectors in one workflow and let the agent pick the right tool for each task.

On my site I wrote up the full setup, benchmarks, and decision logic. The short version:


  • zotero-mcp-server – best for annotations, notes, and reading large PDFs page-by-page via zotero_read_pdf_pages.

  • Zoteus – best for writes/updates, batch edits, and cloud-style API calls against the local Zotero instance.

  • cli-anything-zotero – useful for one-off CLI and scripting tasks.

  • pyzotero with local=True – fastest for bulk metadata and full-text reads; great for mass operations.

  • Memory-MCP server – makes the whole combination usable across sessions, because the agent can remember which tool worked for which job.

The key insight: the local Zotero HTTP API is fast and free, but it is not enough on its own. The real benefit comes from routing each request to the connector that handles it best.

Detailed walkthrough and benchmarks:
https://www.logies.de/zotero-mcp-server-beaver-comparison.html

Why cross-session memory matters for this (and how I built a local ONNX-based Memory-MCP server):
https://www.logies.de/memory-mcp-for-ai-agents.html

If you are already running an AI agent such as Kimi Code or Claude Code, you can essentially hand it these two pages and ask it to replicate the setup.

Happy to answer questions or discuss further.

Michael

Text drafted by Kimi Code (K2.7-code) on behalf of Michael Logies.

Suggested tags: Zotero 9, MCP, AI, automation, local API, LLM

  • milogies
    edited 10 days ago

    Small update to the setup described above: the comparison page now covers OpenAlex semantic search as well.

    Zoteus exposes this through its OpenAlex / zotero_scholar integration, so the agent can search the scholarly graph conceptually rather than just by keyword, spot related works that aren't in the local library yet, and import them on demand. That's the same capability Beaver offers inside the Zotero client, just routed through the MCP layer.

    For full-text retrieval after an OpenAlex hit we use a short cascade:


    1. If OpenAlex lists an open-access PDF link, the agent fetches it directly.

    2. Otherwise we fall back to cli-anything-zotero: add doi 10.xxxx/xxxxx --fetch-pdf imports the item and tries to download the PDF in one step. This works well whenever a freely accessible copy exists.

    3. If the article is paywalled, the Zotero Connector in the browser or institutional access is the remaining route.

    One practical detail we added for imports: every item brought in this way gets the tag imported by Kimi. It sounds minor, but it makes attachment management much easier — one click shows everything that arrived through the agent, so I can check which PDFs are missing, fetch them, and decide what to keep. Without that tag, imports tend to dissolve into the library.

    University VPN note: If the Windows machine that runs cli-anything-zotero is connected through a university VPN, many paywalled articles can also be fetched automatically — provided the institution holds the license. The VPN must be active on the Zotero host, not on the Linux client. Some publishers still require Shibboleth/SSO or cookies, so the browser connector remains the fallback in those cases.

    Page updated here: https://www.logies.de/zotero-mcp-server-beaver-comparison.html

    (Text drafted by Kimi Code (K2.7-code) on behalf of Michael Logies.)
Sign In or Register to comment.