MCP Zotero is a simple read-only reference server with 5 tools. All tools have names and descriptions present, but lack critical depth for production use. Naming is verb-forward (get_*, search_*) which is good. However, descriptions are generic and do not explain when/why to use each tool vs alternatives, or what the LLM should expect in the response. Input schemas are present but minimal, most tools accept only 1 parameter with no validation constraints. Output schemas are entirely undocumented; the code shows the tools return JSON but does not specify field names, types, or structure that the LLM should expect. Parameter descriptions are present but very terse (e.g., 'The collection key/ID' does not explain format, length, or how to obtain a key). Error handling is present in code (e.g., 'No collections found') but responses are not structured to guide the LLM on recovery actions. No tool output is documented, forcing the LLM to infer structure from first call. All tools are read-only (safe), but the lack of output documentation and parameter constraints prevents confident agent composition.

• Add explicit output schema documentation for each tool. Example for get_collections: 'Returns an array of collection objects, each with {name: string, key: string, version: number, description: string}'. This enables the LLM to chain results (e.g., pass collection key to get_collection_items) without trial-and-error.
• Add min/max constraints to numeric parameters. For get_recent limit, add 'limit' constraint to 1 - 100 in schema and description: 'Number of papers to return (1 - 100, default 10)'. This prevents runaway API calls.
• Expand parameter descriptions to include format and how to obtain values. Example: 'collectionKey: The unique identifier of the collection. Obtain from get_collections response. Format: alphanumeric string, 5 - 20 characters.'
• Clarify tool selection guidance in descriptions. Add to search_library: 'Use this to find items across all collections when you don't know which collection they're in. Use get_collection_items instead if you already know the collection key, faster and more precise.'
• Standardize error responses. Instead of free-text error content, return structured format: {type: 'error', code: 'NO_COLLECTIONS_FOUND', message: 'No collections exist in library.', suggestion: 'Create a collection first at https://www.zotero.org/support/collections', retryable: false}. This lets LLMs detect error type and decide next action.
• Document what fields each tool response contains. Create a brief schema reference in README or inline comments. Example: 'get_item_details returns {itemKey, title, creators, date, abstract, url, tags, notes}'.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry