zotero-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Zotero operations like collection management, item CRUD, duplicate handling, and import/search functions. There is no significant overlap between tools - for example, 'add_to_collections' and 'remove_from_collection' are complementary but distinct operations, and 'create_item' vs 'create_item_from_doi' serve different creation workflows.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern throughout (e.g., create_collection, get_item, search_items, import_bibtex). The naming is perfectly predictable and readable, with no mixing of conventions or inconsistent verb styles across the toolset.
Tool Count5/5
With 15 tools, this server provides comprehensive coverage of Zotero's core functionality without being overwhelming. The count is well-scoped for a reference management system, covering collections, items, duplicates, imports, and searches - each tool earns its place in the domain.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for Zotero's domain: full item management (create, get, update, delete), collection operations (create, get, add/remove items), duplicate handling (find and merge), import capabilities, and search functionality. There are no obvious gaps that would cause agent failures in typical reference management workflows.
Average 3.1/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal critical traits: whether this is a mutation (implied by 'Add'), what permissions are required, if it's idempotent (e.g., adding to already-associated collections), error conditions (e.g., invalid keys), or side effects. The description is minimal and lacks operational 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?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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 an output schema (which likely covers return values), the description's minimalism is less problematic. However, for a mutation tool with 2 parameters, 0% schema coverage, and no annotations, the description should do more to explain behavior and parameter meaning. It's borderline adequate but leaves significant gaps in understanding.
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%, so parameters are undocumented in the schema. The description mentions 'item' and 'collections' but doesn't explain what 'item_key' and 'collection_keys' represent (e.g., identifiers, formats), their constraints, or examples. It adds minimal semantic value beyond naming the entities involved.
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 the action ('Add') and the target resource ('Zotero item to one or more collections'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'remove_from_collection' or 'update_item' that might also involve collection-item relationships.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the item and collections must already exist), exclusions, or how it differs from tools like 'create_item' (which might add to collections during creation) or 'update_item' (which might modify collection membership).
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention permissions needed, whether it's idempotent, what happens on duplicate names, or what the output contains. This leaves significant gaps for a mutation 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a basic creation operation and gets straight to the point without unnecessary elaboration.
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?
While the description is minimal, the presence of an output schema reduces the need to explain return values. However, for a mutation tool with 2 parameters and no annotations, the description should provide more context about behavior and parameter meaning to be truly complete.
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%, so the description must compensate but provides no parameter information. It doesn't explain what 'name' represents (display name vs. identifier), what 'parent_key' is for (creating nested collections), or format expectations. The two parameters remain semantically unclear.
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 the action ('Create') and resource ('new Zotero collection'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_to_collections' or 'get_collections' beyond the basic verb distinction.
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 like 'add_to_collections' for modifying existing collections or 'get_collections' for viewing them. The description lacks context about prerequisites or typical use cases.
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?
With no annotations, the description carries full burden but only states it creates an item without disclosing behavioral traits like permissions needed, whether it's idempotent, error handling, or what the output contains. It mentions Zotero as context but adds minimal operational insight.
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, direct sentence with zero waste—it efficiently conveys the core action without unnecessary words. It's appropriately sized and front-loaded for quick comprehension.
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 10 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to explain returns), the description is incomplete. It covers the basic purpose but lacks details on parameters, usage, and behavior needed for effective tool 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 description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'item_type' entails, the format of 'creators', or the purpose of fields like 'collections' and 'tags', leaving parameters largely undocumented.
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 the action ('Create') and resource ('new item in Zotero'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'create_item_from_doi' or 'create_collection', but it's not vague or tautological.
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 like 'create_item_from_doi' for DOI-based creation or 'import_bibtex' for batch imports. The description lacks context about prerequisites or typical use cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what the tool does but doesn't describe how it behaves: no information about permissions needed, whether it's read-only or has side effects, performance characteristics, or what the output contains. For a tool with 4 parameters and no annotation coverage, this is inadequate.
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 extremely concise (one sentence) and front-loaded with the core functionality. Every word earns its place: 'Find duplicate items' establishes purpose, 'by title or DOI' specifies methods, 'or scan entire library' adds an alternative approach. Zero waste.
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 4 parameters with 0% schema coverage and an output schema exists, the description is minimally complete. The output schema will handle return values, but the description doesn't provide enough context about behavioral aspects or parameter usage. It's adequate for a basic understanding but lacks depth for effective tool selection.
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%, so the description must compensate for undocumented parameters. It mentions 'title or DOI' and 'scan entire library', which loosely maps to 'title', 'doi', and 'scan_all' parameters, but doesn't explain 'collection_key' at all. The description adds some meaning but doesn't fully compensate for the coverage gap, especially for the unexplained parameter.
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 the tool's purpose: 'Find duplicate items by title or DOI, or scan entire library'. It specifies the action (find duplicates) and the resources (items) with multiple search methods. However, it doesn't explicitly distinguish this from sibling tools like 'merge_duplicates' or 'search_items', which would require a 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'search_items' for finding duplicates, or how it relates to 'merge_duplicates' (which presumably handles merging after finding). There's no context about prerequisites or exclusions.
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 the full burden of behavioral disclosure. It states the tool lists items, implying a read-only operation, but doesn't cover critical aspects like pagination (the 'limit' parameter suggests it), error handling (e.g., invalid collection_key), authentication needs, or rate limits. The description is minimal and leaves key behavioral traits unspecified.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose ('List items in a specific Zotero collection'), making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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's moderate complexity (2 parameters, no annotations, but with an output schema), the description is incomplete. It covers the basic purpose but lacks usage guidelines, parameter details, and behavioral context. The presence of an output schema means return values are documented elsewhere, reducing the burden, but the description still misses key operational aspects for effective use.
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%, so the description must compensate for undocumented parameters. It mentions 'a specific Zotero collection', which hints at the 'collection_key' parameter, but doesn't explain what a collection_key is or its format. The 'limit' parameter is not addressed at all. The description adds minimal semantic value beyond the schema's structural definition.
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 the action ('List items') and resource ('in a specific Zotero collection'), making the purpose immediately understandable. It distinguishes from siblings like 'get_collections' (which lists collections) and 'get_item' (which retrieves a single item), though it doesn't explicitly name these alternatives. The description is specific but could be slightly more precise about what 'items' refers to (e.g., bibliographic entries).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to 'search_items' (which might filter across collections) or 'get_item' (for single items), nor does it specify prerequisites like needing a valid collection_key. Usage context is implied but not articulated.
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?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions required, whether imports are reversible, rate limits, or what happens on failure (e.g., invalid BibTeX). This leaves significant gaps for a mutation 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 a single, efficient sentence with zero wasted words, making it easy to parse and front-loaded. It directly conveys the core purpose without unnecessary elaboration.
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 an output schema (which handles return values) and no annotations, the description is minimally adequate but incomplete. It covers the basic action but lacks details on parameters, behavioral context, and differentiation from siblings, which are needed for a mutation tool with 2 parameters.
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%, so the description must compensate but adds no parameter details. It doesn't explain what 'bibtex' should contain (e.g., raw BibTeX text) or what 'collection_key' does (e.g., target collection identifier), leaving both parameters undocumented beyond their schema types.
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 the action ('import') and target ('BibTeX entries into Zotero'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_item' or 'create_item_from_doi' that might also add content to Zotero, missing explicit distinction.
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?
The description provides no guidance on when to use this tool versus alternatives such as 'create_item' or 'create_item_from_doi', nor does it mention prerequisites like needing valid BibTeX format. Usage is implied but not explicitly stated.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the merge action and outcome ('transfer metadata, tags, collections to keeper, trash rest'), which implies a destructive operation on the removed items. However, it lacks details on permissions required, whether the operation is reversible, error handling (e.g., if keys are invalid), or side effects like updating references. For a tool that modifies data, this is insufficient.
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, efficient sentence that front-loads the core action ('Merge duplicate Zotero items') and succinctly explains the process. Every word earns its place, with no redundancy or fluff, making it easy to parse quickly.
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's complexity (destructive merge operation), lack of annotations, and 0% schema coverage, the description is incomplete. It covers the basic purpose but misses critical details like parameter semantics, behavioral risks, and usage context. However, the presence of an output schema mitigates the need to describe return values, keeping it from being entirely inadequate.
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%, so the description must compensate for undocumented parameters. It mentions 'keeper' and implies 'remove_keys' correspond to items to be trashed, but doesn't explain what 'keep_key' and 'remove_keys' represent (e.g., Zotero item keys), their format, or constraints (e.g., must be valid keys, cannot overlap). The description adds minimal meaning beyond the schema's property names.
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 the action ('merge duplicate Zotero items') and specifies what happens during the merge ('transfer metadata, tags, collections to keeper, trash rest'). It distinguishes from siblings like 'find_duplicates' (which identifies but doesn't merge) and 'delete_item' (which deletes without merging). However, it doesn't explicitly contrast with all relevant siblings like '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 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. It doesn't mention prerequisites (e.g., needing to identify duplicates first with 'find_duplicates'), nor does it specify scenarios where merging is appropriate versus deleting or updating items separately. The description assumes the user already knows when merging is needed.
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?
With no annotations, the description carries full burden but only states it updates fields without disclosing behavioral traits. It lacks details on permissions required, whether changes are reversible, rate limits, error handling, or what the update entails (e.g., partial vs. full replacement). This is a significant gap for a mutation 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 a single, efficient sentence with zero waste, clearly front-loaded with the core action. It's appropriately sized for the tool's complexity.
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 a mutation tool with no annotations, 0% schema coverage, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks crucial details like behavioral transparency and parameter semantics, though the output schema may help with return values.
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%, so the description must compensate but adds minimal meaning. It mentions 'fields' generically without explaining what fields are updatable or their formats, and 'item_key' is not contextualized. This fails to address the undocumented parameters adequately.
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 the verb ('Update') and resource ('existing Zotero item'), specifying it modifies fields on an item. It distinguishes from siblings like 'create_item' or 'delete_item' by focusing on updates, but doesn't explicitly differentiate from similar tools like 'merge_duplicates' in terms of scope.
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. It doesn't mention prerequisites (e.g., needing an existing item key), exclusions, or comparisons to siblings like 'merge_duplicates' for handling duplicates or 'create_item' for new 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 discloses the deletion behavior (move to trash or permanent delete) but omits critical details: whether deletion requires specific permissions, if it's reversible, what happens to associated data, or rate limits. For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational 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?
The description is a single, efficient sentence that front-loads the core action and includes essential behavioral detail (trash vs. permanent). Every word earns its place with no redundancy or fluff, making it highly concise and well-structured.
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's complexity (destructive operation with 2 parameters), lack of annotations, and presence of an output schema, the description is moderately complete. It covers the basic action and parameter intent but misses permission requirements, reversibility, and error handling. The output schema may help with return values, but the description doesn't reference it, leaving gaps in operational context.
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 adds meaning by explaining that 'permanent' controls trash vs. permanent deletion, which clarifies the boolean parameter's purpose. However, it doesn't describe 'item_key' (e.g., format, source) or provide examples, leaving half the parameters with minimal context beyond the schema.
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 the action ('Delete') and resource ('a Zotero item'), with additional clarification about moving to trash or permanent deletion. It distinguishes from siblings like 'remove_from_collection' by specifying deletion rather than collection management, though it doesn't explicitly compare to other destructive tools like 'merge_duplicates'.
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. It doesn't mention prerequisites (e.g., item existence), exclusions, or compare to similar tools like 'remove_from_collection' for non-destructive removal. The description implies usage for deletion but lacks contextual direction.
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 the full burden of behavioral disclosure. It states the tool retrieves 'detailed metadata,' implying a read-only operation, but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'detailed' entails. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly, which is ideal for conciseness.
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's low complexity (2 parameters, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks behavioral details (e.g., error cases, permissions) and parameter guidance, making it incomplete for optimal agent use, though not severely deficient due to the simple structure.
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 description adds no semantic information about the parameters beyond what the input schema provides. With 0% schema description coverage, the parameters 'item_key' and 'format' are undocumented in both the schema and description. However, the baseline is 3 because the tool has only 2 parameters, and the description implies retrieval of a single item, which loosely relates to 'item_key,' but it doesn't compensate for the lack of details on parameter usage or meaning.
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 the tool's purpose with a specific verb ('Get') and resource ('detailed metadata for a single Zotero item'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_items' or 'get_collection_items', which might also retrieve item information but with different scopes or filters.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an item key), exclusions, or comparisons to siblings like 'search_items' for broader queries or 'get_collection_items' for collection-specific lists, leaving the agent to infer usage context.
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 the full burden of behavioral disclosure. It states this is a listing operation, implying it's likely read-only and non-destructive, but doesn't confirm this explicitly. It also omits details like rate limits, authentication needs, or pagination behavior, leaving gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. There's no wasted verbiage or redundant 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?
Given the tool's low complexity (a simple list operation with 2 parameters) and the presence of an output schema, the description is minimally complete. It covers the basic purpose but lacks details on behavior, parameters, and usage context. With no annotations and low schema coverage, it doesn't fully compensate for these gaps, making it adequate but not comprehensive.
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 description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage, the schema only defines 'query' and 'limit' with types and defaults, but the description doesn't explain what 'query' filters or how 'limit' affects results. This leaves parameters minimally documented, meeting the baseline for adequate but incomplete coverage.
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 the action ('List') and resource ('tags in the Zotero library'), making the purpose immediately understandable. It distinguishes this as a listing operation rather than creation or modification, which aligns with sibling tools like 'create_item' or 'update_item'. However, it doesn't specify if this lists all tags or filtered tags, leaving some ambiguity compared to siblings like '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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_items' that might also involve tags, nor does it specify prerequisites or contexts for usage. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
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 states the tool searches with filters but doesn't disclose behavioral traits such as pagination behavior (implied by 'limit' parameter), rate limits, authentication needs, or what happens with empty results. For a search tool with 5 parameters and no annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste—'Search items in Zotero library with optional filters'—front-loading the core action and key feature. Every word earns its place, making it appropriately sized and well-structured for quick comprehension.
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's moderate complexity (5 parameters, 1 required), no annotations, and an output schema (which handles return values), the description is incomplete. It covers the basic purpose but lacks details on usage context, behavioral traits, and parameter meanings. The output schema reduces the need to explain returns, but the description should do more to guide effective use.
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 schema provides no parameter details. The description adds minimal semantics by mentioning 'optional filters', which hints at parameters like 'collection_key', 'item_type', and 'tag', but doesn't explain their meanings, formats, or interactions. It doesn't compensate for the low coverage, resulting in a baseline score due to inadequate parameter clarification.
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 the verb ('search') and resource ('items in Zotero library'), making the purpose understandable. It distinguishes from siblings like 'get_item' (single item retrieval) and 'get_collection_items' (collection-specific retrieval) by emphasizing search with filters. However, it doesn't explicitly differentiate from 'find_duplicates' (which might also search) or specify search scope beyond 'library'.
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?
The description mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives like 'get_collection_items' (for items in a specific collection) or 'get_item' (for a known item). It lacks explicit when/when-not instructions or prerequisites, leaving usage context implied rather than stated.
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 the full burden of behavioral disclosure. It states the action ('List all collections') but doesn't mention any behavioral traits like pagination, rate limits, authentication requirements, or what the output contains (e.g., format, fields). This leaves significant gaps for an agent to understand how to interact with it effectively.
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, clear sentence with zero waste—it directly states the tool's purpose without fluff or repetition. It's front-loaded and efficiently communicates the core functionality, making it easy for an agent to parse quickly.
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's simplicity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It states what the tool does but lacks context on behavior and usage compared to siblings. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to cover that, but it still falls short in guiding the agent fully.
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?
The input schema has 0 parameters with 100% coverage, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for this case. A baseline of 4 is applied as it avoids unnecessary details while matching the schema's simplicity.
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 the verb ('List') and resource ('all collections in the Zotero library'), making the purpose immediately understandable. However, it doesn't distinguish itself from sibling tools like 'get_collection_items' or 'search_items' that also retrieve collection-related data, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_collection_items' (which retrieves items within a specific collection) and 'search_items' (which might filter collections), there's no indication of this tool's specific use case, such as for bulk retrieval without filtering.
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?
With no annotations provided, the description carries full burden. It mentions 'auto-fills metadata' which is useful behavioral context, but doesn't disclose other important traits like whether this is a write operation (implied by 'Create'), what happens on failure, permission requirements, rate limits, or what the created item contains. More behavioral details would help the agent.
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, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
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 creation tool with 3 parameters (1 required), 0% schema coverage, no annotations, but with an output schema, the description is minimally adequate. The output schema likely covers return values, but more guidance on parameter usage and behavioral context 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 schema provides no parameter descriptions. The description mentions 'DOI' which maps to the required 'doi' parameter, but doesn't explain the optional 'collections' or 'tags' parameters at all. It adds minimal value beyond what's inferable from parameter names.
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 ('Create a Zotero item'), the input source ('from a DOI'), and the key behavior ('auto-fills metadata'). It distinguishes itself from sibling tools like 'create_item' by specifying the DOI-based creation method.
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 usage when you have a DOI and want to create an item with auto-filled metadata, but it doesn't explicitly state when to use this versus alternatives like 'create_item' (manual entry) or 'import_bibtex' (BibTeX import). No exclusions or prerequisites are mentioned.
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 carries full burden. It discloses a key behavioral trait: the operation removes from collections but doesn't delete items, which is valuable context. However, it lacks details on permissions needed, error conditions, or what happens if the item isn't in the collection, leaving gaps in behavioral understanding.
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, efficient sentence with zero waste. It front-loads the core action and clarifies a critical distinction, making it highly concise and well-structured for quick comprehension.
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 an output schema (which handles return values) and no annotations, the description is moderately complete. It covers the primary purpose and a key behavioral nuance, but for a mutation tool with 0% schema coverage, it should ideally include more about parameter semantics or error handling to be fully adequate.
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%, so the description must compensate for undocumented parameters. It mentions 'item_key' and 'collection_key' implicitly but provides no semantic details (e.g., format, source, or examples). This adds minimal value beyond the schema's structural definition.
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 specific action ('Remove') and target ('a Zotero item from a collection'), while explicitly distinguishing it from sibling tools by noting it 'does not delete the item' (unlike delete_item). This provides precise verb+resource differentiation.
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 context by specifying it removes from collections without deleting items, which helps differentiate from delete_item. However, it doesn't explicitly state when to use this versus alternatives like update_item for other modifications or provide prerequisites for the item/collection keys.
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

Copy to your README.md:

[![zotero-mcp MCP server](https://glama.ai/mcp/servers/BirdInTheTree/zotero-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BirdInTheTree/zotero-mcp)

Score Badge

Copy to your README.md:

[![zotero-mcp MCP server](https://glama.ai/mcp/servers/BirdInTheTree/zotero-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BirdInTheTree/zotero-mcp)

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/BirdInTheTree/zotero-mcp'

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