Zoteus

Resolve the current Zotero identity (userID, username, display name) and per-library access scopes from the configured API key, report the running Zoteus `version`, and report which library backends are available (cloud Web API and/or the desktop local API). Call this first to discover the userID — never ask the user to type a numeric ID. It also reports which library every call defaults to and WHY (`defaultLibrary.source`: pinned by whoever runs the server, derived from the key, or the desktop app's own library), whether this caller has a context of their own or shares the one the server operator configured (`context`), and which single library this context's search index holds (`searchIndex`). For per-group write permission, call zotero_groups. If no API key is configured, the server runs in local-only read mode against the desktop library (users/0).

无需输入参数。

Search or list items in a Zotero library or collection. Quick search via `q` (`qmode`: titleCreatorYear=default, matches title/creator/year only; everything=also searches notes & attachment full text). For presence checks ("is X in my library?"): a default-mode `q` that matches nothing auto-retries once in `everything` mode, so terms appearing only inside PDF text don't false-negative — pin `qmode` explicitly to disable. An empty `everything` result is reported as strong-but-not-conclusive, since un-indexed/scanned/un-synced PDFs aren't full-text searchable. Also supports boolean `itemType` filters (use `||` for OR, repeat or `&&` for AND, leading `-` to negate, e.g. "journalArticle || book", "-attachment"), boolean `tag` filters (same syntax; escape a literal leading hyphen as "\-"), `since` (version) for incremental queries, `sort`/`direction`, and `limit`/`start` paging. Set `response_format` to "detailed" to also return technical fields (version, tags, collections, DOI, url) needed before chaining a write; the default "concise" returns high-signal projections (key, itemType, title, creators, date). Reads are served from the fast desktop local API when available, otherwise the cloud Web API. Returns `totalResults` so you can tell when to page rather than assuming you saw everything. For conceptual/"papers about X" queries by meaning rather than exact fields, use zotero_semantic_search instead.

Fetch one item by its key, returning the full item record (itemType, all bibliographic fields, creators, tags, collections, relations, version). Optionally set `include_children` to also return the item's child notes and attachments. Use `include` to additionally request rendered output: "bib" (formatted bibliography entry), "citation" (inline citation), or "csljson" (CSL-JSON for downstream formatting); combine with `style` (a style name such as "apa" or "chicago author-date", a CSL style id such as chicago-notes-bibliography, or the URL of a CSL file; unset renders Zotero's default, Chicago shortened notes and bibliography) and `locale`. When the desktop app serves the request, a style it has installed is used as-is and an unknown one is fetched from the Zotero style repository. The returned `version` is required if you later update or delete this item.

Return the Zotero data model so you never hardcode item shapes. With no arguments, returns the schema version and the list of all item type names. With `item_type`, returns the valid fields and creator types for that type (the "primary" creator type is listed first). Use this to validate an item before creating or updating it: notes, attachments, and annotations are item types too but bypass the normal field/creator model.

Create new items or update existing ones in a single batch (the server auto-chunks into groups of 50). `items` is an ARRAY of item-data objects; each object has `itemType` as a **plain string** (e.g. "journalArticle", "book", "preprint", "report") plus its valid fields, `creators` (each `{creatorType, firstName, lastName}` or `{creatorType, name}`), `tags` (`[{tag}]`), and `collections` (array of 8-char collection keys). To UPDATE an existing item, also include its `key` and current `version`; to CREATE, omit both. Every item is validated against the Zotero schema before anything is sent — if any item is invalid, nothing is written and the problems are returned. Use zotero_schema to discover valid fields/creator types for an itemType. Writes to your personal library go to the running Zotero desktop app (Zotero 10+) when it is up, otherwise to the cloud Web API (requires ZOTERO_API_KEY). When updating, take `version` from a read made the same way (zotero_get_item), since the desktop and the cloud number versions independently. To write to a GROUP library, pass its numeric `library_id` (from zotero_groups) together with `library_type:"group"`. `library_type` alone is not enough, and the key needs write access to that group. Collection keys are per-library, so take them from zotero_list_collections with the same `library_id`. Example: ```json {"items": [{"itemType": "journalArticle", "title": "The Role of Metadata in Machine Learning", "creators": [{"creatorType": "author", "firstName": "Ada", "lastName": "Lovelace"}], "date": "2024-01-15", "DOI": "10.1234/example.5678", "tags": [{"tag": "ml"}], "collections": ["ABCD1234"]}]} ```

