Which integrations are available for this server?

Provides programmatic access to Zotero reference libraries, enabling search, citation generation, PDF text extraction, item and collection management, and tag management.

How do I use Zotero MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zotero MCP Server search my Zotero library for publications on machine learning from 2023" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Zotero MCP Server

by danielostrow

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Zotero MCP Server

A Model Context Protocol server that provides programmatic access to Zotero reference libraries. This server enables AI assistants to search, cite, and manage research references directly from your Zotero library.

Features

Tools

search_items - Search and filter items in your library
get_item - Retrieve a single item by key or DOI
generate_citation - Generate formatted citations in multiple styles
extract_pdf_text - Extract full-text content from PDF attachments
create_item - Add new items to your library
update_item - Modify existing item metadata
delete_items - Remove items from your library
manage_collections - Create and organize collections
manage_tags - Add and remove tags from items

Resources

zotero://collections - Access collection hierarchy and metadata
zotero://tags - Browse all tags in your library
zotero://citation-styles - List available citation styles

Related MCP server: zotero-mcp-lite

Prerequisites

Node.js 20.16.0 or higher
A Zotero account with API access
Zotero API key from https://www.zotero.org/settings/keys

Installation

Option 1: NPM (Coming Soon)

npm install -g zotero-mcp-server

Option 2: From Source

git clone <repository-url>
cd zotero-mcp-server
npm install
npm run build

Configuration

Getting Your Credentials

Visit https://www.zotero.org/settings/keys
Create a new API key with appropriate permissions
Note your User ID (displayed at the top of the page)
Copy the generated API key

Environment Variables

Create a .env file in the project root:

ZOTERO_API_KEY=your_api_key_here
ZOTERO_USER_ID=your_user_id_here

For group libraries, use ZOTERO_GROUP_ID instead of ZOTERO_USER_ID.

Optional Configuration

ZOTERO_BASE_URL=https://api.zotero.org
ZOTERO_TIMEOUT=30000
ZOTERO_MAX_RETRIES=3
CACHE_ENABLED=true
CACHE_TTL_SECONDS=300

Usage with Claude Desktop

Add this configuration to your Claude Desktop config file:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "zotero": {
      "command": "node",
      "args": ["/absolute/path/to/ZoteroMCP/dist/index.js"],
      "env": {
        "ZOTERO_API_KEY": "your_api_key_here",
        "ZOTERO_USER_ID": "your_user_id_here"
      }
    }
  }
}

Restart Claude Desktop after making this change.

Tool Usage Examples

Searching Items

Search your library with various filters:

// Search by text query
{
  "query": "machine learning",
  "limit": 10
}

// Filter by item type and tags
{
  "itemType": "journalArticle",
  "tag": ["ai", "research"],
  "sort": "dateAdded",
  "direction": "desc"
}

// Search within a collection
{
  "collection": "COLLECTION_KEY",
  "limit": 25
}

Generating Citations

Create formatted citations in various styles:

{
  "itemKeys": ["ITEM_KEY_1", "ITEM_KEY_2"],
  "style": "apa"
}

// Supported styles include:
// apa, chicago-note-bibliography, mla, ieee, nature,
// science, harvard-cite-them-right, vancouver, and 10,000+ more

Extracting PDF Text

Extract text content from PDF attachments:

{
  "itemKey": "PDF_ATTACHMENT_KEY",
  "pages": {
    "start": 1,
    "end": 5
  }
}

Note: PDFs must be indexed by Zotero Desktop for full-text extraction to work.

Creating Items

Add new items to your library:

{
  "itemType": "journalArticle",
  "title": "Understanding Neural Networks",
  "creators": [
    {
      "creatorType": "author",
      "firstName": "Jane",
      "lastName": "Smith"
    }
  ],
  "date": "2024",
  "DOI": "10.1234/example",
  "tags": ["neural-networks", "deep-learning"],
  "collections": ["COLLECTION_KEY"]
}

Managing Collections

Create and organize collections:

// List all collections
{
  "action": "list"
}

// Create a new collection
{
  "action": "create",
  "name": "Machine Learning Papers"
}

// Create a nested collection
{
  "action": "create",
  "name": "Deep Learning",
  "parentCollection": "PARENT_COLLECTION_KEY"
}

Managing Tags

Add or remove tags from items:

// Add tags to an item
{
  "action": "add_to_item",
  "itemKey": "ITEM_KEY",
  "tags": ["ai", "research"]
}

// Remove tags from an item
{
  "action": "remove_from_item",
  "itemKey": "ITEM_KEY",
  "tag": "outdated"
}

// List all tags
{
  "action": "list"
}

Resource Usage Examples

Collections Resource

zotero://collections

Returns all collections with hierarchy information, item counts, and metadata.

zotero://collections/COLLECTION_KEY

Returns details for a specific collection.

Tags Resource

zotero://tags

Returns all tags in your library with usage counts.

Citation Styles Resource

zotero://citation-styles

Returns a list of commonly used citation styles with their identifiers.

API Details

Rate Limiting

The server implements automatic rate limiting with exponential backoff:

Initial retry delay: 5 seconds
Maximum retries: 3 (configurable)
Respects Zotero API Backoff and Retry-After headers
Requests are queued during rate limit periods

Caching

Intelligent caching reduces API calls and improves performance:

Item templates: 1 hour
Collections and tags: 15 minutes
Search results: 5 minutes
PDF full-text: 30 days
Citations: 1 hour

Error Handling

All errors are transformed into descriptive messages:

400 - Invalid request parameters
401/403 - Authentication failure (check API key)
404 - Item or resource not found
409 - Version conflict (item modified elsewhere)
412 - Precondition failed (library version changed)
429 - Rate limited (automatic retry)
5xx - Server error (automatic retry)

Development

Building from Source

npm install
npm run build

Running in Development Mode

npm run dev

Project Structure

src/
├── index.ts              # Server entry point
├── config/
│   └── default.ts        # Configuration management
├── services/
│   ├── zotero-client.ts  # Zotero API client
│   ├── cache-manager.ts  # Caching layer
│   └── pdf-extractor.ts  # PDF text extraction
├── tools/
│   └── index.ts          # MCP tool implementations
├── resources/
│   └── index.ts          # MCP resource implementations
├── utils/
│   ├── validators.ts     # Input validation
│   └── error-handler.ts  # Error transformation
└── types/
    └── zotero.ts         # Type definitions

Troubleshooting

Server won't start

Ensure you have created a .env file with valid credentials:

cp .env.example .env
# Edit .env and add your ZOTERO_API_KEY and ZOTERO_USER_ID

Authentication errors

Verify your API key at https://www.zotero.org/settings/keys
Ensure the API key has appropriate read/write permissions
Check that ZOTERO_USER_ID matches the ID shown on the API keys page

PDF extraction fails

PDFs must be indexed by Zotero Desktop application
Open Zotero Desktop and allow it to index PDF attachments
Verify the item has an actual PDF attachment (not just a link)

Claude Desktop doesn't show Zotero tools

Verify the absolute path in claude_desktop_config.json is correct
Check that environment variables in the config are set
Restart Claude Desktop completely (quit and reopen)
Check Claude Desktop logs: Help → View Logs

License

MIT

Contributing

Contributions are welcome. Please open an issue or submit a pull request.

Attribution

This MCP server uses the Zotero Web API to provide programmatic access to Zotero libraries. Zotero is a free, open-source reference management software developed by the Corporation for Digital Scholarship.

This project is not affiliated with, endorsed by, or sponsored by Zotero or the Corporation for Digital Scholarship.

Available Tools

9 tools

create_itemC

Create a new item in your Zotero library

ParametersJSON Schema

Name	Required	Description
`itemType`	Yes	Item type (book, journalArticle, thesis, etc.)
`title`	Yes	Item title
`creators`	No	Authors/editors
`date`	No
`DOI`	No
`url`	No
`tags`	No
`collections`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only says 'Create a new item'. It lacks disclosure of behavioral traits such as required permissions, behavior on duplicate entries, or side effects like automatic collection assignments.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise, but the description could be more informative without being verbose. It earns high marks for lack of fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and no output schema or annotations, the description is insufficient. It does not cover error handling, return values, or required fields beyond itemType and title.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 38% schema coverage, the description adds no parameter-level details beyond the schema. It does not explain expected formats for dates, creators, or item types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (create) and resource (item in Zotero library), and it implicitly distinguishes from siblings like update_item, delete_items, and search_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; for example, when to use create_item versus update_item or search_items is not addressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_itemsA

Delete items from library (supports batch up to 50)

ParametersJSON Schema

Name	Required	Description	Default
`itemKeys`	Yes	Item keys to delete (max 50)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only discloses the batch limit. It lacks details about permanence of deletion, side effects, or required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that is front-loaded with key information, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no output schema), the description adequately covers purpose and constraint. However, it could benefit from mentioning if deletion is reversible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reiterates the max 50 constraint but adds no new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Delete', the resource 'items from library', and includes a constraint 'supports batch up to 50', distinguishing it from sibling tools like 'create_item' and 'update_item'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates usage for deleting items but does not provide explicit guidance on when to use or avoid this tool, or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_pdf_textB

Extract full-text content from PDF attachments

ParametersJSON Schema

