Which integrations are available for this server?

Provides read-only access to a Zotero group library, enabling search for papers, retrieval of bibliographic metadata and attachment lists, and fetching synchronized full-text content from Zotero.

How do I use MCP Zotero?

1. Click on "Deploy 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., "@MCP Zotero search for papers on CRISPR and return the first full-text excerpt for each" 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.

MCP Zotero

by bindresearch

Overview Schema Source Related Servers Discussions Admin

Python

Remote

WARNING

This is entirely vibe-coded (but human-reviewed)

MCP Zotero

This project provides read-only MCP access to one Zotero group library. It uses the Zotero Web API v3 and can run over Streamable HTTP or stdio.

The server is stateless. It does not keep a local index. It does not download or parse PDF files. Zotero performs the search and supplies synchronized attachment text.

Tools

`search_papers`

Search Zotero with qmode=everything. The server resolves attachment, note, and annotation results to their parent bibliographic items. It then removes duplicate papers.

The Zotero Web API currently supports phrase search. For broad discovery, use separate short queries and synonyms. Zotero does not provide a relevance sort for item requests, so results use the most recently modified items first. Zotero's result count is a count of raw matching items, not unique parent papers.

`get_paper`

Get all metadata and the attachment list for one bibliographic item.

`get_paper_text`

Get synchronized text from Zotero's /items/{attachmentKey}/fulltext endpoint. The tool does not request the attachment file.

The tool returns a bounded character range by default. Supply query to get excerpts around literal matches. Zotero full text has no reliable page boundaries, so the tool uses character offsets.

Related MCP server: zotero-mcp

Requirements

Python 3.13 or later
Zotero group ID (find from the URL)
A read-only Zotero API key with access to the group and its files

Create a dedicated key in your Zotero account settings. The MCP endpoint has no authentication and must stay on a private network.

Configuration

Copy the example configuration:

cp .env.example .env

Set these required values:

ZOTERO_GROUP_ID=123456
ZOTERO_API_KEY=replace-with-a-read-only-api-key

The main optional settings are:

MCP_TRANSPORT=streamable-http  # or stdio
MCP_HOST=127.0.0.1
MCP_PORT=8000
MCP_LOG_LEVEL=INFO
MCP_MAX_TEXT_CHARACTERS=12000
ZOTERO_TIMEOUT_SECONDS=30
ZOTERO_MAX_RETRIES=3
ZOTERO_MAX_SEARCH_PAGES=20

Install and run

Install the project with uv:

uv sync

Start the server. The default is Streamable HTTP:

uv run mcp-zotero

Set MCP_TRANSPORT=stdio in .env to run over standard input/output instead:

MCP_TRANSPORT=stdio uv run mcp-zotero

Streamable HTTP

The MCP endpoint is:

http://127.0.0.1:8000/mcp

Point the LiteLLM MCP server configuration at this URL. No MCP authorization header is required. Use MCP_HOST=0.0.0.0 when LiteLLM connects from another container or host on the private network.

stdio

Run in stdio mode for a local MCP client that launches the process directly.

For interactive development, use the MCP Inspector:

uv run mcp dev src/mcp_zotero/server.py

Test

uv run pytest

API behavior

The client sends these headers to Zotero:

Zotero-API-Key: ...
Zotero-API-Version: 3

It observes Zotero Backoff and Retry-After headers. It sends no more than four concurrent Zotero requests. Parent items are retrieved in batches of at most 50 keys, as required by the API.

A PDF can have no synchronized text even when its attachment metadata exists. In this case, get_paper_text returns status="not_available".

Zotero documentation

Available Tools

3 tools

get_paperA

Read-onlyIdempotent

Get a paper's complete Zotero metadata and attachment list.

ParametersJSON Schema

Name	Required	Description	Default
`item_key`	Yes	The 8-character Zotero key of a bibliographic item.

Output Schema

ParametersJSON Schema

Name	Required	Description
`summary`	Yes
`creators`	No
`metadata`	Yes	All metadata fields returned in the Zotero item's data object.
`attachments`	No

TDQS

A4.1/5.0

Behavior4/5

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

The description adds that the result includes complete Zotero metadata and attachment list, which is consistent with the readOnly and idempotent annotations and implies no destructive behavior.

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 with the verb and object front-loaded, containing no redundant or misleading words.

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?

For a simple read-only metadata lookup with one well-described parameter, the description and schema provide enough context for an agent to invoke the tool 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?

The single parameter item_key is fully described in the schema as an 8-character Zotero key; the description adds no further parameter-specific detail, so the schema coverage baseline applies.

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?

Clearly states the action (get), the object (a paper), and the scope (complete Zotero metadata and attachment list), making the tool's purpose unambiguous.

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 implies this tool is for metadata/attachments rather than paper text, especially given the sibling get_paper_text, but it does not explicitly state when to choose this tool over alternatives.

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

get_paper_textA

Read-onlyIdempotent

Read bounded text from Zotero's synchronized full-text endpoint.

This tool does not download or parse the PDF. Zotero does not provide reliable page boundaries, so returned segments use character offsets.

ParametersJSON Schema