Partially update one item (HTTP PATCH — only the fields you supply change; omitted fields are preserved). Provide `item_key` and a `patch` object of the fields to change (e.g. {"title":"New","extra":"note"} or {"tags":[{"tag":"reviewed"}]}). All field values are plain JSON strings/numbers/booleans/arrays — never wrapped in nested objects (e.g. `"title": "New"`, NOT `"title": {"title": "New"}`). Optimistic concurrency is handled for you: if you pass the item's `version` it is used; otherwise the current version is fetched first. If the item changed on the server in the meantime (412), the update is automatically re-fetched and retried once. Writes to your personal library go to the running Zotero desktop app (Zotero 10+) when it is up, otherwise to the cloud Web API; the version is read from the same place the write goes. Set `dry_run:true` to preview the field-level before→after diff without writing (arrays like tags/collections are replaced wholesale by PATCH, not merged; a dry_run call performs no write).

Move items to the trash (the safe, REVERSIBLE default) or restore them. This sets the `deleted` flag (1=trash, 0=restore); it is NOT a permanent delete, so trashed items can be recovered here or in the Zotero app. Use this instead of zotero_delete_items unless you truly need irreversible removal. Provide `item_keys` and optional `action` (default "trash"). Writes go to the running Zotero desktop app (its local-API writes, Zotero 10+) for your personal library and for any group library the app holds, otherwise to the cloud Web API. When the server sets a bulk-write threshold (ZOTEUS_CONFIRM_BULK_WRITES, off by default), trashing more items than that in one call also needs `confirm: true`.

PERMANENTLY and IRREVERSIBLY delete items by key (this purges them; it is NOT the trash). Prefer zotero_trash_items, which is reversible. This tool is disabled unless the server is started with ZOTEUS_ALLOW_DELETE=true, and additionally requires `confirm: true` on every call. For the personal library, and for a group library the running Zotero desktop app holds, it goes through that app when it supports local-API writes (Zotero 10+), otherwise the cloud Web API. The current library version is used as a precondition; the operation auto-chunks to 50 keys per request.

List, create, rename, reparent, or delete collections, and move items into or out of a collection. Set `action` to one of: "list" (collections with key/name/parent, sorted by name; `q` filters by name over the whole library, `start`/`limit` page, `totalResults` counts them all), "create" (needs `name`, optional `parent_collection` key; omit it for top-level), "rename" (needs `collection_key` + `name`), "reparent" (needs `collection_key`; `parent_collection` key, or omit to move to top level), "delete" (needs `collection_key`), "add_items" / "remove_items" (need `collection_key` + `item_keys`; collection membership lives on each item). Writes to your personal library go to the running Zotero desktop app (Zotero 10+) and otherwise to the cloud Web API; group libraries always write to the cloud. When the server sets a bulk-write threshold (ZOTEUS_CONFIRM_BULK_WRITES, off by default), removing more items than that from a collection in one call also needs `confirm: true`.

List tags, or add/remove tags on items. Set `action` to "list" (returns library tags; supports `q` substring filter), "add" (add `tags` to each of `item_keys`), or "remove" (remove `tags` from each of `item_keys`). Tags are stored on the parent item's tag array, so add/remove edits the items: in your personal library through the running Zotero desktop app (Zotero 10+) when it is up, otherwise through the cloud Web API; group libraries always write to the cloud. Tag names are case-sensitive. When the server sets a bulk-write threshold (ZOTEUS_CONFIRM_BULK_WRITES, off by default), editing more items than that in one call also needs `confirm: true`.

List, create, or delete saved-search DEFINITIONS. NOTE: the Zotero cloud Web API stores saved searches but does NOT execute them — to get the items a saved search matches, run an equivalent zotero_search_items query (or use the desktop local API when available). Set `action` to "list" (all saved searches with their conditions), "create" (needs `name` and `conditions`, each `{condition, operator, value}`), or "delete" (needs `search_key`). Writes to your personal library go to the running Zotero desktop app (Zotero 10+) and otherwise to the cloud Web API; group libraries always write to the cloud.

