Loading ToolBench
Zotero CLI and Python package for AI-assisted local library workflows.
The server provides 35 tools with consistent naming (verb_noun pattern), comprehensive parameter schemas with type information, and descriptions for most parameters. However, there are significant gaps in description quality, missing output schema documentation, no error handling guidance, and limited security/validation details. Many parameter descriptions are minimal (under 50 chars) and fail to explain constraints or provide context for LLM decision-making. Tool descriptions are present but inconsistent in depth. No tool has documented return types or pagination patterns despite several that obviously need them (list_*, find_*). Security considerations around session context, library_id defaults, and audit logging are not clearly explained in parameter descriptions.
Add a bibliography item to Zotero by arXiv identifier with optional PDF fetching
Add a bibliography item to Zotero by DOI identifier with optional PDF fetching
Ingest from a URL: arXiv / DOI / generic webpage to Zotero
Analyze a Zotero item by asking a question using OpenAI LLM with item context
Build comprehensive context for an item including attachments, notes, exports, and formatted prompt context
Build a runtime context with environment discovery and backend availability checks
List all items in a collection
List and discovery tools lack pagination parameters and output schema documentation. list_libraries, list_collections, list_items, list_searches, list_tags provide no limit/offset/page parameters and no documented return structure. Without pagination, large result sets blow the context window.
No documented return/output schemas for any tool. LLMs cannot plan downstream tool calls or extract fields if they don't know what the response contains. For example, find_items presumably returns item objects with keys and titles, but this is not explicit in the schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Get hierarchical tree structure of all collections
Convert a CSL-JSON item to Zotero connector item format
Ensure CLI Bridge endpoint is available, launching Zotero if needed
Enable the Zotero Local API in the profile if not already enabled
Ensure Zotero Local API is available, launching Zotero if needed
Search for collections by query string
Search for items by query in current or specified library
Get a single collection by reference (key or ID)
Get a single item by reference (key or ID)
Get a saved search by reference
Get all attachments for an item with resolved file paths
Get child items (notes, attachments) of an item
Get file metadata for an item or its first attachment
Get all notes attached to an item
Launch the Zotero desktop application and wait for connector/local API readiness
List collections in the current or specified library
List items in the current or specified library
List all Zotero libraries available in the local database
List all saved searches in the current library
List all tags in the current library
Append one audit event to the append-only audit log for privileged/write operations
Log a result_payload-like dict if it looks like a write action
Normalize various JSON formats (Crossref, CSL-JSON, connector items) into connector item format
Check if installed CLI Bridge plugin is behind bundled version and return warning if needed
Resolve a library reference to its numeric ID
Run comprehensive health checks on Zotero app, connector, local API, plugin, and CLI bridge
Execute a saved search and return matching items via Zotero Local API
Retrieve the tail of the audit log (recent entries)
Parameter descriptions are minimal and generic. Examples: 'Optional session context' (7 words), 'Digital Object Identifier' (3 words), 'Optional collection key to add item to' (7 words). Descriptions under 20 chars provide insufficient guidance for LLM parameter selection. Descriptions should explain WHEN to use the parameter, what values are valid, constraints, and dependencies.
Error handling and recovery guidance absent. Tools like add_doi, add_arxiv, add_url perform network operations and external API calls (DOI lookup, arXiv fetch, PDF download) but provide no guidance on what happens on timeout, 404, or connection error. No error classification (retryable vs user-fixable vs fatal) is documented.
Security and permission scope not documented. Tools like log_event, log_payload, add_doi, launch_zotero perform audit logging and system control but do not declare what permissions they require (read:library, write:library, admin:zotero). No guidance on least-privilege configurations.
Parameter interdependencies undocumented. Examples: library_id and collection_key may interact; if_exists behavior is 'file' by default but what does that mean for add_doi vs add_arxiv? session parameter appears in many tools but its purpose and content are never explained. search_scope in find_items has 3 options but no guidance on which to use when.
No enum constraints on choice parameters. 'if_exists' accepts 'file' (default) but no documentation of other valid values. 'search_scope' in find_items is documented as accepting 'titleCreatorYear', 'fields', 'everything' but these are not declared as an enum in the schema, forcing LLMs to guess valid values.
Unrelated tools combined into one tool definition. ensure_bridge_endpoint_ready requires a bridge object parameter, which is not a natural user input, it's internal infrastructure. Similarly, build_runtime_context, launch_zotero, ensure_local_api_ready, ensure_bridge_endpoint_ready, ensure_live_api_enabled form a discovery/setup pipeline that should either be one composite tool or better documented as a dependency chain.