Name	Required	Description	Default
`itemKey`	Yes	Item key (parent item or attachment)
`pages`	No	Optional page range to extract

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden but only states the operation is a read ('extract'). It omits disclosure of constraints like file size limits, encoding, performance, or any side effects, leaving the agent underinformed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-front-loaded sentence with no wasted words. However, it could benefit from slightly more structure (e.g., separating key behaviors).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain return values (raw text format, metadata, etc.). It also fails to address handling of non-PDF attachments or edge cases, leaving gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for 'itemKey' and 'pages'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Extract full-text content from PDF attachments'), clearly indicating the action and target. It is distinct from sibling tools which focus on CRUD, citations, and searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description is purely declarative without contextual advice for agent decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_citationB

Generate formatted citations in various styles (APA, Chicago, MLA, IEEE, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`itemKeys`	Yes	Item keys to cite
`style`	Yes	Citation style (apa, chicago, mla, ieee, nature, etc.)
`format`	No	Output format	text

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. While generating citations is likely non-destructive, the description does not explicitly confirm lack of side effects, authentication needs, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the main purpose, lists example styles efficiently. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple generation tool with no output schema, the description is minimal but covers the core function. It could mention return format or that items must exist, but is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description need not add much. It lists style examples already present in the schema but does not provide additional context like valid formats or constraints beyond the enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Generate' and the resource 'formatted citations', and lists specific style examples, distinguishing it from sibling tools like create_item or search_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does, not when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_itemA

Get a single item by key or DOI

ParametersJSON Schema

Name	Required	Description	Default
`itemKey`	No	Zotero item key
`doi`	No	DOI to look up

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must convey behavioral traits. It describes a simple read operation, which is adequately transparent. However, it does not mention idempotency, performance, or authentication requirements, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 6 words, directly stating the tool's purpose. It is front-loaded and contains no unnecessary words, earning its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description sufficiently covers the tool's functionality for a simple retrieval operation. It clearly explains what it does and how to identify items, making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have schema descriptions (100% coverage). The description adds the concept of alternative identifiers ('key or DOI'), but this is minor. Baseline is 3, and the added value is limited.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the resource ('a single item'), and specifies the identifiers ('by key or DOI'). It distinguishes from sibling tools like search_items (multiple results) and create_item/update_item (modification).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving a single item, and the sibling context shows alternatives. However, it does not explicitly state when not to use or name alternatives, missing a chance to prevent misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

manage_collectionsC

Manage collections (create, list, get, delete)

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`collectionKey`	No
`name`	No
`parentCollection`	No

TDQS

C2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description should disclose behavioral traits, but it merely states actions. There is no mention of destructiveness, side effects, or preconditions for delete/publication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While short, the description is too minimal; it lacks essential details about the tool's behavior and parameters, which is not conciseness but under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters with 0% schema coverage, no output schema, and no annotations, the description is completely inadequate for an agent to understand how to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no meaning to the input schema parameters; it does not explain that 'collectionKey' is a required identifier for update/delete, or the role of 'parentCollection'. Schema description coverage is 0%, so the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists actions (create, list, get, delete) but omits 'update' which is present in the enum, creating ambiguity. It does not specify what a collection is, making the purpose somewhat clear but incomplete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like 'create_item' or 'search_tags'. The description only lists actions without context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

manage_tagsC

Manage tags (list, add to item, remove from item)

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`itemKey`	No
`tag`	No
`tags`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior, but it only lists actions. There is no mention of side effects, error conditions, or required dependencies (e.g., item existence for add/remove), leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, which is efficient, but it omits critical information. Conciseness comes at the cost of completeness, resulting in an adequate but not well-structured explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has four parameters and no output schema, the description fails to provide essential context about return values, parameter relationships, or behavior across actions. It is insufficient for reliable agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description adds no parameter explanations beyond the schema. The enum for 'action' provides some context, but 'itemKey', 'tag', and 'tags' are not described, making it hard to use correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool handles tags with three specific actions: list, add, and remove. Although 'manage' is somewhat generic, the parenthetical details clarify the purpose. It distinguishes from sibling tools like 'manage_collections' which focus on collections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions stated. The description simply lists actions without context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_itemsB

Search and retrieve items from your Zotero library with filtering by query, tags, collections, and item type

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Text search query across all fields
`qmode`	No	Search mode
`itemType`	No	Filter by item type (book, journalArticle, etc.)
`tag`	No	Filter by tags
`collection`	No	Filter by collection key
`limit`	No	Number of results (max 100)
`sort`	No	Sort field
`direction`	No	Sort direction	desc

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It does not mention side effects, rate limits, authentication requirements, pagination, or return format. The description only states basic functionality without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that efficiently states the tool's purpose and key filtering capabilities. No redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 optional parameters, no output schema, and no annotations, the description is adequate but incomplete. It explains what the tool does but omits details on result format, pagination limits, and interaction between filters, which are important for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description lists the filtering dimensions, which adds minimal semantic value beyond the schema, but does not explain parameter relationships or constraints (e.g., behavior when multiple filters are combined).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('search and retrieve') and specifies the resource ('items from your Zotero library') along with filtering dimensions (query, tags, collections, item type). This distinctly differentiates it from sibling tools like create_item or delete_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., get_item for single item lookup, manage_tags for tag operations). The description lacks context about prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_itemC

Update an existing item

ParametersJSON Schema

Name	Required	Description
`itemKey`	Yes	Item key to update
`version`	Yes	Current item version (for conflict detection)
`data`	Yes	Fields to update

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Update an existing item', which implies mutation but does not reveal details about idempotency, partial updates, conflict handling, or side effects. This is insufficient for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundancy. It is front-loaded and easy to parse. However, it may be overly terse given the tool's complexity (3 params, no output schema).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three required parameters including a version field and a nested object, and no output schema, the description is underspecified. It fails to explain the purpose of version for optimistic concurrency, the format of the data object, or what the tool returns. The sibling context shows many other tools, but the description does not help the agent choose correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter name and description is already documented. The tool description adds no extra meaning beyond the schema (e.g., does not explain how 'version' is used for conflict detection or what fields 'data' can contain). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses 'update' as the verb and 'existing item' as the resource, clearly indicating a modification operation. It distinguishes from sibling tools like create_item (creation) and delete_items (deletion), but lacks specificity about what type of item or any scope limitations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like manage_tags or manage_collections. The description only states the action without any context about prerequisites, when not to use, or trade-offs compared to other update-capable siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a distinct purpose with no overlapping functionality. Create, delete, extract, generate, get, manage collections, manage tags, search, and update are all clearly separated.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case. Verbs like create, delete, get, search, update are used predictably, with manage_ prefixed for collection and tag operations.

Tool Count5/5

9 tools cover the core operations of a Zotero library management server: CRUD for items, collections, tags, plus search, citation generation, and PDF extraction. The count is well-scoped without being excessive.

Completeness4/5

The tool set covers basic CRUD, search, citation, and PDF extraction. Minor gaps exist such as lack of batch update or attachment upload, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Papertext
app.papertext.app
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search Research & Data Knowledge & Memory
2
Books & Papers MCP Server A
io.github.jmrplens
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search Education & Learning Tools Research & Data
417
Scholar Sidekick A
io.github.mlava
Catch AI-fabricated citations (real DOI + fake title). Retraction, open-access, 10,000+ CSL styles.
Research & Data Open Data
718
paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21

Related MCP Servers

MCP Zotero
Research & Data Note Taking Documentation Access
kaliaboi
A
license
B
quality
F
maintenance
Allows AI to interact with your Zotero library.
Updated 2 years ago (2025-02-04 19:51 UTC)
5
90
164
MIT
zotero-mcp-lite
Research & Data Knowledge & Memory Search
xmruuu
A
license
A
quality
D
maintenance
Enables AI assistants to search, read, and manage Zotero references locally with customizable research workflows.
Updated 4 months ago (2026-05-08 12:24 UTC)
9
4
MIT
Stratosphere MCP Zotero
Research & Data Note Taking
stratosphereips
A
license
Not graded
quality
B
maintenance
Enables natural language interaction with Zotero libraries, allowing users to search, retrieve, and update papers and metadata via AI assistants like Claude and Gemini.
Updated 4 months ago (2026-05-13 18:12 UTC)
1
GPL 2.0
zotero-mcp
Research & Data Search
harrig12
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search and retrieve metadata, abstracts, and notes from a user's Zotero library through tools like search, get item, and list collections.
Updated 5 months ago (2026-04-07 21:51 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielostrow/zotero-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Zotero MCP Server

Features

Tools

Resources

Prerequisites

Installation

Option 1: NPM (Coming Soon)

Option 2: From Source

Configuration

Getting Your Credentials

Environment Variables

Optional Configuration

Usage with Claude Desktop

Tool Usage Examples

Searching Items

Generating Citations

Extracting PDF Text

Creating Items

Managing Collections

Managing Tags

Resource Usage Examples

Collections Resource

Tags Resource

Citation Styles Resource

API Details

Rate Limiting

Caching

Error Handling

Development

Building from Source

Running in Development Mode

Project Structure

Troubleshooting

Server won't start

Authentication errors

PDF extraction fails

Claude Desktop doesn't show Zotero tools

License

Contributing

Attribution

Links

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API