List the group libraries this server can reach, with each group's id and name. Use a returned group id with the `library_id`/`library_type:"group"` parameters of other tools to operate on that group library; `library_type` alone does not address a group. With a cloud API key each group the key can access is listed with its type, item count, description and edit permissions, plus `canWrite`: whether this key may write to that group, decided from the key's own access map without sending a write, and `writeBlockedReason` naming the remedy when it may not. Without a key the list falls back to the group libraries a running Zotero 10+ desktop app holds, which are exactly the groups still readable, key-free, from that app: those rows carry id, name, description and the desktop's own item count, and no type, edit permissions or `canWrite`, because the desktop does not store them. On every row `numItems` counts ALL the items the library holds, child attachments, notes and annotations and the trash included, so it is larger than a zotero_search_items count and is not a number of papers; `numItemsNote` says how to count top-level items instead. Where both are available every row says which it came from, in `source`: "cloud", "local", or "both" for a group the key can see and the desktop also holds. Rows also carry `indexed`: whether this data directory holds a search index for that group, which is what makes it searchable by meaning. Each library gets its own index file, so several rows can be true, and a false row becomes true after zotero_index action:"build" library_type:"group" library_id:<id>. Writing to a group always goes through the cloud, even when the Zotero desktop app holds that group, and needs a key with write access to it; `libraryEditing` says whether the group itself lets ordinary members edit its library.

无需输入参数。

Export items in a bibliographic format and return the raw text. Choose `format` (bibtex, biblatex, better-biblatex, ris, csljson, csv, mods, tei, coins, rdf_*, refer, wikipedia, bookmarks). Stock formats are rendered by Zotero itself: by the desktop app when it serves the selected library (no cloud key needed), by the Web API otherwise. `biblatex` is Zotero's STOCK translator; BBT-specific options (citation-key generation, sentence-case, biblatexExtendedNameFormat, unicode→LaTeX) are NOT available there. `better-biblatex` uses the local desktop Better BibTeX plugin (your configured BBT export options apply) and is only available when desktop Zotero + BBT are running; it degrades to built-in `biblatex` otherwise. Narrow with `item_keys`, `collection_key`, `q`, or `item_type`. A `limit` (default 50) is always applied. An export that renders no entries says so instead of returning a blank body: named `item_keys` that render none are an error, and any other selection that renders none comes back with `empty: true`. For styled human bibliographies use the bibliography tools.

Not a search: to find which items contain a term, use `zotero_search_items` with qmode=everything. This reads, sets, or tracks one attachment's already-extracted full text by key. `action`: "get" returns the indexed text content plus indexing stats for an attachment item (only attachment items have full text; returns found:false if none); "set" stores extracted text for an attachment (provide `content` and the indexing counts); "since" returns the map of attachment keys whose full text changed after a given library `version` (useful for incremental indexing). Only attachment items support full text. All three go through the running Zotero desktop app when there is one (no cloud key needed; "set" needs Zotero 10+ and writes your personal library or a group library the app holds), otherwise the cloud Web API.

Retrieve an item's PDF or EPUB text for grounding. Pass a parent `item_key` (its best PDF/EPUB attachment is resolved automatically) or an attachment key. With `query`, returns the top relevant passages with locators (char offsets, nearest section, and a page); with `page_range` (e.g. "3-7"), returns just those pages, re-extracted from the PDF so the span is exact; with `outline:true`, returns the PDF's table of contents with page numbers (the cheapest way to decide which pages to read next); with none of them, returns a truncated head. Text comes from Zotero's full-text index when available; when the attachment is NOT indexed yet, the file itself is read and parsed on the fly (`fallback`, on by default; set `fallback:false` to disable), so a PDF added minutes ago still returns text (marked fulltextSource:"pdf" or "epub", with fileSource saying where the bytes came from). The file is read from the running Zotero desktop app, else straight out of the local Zotero storage folder, else downloaded from Zotero cloud storage. Page numbers are exact whenever the PDF was parsed, and otherwise an estimate (pageApprox) unless `precise_pages:true`. Read-only; the indexed text is served by the running Zotero desktop app when there is one, otherwise by the cloud Web API. Use this to cite a claim with a page after finding an item via zotero_search_items / zotero_semantic_search. A PDF with no text layer is reported as what it is, with its page count and what would read it, instead of failing vaguely, and one whose text layer covers only some pages says which pages lack one; `ocr:true` reads the pages that have no text layer by rendering them and recognising the text (a few a call), but only where the operator enabled OCR and installed the engine, and that text is a machine reading of a picture, never saved and never indexed. Text is all this returns: for a figure, a table, an equation or a scanned page with no text layer, zotero_pdf_images renders the page (or extracts the embedd

