zotero-mcp-lite

by alexobiwan-creator

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct action and resource (e.g., creating notes, listing collections, getting metadata, searching annotations). There is no overlap in functionality, and descriptions clearly differentiate purposes.
Naming Consistency5/5
All tools follow the consistent pattern 'zotero_verb_noun' in snake_case, using clear verbs like create, get, search. This makes the naming predictable and intuitive.
Tool Count4/5
9 tools is appropriate for a reference management server with core features (collections, items, notes, annotations, search). It covers essential workflows without being excessive, though some common operations like updating or deleting items are missing.
Completeness3/5
The tool set covers viewing and searching well but lacks create/update/delete for items (papers) and notes (except creating notes). This is a notable gap for a complete reference management workflow, though the 'lite' label may justify it.
Average 4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns PDF highlights with colors, margin comments, and standalone notes, providing good insight into the output. No annotations exist, but the description is sufficient for a read-only retrieval tool.
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 two sentences, front-loaded with the core purpose, and adds return details and context in the second sentence. 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?
With one required parameter and an output schema, the description covers the return types but fails to explain the input parameter. The output schema likely provides return structure, but the parameter gap reduces completeness.
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?
The description does not explain the 'item_key' parameter or how to obtain it. Schema description coverage is 0%, so the description should compensate, but it only vaguely mentions 'for a paper' without specifying the input format.
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 states that the tool retrieves reading annotations and notes for a paper, listing specific return types (highlights, comments, notes). However, the tool name 'get_item_children' suggests broader functionality than just annotations, causing slight ambiguity.
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 mentions it's essential for a literature_review prompt, giving a use case. But it does not explicitly contrast with siblings like 'zotero_search_annotations' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool shows hierarchy and organization, but does not disclose details like pagination, rate limits, or that it is a read-only operation. Adequate but limited.
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?
Three concise sentences, all front-loaded with purpose and usage guidance. 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?
The description lacks details about the 'limit' parameter and does not explain the output format despite having an output schema. For a list tool, omitting behavior of the only parameter is a gap.
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?
Schema coverage is 0% and the description does not mention the 'limit' parameter at all. The description adds no value beyond the schema's parameter outline, which itself has no descriptions.
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 lists all folders/collections with hierarchy, using specific verb 'list' and resource 'folders/collections'. It distinguishes from sibling tools like zotero_get_collection_items which focuses on items within a collection.
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 explicitly mentions using the collection key with get_collection_items to browse papers, providing clear alternative usage. It does not explicitly state when not to use this tool, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says 'List all' but schema has limit default 25, implying pagination. Fails to disclose that results may be truncated. With no annotations, this is a notable gap.
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?
Two efficient sentences: first states purpose, second adds filtering behavior and downstream usage. No fluff, front-loaded.
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?
Covers main workflow, but lacks explanation of limit/pagination and does not clarify that only keys are returned (though output schema may cover structure). Adequate but not comprehensive given no annotations.
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?
Adds crucial meaning for item_type parameter (default papers only, use '' for notes). But does not explain collection_key or limit; given 0% schema coverage, description partially compensates but not fully.
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 it lists papers/references in a collection, with default filtering. Distinguishes purpose from sibling tools by specifying output keys for use with get_item_metadata or get_item_children.
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?
Provides guidance on using item_type parameter to include notes, and suggests subsequent tools for citation metadata or highlights. Could be more explicit about when not to use this tool vs zotero_search_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation by saying 'get', but does not explicitly state read-only behavior, side effects, required permissions, or error handling. For a metadata retrieval tool, more disclosure (e.g., 'read-only, no side effects') is expected.
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 efficient with four sentences, each adding value: main purpose, return fields, alternative tools, and a usage tip. No redundant or filler content. Could be slightly tighter by removing the tip, but acceptable.
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 the tool has two parameters (one optional), no enums, and an output schema exists, the description covers the primary use case and return format. However, it omits details about the optional parameter (include_bibtex), input assumptions (valid item_key), and any constraints like authentication or rate limits. The presence of an output schema partially compensates, but gaps remain.
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 description coverage is 0%, meaning no parameter descriptions exist. The description mentions return fields (title, authors, etc.) but does not explain the 'include_bibtex' boolean parameter. It adds minimal meaning beyond the schema for the 'item_key' parameter by implying it identifies the item. This is insufficient for complete parameter understanding.
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 specifies the verb 'get' and resource 'complete bibliographic metadata', and distinguishes from sibling tools by naming alternatives for annotations (get_item_children) and full text (get_item_fulltext). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for metadata) and when to use alternatives (annotations: get_item_children; full text: get_item_fulltext). Also includes a tip for structured literature reviews, advising against ad-hoc analysis. No gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches and returns item keys, and describes two search modes. However, it does not explicitly state that the operation is read-only (implied but not confirmed), nor does it mention any rate limits 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?
Two sentences with clear front-loading. Every sentence adds value: first states purpose, second explains modes and follow-up. No wasted 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?
For a search tool with an output schema, the description covers the primary purpose and usage. It explains two qmodes and directs to related tools. However, it omits details about default item_type (excludes attachments) and pagination via limit, which would help completeness given the 5 parameters.
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 0%, so description must compensate. It adds value by explaining qmode options ('titleCreatorYear' default vs. 'everything') and the return type (item keys). But it does not describe the purpose of item_type, limit, or tag parameters, leaving gaps for a 5-parameter tool.
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?
Description clearly states it searches a reference library by keyword and specifies the resource type (papers, articles, books, notes). It connects to sibling tools by mentioning item keys for get_item_metadata or get_item_children. However, it could more explicitly differentiate from zotero_search_annotations, which searches annotations.
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?
Provides clear guidance on when to use default vs. 'everything' qmode, explaining that default searches title/author/year while 'everything' searches full text and note contents. Also informs the agent about subsequent tools to use (get_item_metadata or get_item_children). Does not explicitly state when to avoid this tool in favor of others like list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It reveals that content is auto-converted to HTML and line breaks/spacing are preserved. However, it omits details about error behavior (e.g., invalid parent_key), authentication requirements, rate limits, or confirmation of creation success. The mutation nature is implied but not explicitly stated.
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 with no wasted words: first sentence states purpose and formatting, second lists use cases, third explains behavior. It is front-loaded with the primary action and remains succinct.
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 tool simplicity (3 parameters, 1 required) and the existence of an output schema, the description covers the essential context: purpose, use cases, and key parameter behaviors. It does not describe the return value, but the output schema likely fulfills that. A brief mention of what to expect upon creation would improve completeness.
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 0%, so the description must compensate. It explains that 'Content is auto-converted to HTML' (adding meaning to the content parameter) and that parent_key attaches to a paper for organization. However, it does not mention the tags parameter or provide any syntax or constraints, leaving a gap.
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 verb 'Create' and resource 'note in Zotero', specifies formatting support (tables, lists, line breaks), and lists concrete use cases (literature reviews, summaries, research memos). It distinguishes itself from sibling tools, which are all retrieval-oriented (get, search), making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Use for: saving literature reviews, summaries, research memos, or any content' and 'Attach to a paper with parent_key for organized reference management.' It does not explicitly state when not to use or compare to alternatives, but since all siblings are read-only, exclusions are implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that long papers are truncated and suggests asking about specific sections, which is key behavioral info. Lacks explicit mention of being read-only or requiring PDF access, but 'Extract and read' implies non-destructive.
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?
Two sentences, front-loaded with verb and object. No wasted words. First sentence states core purpose, second adds usage guidance and a behavioral note.
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?
Has output schema but no annotations. Description provides basic purpose and truncation info but omits parameter explanations, preconditions (item must have PDF), and whether it's read-only. Adequate but not thorough for a 2-param tool.
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 has 2 parameters with 0% description coverage. Description does not explain item_key (required identifier) or max_chars (optional limit). Schema property names are somewhat self-explanatory, but the description should clarify them for reliable use.
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?
Description clearly states it extracts full text from PDF papers, using specific verb 'Extract and read' and resource 'full text content from a PDF paper'. It distinguishes from sibling tools like zotero_get_item_metadata (which likely returns metadata/abstract) and search tools.
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?
Explicitly says 'Use when you need to analyze the actual paper content beyond the abstract', which guides when to invoke. Also mentions truncation for long papers, implying when to ask for sections. Does not explicitly exclude other use cases or mention alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description explains default behavior (papers only, sorting by dateModified) and how to modify it. Discloses that it returns recent items, but doesn't explicitly state it is read-only or mention pagination. Still, clear and consistent.
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?
Two sentences only; first sentence clearly states purpose, second sentence provides critical parameter guidance. No wasted words, front-loaded effectively.
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?
Covers main use cases and parameter behavior. Output schema exists so return details aren't needed. Could mention that results are a subset of library items, but overall adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds meaning for sort_by and item_type (e.g., 'dateModified' for reading activity, 'dateAdded' for imports, default excludes notes). Doesn't explain limit, but its purpose is obvious.
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?
Description uses specific verb 'Get' and resource 'recently read, modified, or imported papers from your library', clearly distinguishing it from general search tools. The name 'get_recent' aligns with the behavior.
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?
Provides guidance on when to use different parameter values (e.g., sort_by='dateAdded' for imports, item_type='' for notes), but does not explicitly compare to sibling tools like zotero_search_items or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return values (highlighted text, comments, page numbers, parent paper context) and scope (across all papers). It is transparent for a read-only search tool.
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, front-loaded with the core action, followed by usage guidance and return details. Every sentence adds value without redundancy.
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 the tool's low complexity (2 simple parameters, output schema exists), the description covers purpose, usage, and return fields adequately. No gaps remain.
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?
With 0% schema description coverage, the description partially compensates by explaining 'query' as a keyword search term. However, the 'limit' parameter is not described, leaving a gap.
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 'Search' and the resource 'PDF highlights and comments across your entire library by keyword'. It distinguishes from sibling tools like zotero_search_items which search metadata, not annotations.
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 provides explicit use cases such as 'cross-paper knowledge synthesis' and 'finding where you discussed a concept'. It implies appropriate contexts but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

zotero-mcp-lite MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![zotero-mcp-lite MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/alexobiwan-creator/zotero-mcp-lite/badges/card.svg)](https://glama.ai/mcp/servers/alexobiwan-creator/zotero-mcp-lite)

Score Badge

Copy to your README.md:

[![zotero-mcp-lite MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/alexobiwan-creator/zotero-mcp-lite/badges/score.svg)](https://glama.ai/mcp/servers/alexobiwan-creator/zotero-mcp-lite)