Loading ToolBench
Unofficial MCP server for Zotero integration with citation management. Enables library management, citation injection into Word documents, PDF handling, and Zotero API access through MCP tools.
The Zotero MCP server demonstrates solid definition quality with excellent descriptions and generally well-structured schemas. All 15 tools have clear, actionable descriptions (averaging ~250-400 chars, well within the 10-1024 baseline). Most tools properly declare input schemas with type information. However, there are notable gaps: (1) Output schemas are not explicitly documented in the schema definitions, LLMs cannot see what these tools return; (2) Some parameter descriptions lack actionable constraints (e.g., 'array of Zotero item keys' without max length enforcement visible in schema); (3) Error handling patterns are not evident in schema definitions (no documented error recovery guidance); (4) Tool composition is generally good, but some multi-parameter dependencies (e.g., auto_attach_pdf in add_items_by_doi) lack explicit mutual-exclusivity documentation. Naming is strong across all tools (verb-noun pattern, clear action intent). The tool set is well-designed for the domain (citation/reference management), with logical separation of concerns.
Add items to Zotero by providing metadata directly. Supports ALL 37 Zotero item types. WHEN TO USE: - For items that do not have a DOI (books, theses, reports, etc.) - When you need full control over metadata (e.g., override a title, set a specific itemType, add custom fields) — even if a DOI exists, use add_items when the auto-resolved metadata would be incorrect or incomplete - Mixed batch: if some items have DOIs and others don't, call add_items_by_doi for the DOIs and add_items for the rest (two separate calls) - Prefer add_items_by_doi when DOIs are available AND you don't need to override metadata (it auto-resolves everything and attaches OA PDFs) BATCH: Pass multiple items in the 'items' array (single API call). COMMON FIELDS (available for most types): title, date, abstractNote, url, DOI, publisher, place, pages, volume, language, extra ITEM TYPE QUICK REFERENCE: - journalArticle: publicationTitle, volume, issue, pages, DOI, ISSN - book: publisher, ISBN, edition, numPages, series, seriesNumber - bookSection: bookTitle, publisher, pages, ISBN, edition - conferencePaper: proceedingsTitle, conferenceName, publisher, DOI - thesis: thesisType ("PhD thesis"|"Master's thesis"), university - report: reportType, reportNumber, institution - webpage: websiteTitle, websiteType, accessDate - preprint: repository, archiveID, genre ("Preprint") - patent: patentNumber, assignee, issuingAuthority, filingDate - computerProgram: versionNumber, company, system, programmingLanguage CREATORS: Array of {firstName, lastName, creatorType} or {name, creatorType} for institutional. Default creatorType is "author". Some types use different primary types (e.g., "director" for film, "inventor" for patent, "artist" for artwork). Invalid fields or creatorTypes for a given type are rejected with helpful error messages listing the valid options.
Add items to your Zotero library by resolving DOIs. Works with ANY item type that has a DOI — journal articles, books, datasets, preprints, conference papers, reports, etc. For each DOI, resolves metadata via content negotiation and creates the item in Zotero with the correct type automatically. Returns a list of successfully added items (with item_key and title) and any failures. WHEN TO USE vs add_items: - Use add_items_by_doi when the item HAS a DOI — it auto-resolves all metadata and attaches OA PDFs. - Use add_items when the item does NOT have a DOI, or when you need to override specific metadata fields (add_items_by_doi does not allow metadata overrides). - Mixed batch: if some items have DOIs and others don't, make two separate calls — add_items_by_doi for the DOIs and add_items for the rest. WORKFLOW TIPS: - To collect metadata for all added items, call get_items_details with the returned item_keys (single batch call). - To create a cited Word document, use the returned item_keys as <zcite keys="ITEMKEY"/> placeholders in a .docx, then call inject_citations. See inject_citations description for the full workflow.
Output schemas not documented in tool definitions. LLMs cannot see what fields are returned, forcing them to guess at response structure for downstream tool calls and data extraction.
Error handling not visible in tool schemas. No documented error recovery guidance, error classification (retryable vs fatal), or actionable error messages. Agents have no guidance on what to do when tools fail.
Parameter constraints not enforced in schemas. Several tools accept arrays (e.g., item_keys in get_items_details, dois in add_items_by_doi) with documented max limits (50 items) but no 'maxItems' constraint visible in schema. LLMs will pass arbitrary array sizes.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Add a linked URL attachment to a Zotero item
Create a new collection in the Zotero library
Delete a collection from the Zotero library
Delete items from the Zotero library
Find and attach freely available PDFs to items in Zotero using Unpaywall
Get all items in a specific Zotero collection
Retrieve all collections in the Zotero library
Extract full text content from a Zotero item's PDF attachment
Get detailed metadata for specific items by their keys
Get the current Zotero user ID. Only needed by the standalone skill script (inject.js), not by the inject_citations tool.
Import a PDF file as an attachment to a Zotero item or create a new item with the PDF
Inject Zotero citations into a Word document. Reads a .docx file with <zcite> tags, fetches item metadata from Zotero, generates field codes, and produces a _cited.docx file ready to open in Word with the Zotero plugin.
Search the Zotero library for items matching a query
Destructive operations (delete_collection, delete_items) have optional permission gating (UNSAFE_OPERATIONS env var) but no confirmation/dry-run mechanism visible in tool schema. Agents cannot preview what will be deleted before committing.
add_items_by_doi and add_items have overlapping functionality but naming does not make the distinction obvious enough in descriptions. 'Use add_items_by_doi when... Use add_items when...' is present but not prioritized in tool descriptions themselves, LLMs may still conflate them.
get_user_id lacks clear use case documentation. Description states 'mainly for internal use' and 'can be useful for debugging', too vague for LLM selection. When should an agent call this vs. extract from context?