See a PDF the way a reader does. Text extraction (zotero_get_fulltext) loses figures, turns tables into run-together numbers, drops most equations, and returns nothing for a scanned page with no text layer; this tool returns pictures instead. Pass a parent `item_key` (its PDF attachment is resolved automatically, exactly as zotero_get_fulltext does) or an attachment key, a `mode`, and `pages` ("3" or "3-7", 1-based; default "1"). `mode:"pages"` renders whole pages and returns them as image content blocks you can look at, followed by a JSON block with each page's pixel size and byte count: the default resolution keeps body text legible (about 1568 px on the long edge, which is also as much as the model is shown), `dpi` (36 to 300) overrides it for small print, and `format` is "jpeg" (default, quality 80) or "png" (sharper line art, larger). `mode:"figures"` extracts the raster images embedded in those pages, the way pdfimages does: photographs, plots and diagrams stored as images, and on a scanned PDF the page image itself (reported with coversPage:true); each comes back with its page, pixel size, position on the page in points from the top left, and the image inline (`inline`, default true; very large ones as a 2000 px preview). A figure drawn as vectors (most matplotlib, TikZ and PDF-exported plots) is lines in the content stream, not an image, so it does not appear in figures mode; render the page with mode:"pages" to see it. Caps: `max_pages` per call (default 4, at most 8; a longer span is cut and the notice says how to continue), `max_images` (default 16, at most 40), images under `min_size` px on a side skipped (default 32: icons, rules, bullets), an image repeated across pages returned once, files above 20 MB not parsed, and about 5 MB of inline image data per response, beyond which pages or figures are left out with a notice naming them and the remedy (fewer pages, lower `dpi`, format:"jpeg", or the next span). A PDF whose encryption only restricts printing

Return what changed in a library since a given version, for efficient incremental sync. Provide `since` (a library version; 0 = everything). Returns, per object type (items/collections/searches/tags), the map of keys→version that changed after `since`, plus the deletion log (keys removed since `since`). This is the version-based delta the Zotero sync algorithm uses: fetch the changed keys, then pull only those with zotero_get_item/zotero_search_items. Follows the library route: a running Zotero desktop app serves the delta for any library it holds, with no cloud API key, and otherwise the cloud Web API does; `backend` says which one answered. The whole delta comes from that one API, because the two number library versions independently. The desktop app serves item and collection versions but no tag versions and no deletion log; those are reported in `unavailable`, naming what is missing and why, and never as an empty result.

Upload, download, or inspect attachment files. `action`: "upload" stores a file as a Zotero attachment using the full File Storage protocol (provide `url` to have Zoteus fetch it, or `file_path` for a file on the machine running Zoteus; optional `parent_item` to attach it under an item, `title`, `content_type`) and returns the new attachment key; "download" fetches an attachment's file to a local path (provide `item_key`; optional `save_path`, default under the Zoteus data dir) and returns the path and byte count; "info" returns an attachment item's metadata. File bytes are written to / read from disk, never streamed through the conversation. Upload and download go through the running Zotero desktop app (Zotero 10+, no cloud key and no storage quota) for your personal library and any group library the app holds, and through the cloud Web API and your file-storage quota otherwise; `target` (upload) and `readFrom` (download) say which. When Zoteus runs on a different machine than Zotero, `file_path` refers to the server's disk, so use `url` instead.