Name	Required	Description
`query`	No	Optional literal phrase. When set, return excerpts around matches instead of one contiguous text segment.
`offset`	No	Character offset for contiguous text or the start of excerpt search.
`item_key`	Yes	The 8-character Zotero key of a bibliographic item.
`attachment_key`	No	A PDF attachment key returned by get_paper. It is required only when the paper has multiple PDF attachments.
`max_characters`	No	Maximum text characters to return. The server-configured maximum is used when this value is omitted.

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	No
`status`	Yes
`message`	No
`item_key`	Yes
`segments`	No
`match_count`	No
`next_offset`	No
`total_pages`	No
`indexed_pages`	No
`attachment_key`	No
`total_characters`	No
`content_characters`	No
`indexed_characters`	No
`available_attachments`	No

TDQS

A3.6/5.0

Behavior3/5

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

The annotations already declare readOnly and idempotent behavior. The description adds context about not downloading or parsing PDFs and the use of character offsets, which provides some behavioral detail beyond the annotations, but it does not cover other potential behaviors like error conditions or performance implications.

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 concise and to the point, consisting of three short sentences with no redundant or irrelevant information. It efficiently communicates the core function and key limitations without unnecessary elaboration.

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?

The description is complete enough given the presence of an output schema. It covers the purpose, limitation (no page boundaries), and a key technical detail (character offsets). It does not mention error scenarios or return format, but those are not required when an output schema exists.

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?

The input schema provides descriptions for all five parameters, achieving 100% coverage. The description adds a brief clarification about character offsets, which aids understanding of the offset parameter, but it does not elaborate on the other parameters (item_key, attachment_key, max_characters) beyond what is already in 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 tool's purpose with a specific verb ('Read') and resource ('bounded text from Zotero's synchronized full-text endpoint'). It also differentiates itself from sibling tools by explicitly noting it does not download or parse PDFs, making its scope unambiguous.

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 is provided on when to use this tool versus the sibling tools (search_papers, get_paper). The description mentions limitations (no page boundaries, character offsets) but does not state conditions under which this tool is preferable or when alternatives should be chosen.

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

search_papersA

Read-onlyIdempotent

Search paper metadata and Zotero-indexed full text with a phrase query.

Attachment, note, and annotation matches are resolved to their parent paper. The result does not claim which attachment field matched. Use get_paper_text with a returned attachment key to inspect synchronized PDF text.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`query`	Yes	A Zotero quick-search phrase. Zotero searches item metadata, notes, tags, and indexed full text when qmode=everything is used.
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes
`query`	Yes
`offset`	Yes
`papers`	No
`returned`	Yes
`next_offset`	No
`scan_limit_reached`	No
`scanned_zotero_items`	Yes
`zotero_total_results`	Yes
`more_results_available`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Beyond read-only annotations, it discloses a key behavior: attachment matches are resolved to parent papers, and it states the result does not claim which attachment field matched—so users know the limitation.

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 three sentences, concise, and front-loads the primary purpose without superfluous detail.

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?

The tool is simple; the description covers the main search behavior and directs to get_paper_text for follow-up, but does not mention pagination or output summary, though those are likely covered by the output schema.

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?

Only the query parameter is described (as a phrase query); limit and offset lack descriptions in the schema and are not explained in the description, so semantics are incomplete for two of three parameters.

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 tool searches paper metadata and Zotero-indexed full text with a phrase query, distinguishing it from sibling tools that retrieve specific papers or text.

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?

It gives explicit follow-up guidance to use get_paper_text for inspecting matched PDF text and notes that matches are resolved to parent papers, but does not explicitly contrast with get_paper.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Sep 8, 2026
- First observedget_paper
- First observedget_paper_text
- First observedsearch_papers

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-09-08 00:40 across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: searching, retrieving full text, and fetching metadata. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (search_papers, get_paper_text, get_paper) with clear actions and targets.

Tool Count5/5

Three tools is well-scoped for a focused read-only Zotero server, covering the essential operations without redundancy.

Completeness4/5

Covers the primary use cases of searching and retrieving papers, but lacks management operations (e.g., create, update, delete) which may be outside the intended scope. Minor gap for full CRUD, but adequate for a search/retrieval tool.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

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.
Education & Learning Tools Research & Data Search
4111
adamamer20-paper-search-mcp-openai COAuth
ai.smithery
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
Search Research & Data Open Data
25215
ZoteusOAuth
io.github.oscardvs
Zotero MCP server for Claude and ChatGPT: search, citations, safe writes, PDF passages and pages.
Research & Data Search
136

Related MCP Servers

Zotero MCP Server
Research & Data Education & Learning Tools
awsl5714
A
license
A
quality
D
maintenance
Enables LLM-powered tools to interact with Zotero academic libraries, including searching papers, adding arXiv papers, updating metadata, and generating literature reviews.
Updated 3 months ago (2026-06-20 06:58 UTC)
10
1
MIT
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)
-
zotero-fulltext-mcp
Research & Data Search
matthiaskloft
A
license
Not graded
quality
B
maintenance
Enables searching and reading full text of papers in a Zotero library by converting PDF attachments to Markdown and exposing a full-text search index to LLM tools.
Updated 2 months ago (2026-07-27 15:32 UTC)
MIT
Zotero Research MCP
RAG Systems Research & Data Search
tomozzz
A
license
Not graded
quality
B
maintenance
Enables ChatGPT to search and retrieve papers, passages, and page evidence from a local Zotero library via a read-only MCP server.
Updated 2 months ago (2026-07-16 06:44 UTC)
AGPL 3.0