Add or delete Zotero PDF annotations (highlights, underlines, notes), the same objects you create in the Zotero PDF reader. `action:"add"` needs `parent` (a regular item key OR a PDF attachment key) and `annotations`: each with `type` (highlight|note|underline, default highlight), `text` (the exact passage to highlight), optional `comment`, `color`, `page` (0-based page index). **You do not need page coordinates**: give the passage in `text` and it is located in the PDF and anchored to the exact lines it occupies, so quoting a passage is enough to highlight it. Pass `page` to disambiguate a passage that repeats, or `occurrence` to pick among repeats; pass `position` ({"pageIndex":N,"rects":[[x1,y1,x2,y2],...]} in PDF points, bottom-left origin) only to place a highlight yourself. `action:"delete"` trashes the annotations in `annotation_keys`. Writes go to the running Zotero desktop app for your personal library (via its local-API writes where available, or its connector protocol) and for any group library the app holds (local-API writes, Zotero 10+), otherwise to the cloud Web API.

Add a stored file attachment (e.g. a PDF full text) under an existing item. Give `parent` (the item key) and one of `url` (Zoteus downloads it, then stores it), `path` (a file on the machine running Zoteus), or `find_oa: true` (Zoteus looks the parent item's DOI up in OpenAlex and attaches the open-access PDF, if there is one). `find_oa` finds only copies OpenAlex already knows about, which is arXiv, PubMed Central, DOAJ journals and institutional repositories: it is not a way past a paywall, and it says so plainly when there is no free copy. The copy it finds is often the author's accepted or submitted manuscript rather than the published version, so the source, the version and the licence come back in the result and go into the attachment's title. `filename` and `content_type` are inferred when omitted. Saves through the Zotero desktop app when one is reachable (Zotero 10+ local API; you may be asked once to allow Zoteus write access, choose "Always Allow"), and otherwise through the cloud Web API, which needs ZOTERO_API_KEY with file access and uses your Zotero file-storage quota. `url` works on every setup including a remote/hosted Zoteus that cannot see your desktop, so prefer it over `path` unless the file really is on the server. Returns the new attachment key.

Resolve bibliographic metadata to Zotero item-data and optionally save it to your library. `action: "by_identifier"` resolves a DOI, ISBN, PMID, arXiv id, or ADS bibcode (set `identifier`). `action: "by_url"` scrapes a web page (set `url`) and may return multiple choices to pick from. `action: "by_file"` imports a BibTeX, RIS or CSL-JSON bibliography: set `text` with the contents or `path` with a local file. Those three formats are parsed by Zoteus itself, so they need no translation-server, no Docker and no network; a reachable translation-server is used first when there is one, because it covers more formats (EndNote XML, MODS, RDF). `action: "by_pdf"` recovers metadata for a PDF: set `path` for a file on the machine running Zoteus, or `attachment_key` for a PDF already in the library (the only variant a hosted server can reach). It extracts the text of the first pages, looks for a DOI or an arXiv id, and resolves that; the result says which page the identifier was on, what introduced it, and whether the match was a labelled one or a bare string, because a first page often carries DOIs belonging to other works. It does not read scanned pages (no text layer means no identifier) and it never invents metadata: when nothing is found it says so. Set `save_to_library:true` (and optionally `collection_key`) to persist the resolved items, saved into the running Zotero desktop app when available and otherwise via the cloud Web API (requires ZOTERO_API_KEY); without it the metadata is returned and nothing is written, which makes a file import a free preview of what would be created. When a Zotero translation-server is reachable (ZOTEUS_TRANSLATION_SERVER_URL, default http://127.0.0.1:1969) it is the primary path for identifiers and URLs; with none running, DOI and arXiv ids fall back to built-in resolution (OpenAlex/Crossref and the arXiv API), and the result then carries a `source` field ("scholar" or "arxiv"). ISBN/PMID/bibcode and web URLs require a translation-server (a

Resolve a human citation-style name to a valid CSL style id and confirm it is available, or list common style aliases. `action: "resolve"` maps names like "APA 7th", "IEEE", "Vancouver", "Chicago", "MLA", "Nature" to the correct CSL id (e.g. apa, ieee, modern-language-association) and verifies the style can be fetched; pass the returned `styleId` as the `style` argument to zotero_format_bibliography or zotero_bibliography. `action: "list"` returns the built-in common aliases (any id from the CSL styles repository also works). Dependent styles are resolved to their independent parent automatically when formatting. Long names resolve too, including the titles Zotero lists styles under ("Chicago Manual of Style 17th edition (author-date)", "American Psychological Association 7th edition"), and a past edition the CSL repository still carries (Chicago 16th and 17th, APA 6th, AMA 10th) resolves to that edition's own style rather than to the current one. A name it cannot read is tried as a CSL id as given.

Render a formatted bibliography in any CSL style using citeproc-js — no Zotero library write required. Provide either `items` (an array of CSL-JSON objects, e.g. from zotero_import or external metadata) or `item_keys` (library items, which are exported to CSL-JSON first). Choose `style` (a name like "APA 7th" or a CSL id; default "apa"), `locale` (default "en-US"), and `format` (html/text/rtf; default html). The formatted bibliography text is returned. Use this for arbitrary items or styles; for items already in the library you can also use zotero_bibliography (server-rendered).

Produce a formatted bibliography for items already in a Zotero library, rendered server-side by Zotero in a CSL style (by the desktop app for a library it serves, so no cloud key is needed there; otherwise by the Web API). Provide `item_keys` and optionally `style` (a name such as "apa" or "chicago author-date", or a CSL id; unset renders Zotero's default, chicago-shortened-notes-bibliography), `locale`, and `linkwrap`. Returns XHTML. Note: this endpoint is item-only and capped at 150 items. For arbitrary CSL-JSON or items not in the library, use zotero_format_bibliography instead.

Manage the local hybrid-search index used by zotero_semantic_search. Every job runs in the background on the server, so this tool returns immediately and never blocks on large libraries. THREE write actions, and picking the right one matters: `action: "update"` is the cheap one and should be the default for a library that is already indexed; `action: "build"` and `action: "refresh"` both rebuild the WHOLE index, which on a large library means many minutes and, with an API embedding provider, real spend (they differ in one thing: build resumes an interrupted build, refresh always starts over). `action: "build"`/"refresh" pages the library's top-level items (100-at-a-time, stopping at the server's item cap, ZOTEUS_INDEX_MAX_ITEMS, default 5000, or at a smaller `limit` if one is given), indexes their text (title, abstract, creators, tags) for BM25 keyword search and, if an embedding provider is configured, for vector search, persisting partial progress atomically as it goes; use it for the first build, after changing the embedding model, or to widen a previously capped build. It is ALSO the repair: if the index cannot be read at all, only `action:"build"` clears it, by deleting the unreadable file and opening a fresh one before rebuilding (nothing repairs it at startup or inside a query). `action: "update"` instead fetches only the items changed since the version the index recorded (Zotero's `?since=`), re-chunks and re-embeds just those, and removes items the library no longer holds (diffed from a cheap keys-only `?format=versions` census, since the deletion log is cloud-only); untouched items are never re-embedded, so adding a handful of items costs seconds instead of a full rebuild. Update falls back to a full rebuild by itself, and says so in `updateNotice`, when a delta would be wrong: no version stamp recorded yet, the library is now served by a different Zotero API (the desktop app and the cloud number their versions independently), or the embedding model change

Search the library by meaning, not just keywords. Combines BM25 keyword scoring with vector similarity (when an embedding provider is configured) via reciprocal-rank fusion, and returns the best-matching items with a snippet and score. By default it searches item metadata and abstracts; if the index was built with `fulltext` on (zotero_index fulltext:true, or ZOTEUS_INDEX_FULLTEXT=true) it also searches the body text of attachments, and a hit whose snippet came from a PDF body is marked source:"fulltext". It ALSO searches the words the reader wrote, child notes and PDF annotations (highlight text and comments), unless that was turned off (ZOTEUS_INDEX_OWN_WORDS=false); a hit from one is marked source:"note" or source:"annotation" and is attributed to the item it hangs off, so an item with forty annotations is one result rather than forty. `mode`: "auto" (hybrid, default), "keyword" (BM25 only), or "semantic" (vector only). "semantic" needs both vectors in the index and a running embedder to turn the query into one: when either is missing (embeddings switched off, or e.g. the on-device model runtime is not installed) it returns an error naming the cause instead of an empty result set, and "auto" keeps working as keyword search while saying so. The index must be built once before first use, with zotero_index action:"build": this tool only reads, so on an empty index it starts nothing and returns an error naming that call (or, while a build is running, its progress). ONE INDEX FILE HOLDS ONE LIBRARY, and a plain call answers from the default library's index: which library that is comes back as `library` on the result and is named in the summary (both absent only on an index built before that stamp existed, where the library is genuinely unknown). `library_type`/`library_id` name ONE library: when that library has an index of its own in this data directory, the search answers from THAT index; when it does not, you get an error naming which library the index that IS here

Explore the EXTERNAL scholarly graph around a paper (OpenAlex, Crossref fallback). This does NOT search, list, or read your Zotero library: it queries the open web, and results are works from the scholarly web, not your items. To search or inspect YOUR library use zotero_search_items, zotero_semantic_search, zotero_get_item, or zotero_list_tags instead. Provide a `doi` and an `action`: "lookup" (metadata + citation count, plus an `oa` block naming the open-access PDF OpenAlex knows of, when there is one), "references" (works this paper cites), "citations" (works that cite this paper, most-cited first), "related" (similar works), or "notices" (update notices deposited against the paper: retractions, corrections, expressions of concern, errata, withdrawals). "notices" asks Crossref, which redistributes the Retraction Watch database, and OpenAlex side by side and reports what each one says with its source and date; it never emits a verdict, there is no `retracted` field, a source that did not answer is reported as not reached rather than as "nothing found", and when the two sources disagree it says so. Set `include_in_library: true` to additionally flag which results your library already holds and hand back the item key for each (off by default because it scans the library); with action "citations" that key is the way into zotero_get_fulltext, whose `query` returns the passages where a citing paper you already hold discusses this one. Set `library_scan: true` with action "notices" to check the DOIs your library already holds against the same two sources and list only those with a record; it reports how much of the library it saw. `limit` caps results (default 20); every list answer also carries `total`, the size of the list the results were cut from, and `truncated: true` when the limit dropped some, so a review with 150 references never looks like one with 20. Read-only; calls external scholarly APIs. This is a thin citation-graph helper around a single DOI: for full

Discover the available Zotero tools by keyword — useful for progressive disclosure when you do not want to load every tool definition up front (the code-execution-with-MCP pattern). Pass an optional `query` (matched against tool names, titles, and descriptions) and `detail` ("names" or "descriptions", default "descriptions"). Returns the matching `zotero_*` tools so you can pick the right one for a task. With no query, returns the full catalog.

List tags in a Zotero library with their usage count and whether each was auto-applied by Zotero. Optional `q` substring filter and `limit`. Read-only: available even when the connector runs in read-only mode (unlike zotero_manage_tags, which also writes). For taxonomy hygiene use zotero_tag_audit. Served by the running Zotero desktop app for any library it holds, so it needs no cloud API key.

List collections in a Zotero library (key, name, parent collection key, item count), sorted by name. Read-only: available even in read-only mode (unlike zotero_manage_collections, which also writes). Every collection in the library is read, then `q` filters by name and `start`/`limit` page the result; `totalResults` says how many there are, so a large library is never mistaken for its first page. Use the keys to scope zotero_search_items (collectionKey) or zotero_tag_audit (scope.collection_keys).

Audit a library against a controlled tag vocabulary with priority tiers. Provide the vocabulary inline as `vocabulary` (or a JSON file via `vocabulary_path`): { tags:[{name,tier?}], tiers?:[{name,required?}] }. Reports (1) off-taxonomy tags (library tags not in the vocabulary; Zotero auto-applied tags are bucketed separately unless include_auto), (2) items missing a tag from each required tier, and (3) optional per-collection coverage when `scope.collection_keys` is given. A key that none of these objects knows is refused and named, never dropped: a dropped `scope`, `tier` or `required` would change the question without changing the answer. Read-only. Tag and item enumeration both follow the library route, so a running Zotero desktop app serves the whole audit with no cloud API key.

Merge one or more duplicate items into a master item: fields the master is MISSING are filled from the duplicates, their tags, collections and relations are unioned onto it, their child notes and attachments are reparented to it, and the emptied duplicates are moved to the trash (recoverable). A field the master already has is never overwritten, and nothing is ever deleted outright. PREVIEWS BY DEFAULT: with `dry_run` unset or true nothing is written and the answer is the exact plan, field by field, so the caller can see what would change before it changes. Pass `dry_run:false` to execute. The merge runs on the running Zotero desktop app (Zotero 10+, no cloud key needed) for your personal library and any group library the app holds, and on the cloud Web API (ZOTERO_API_KEY with write access) otherwise; the preview reads the same copy the write will act on, so the two cannot describe different merges, and says which (`readFrom`). The preview also reports `versions` (the master's, each duplicate's and each child's): pass that block back as `expect_versions` with dry_run:false and the write runs only if every record is still at that version, otherwise NOTHING is written and the answer is the plan as it now stands, as a dry run, with `changed` naming what moved. Without `expect_versions` the write plans from the records as they are at call time. If the master changes between the read and the PATCH inside one call, the plan is rebuilt against the record as it then is rather than replayed, and the answer says so (`replanned`), because replaying it would overwrite exactly what changed. Find candidates with zotero_import `check_duplicates:true`, or by comparing records yourself with zotero_search_items and zotero_get_item. The master keeps its own key, so citations already pointing at it stay valid; the duplicates keep theirs in the trash until it is emptied, and the master records a dc:replaces relation naming each item it absorbed, which is the same relation Zotero's own

Render rows of retrieved evidence as a Markdown or CSV table, deterministically, from passages you already retrieved with zotero_get_fulltext and zotero_semantic_search. This tool does NOT search and does NOT read the library: it formats what you pass it and echoes each row's quotation, locator and coverage back unchanged. It counts the coverage summary from the rows rather than taking your word for it, and it warns, naming the row, when a row contradicts its own evidence (a page locator with no quotation, coverage claiming a retrieved passage with no quotation, a quotation on a source marked unavailable, or any support verdict other than "unverified" on a row whose coverage is not a retrieved passage); it warns and still renders, and never rewords a cell. One byte is added and only in CSV: a cell whose text begins with =, +, -, @ or a tab is a formula to Excel, LibreOffice and Sheets, so the CSV writes it with a leading apostrophe, the spreadsheet's own marker for literal text, which the spreadsheet consumes so the passage still displays exactly as it was retrieved; every such cell is named in `warnings`, and a plain number like a page locator of -5 is left alone. Markdown output carries no such marker. Use the `zotero-evidence-table` prompt to gather the rows first. Each row records one study against one question: the finding, the verbatim quotation that supports it, the page locator, whether that locator is exact or approximate, how well the source was covered (a passage was retrieved, only the abstract was available, or nothing was), and the support status. Returns the rendered table as text; pass `save_path` to also write it to a file.

Write a .docx whose citations are LIVE Zotero fields, not plain text: Zotero's Word plugin is meant to refresh, restyle and add to them (never run here, so check your first document). Give `body` as paragraphs containing `[[cite:ITEMKEY]]` or `[[cite:ITEMKEY,p. 12]]` placeholders; `[[cite:KEY1;KEY2]]` puts several works in one field, which is how "(Wu, 2026; Devos, 2026)" is written. Each placeholder becomes a Word field carrying the item's CSL data, with the formatted citation as its visible text. A bibliography field is appended by default. For plain formatted references with no live fields use zotero_bibliography or zotero_format_bibliography instead. The file is written to disk and the path is returned; on a shared deployment it is confined to the server data directory. Refreshing needs Microsoft Word with the Zotero word-processor plugin, and Zotero running: nothing else re-renders the fields. What is verified is the package and the field codes, by unpacking the .docx and checking its XML; a refresh in Word has never been run, and LibreOffice's Zotero extension uses ReferenceMarks rather than Word fields, so whether it adopts this document is untested as well. This writes paragraphs and citation fields and nothing else: no headings beyond `title`, no tables, no images, and no footnotes, so a note style renders its notes inline in the body.