zotero-comfort

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation2/5
Multiple search tools overlap: zotero_search, search_personal_library, search_group_library, zotero_semantic_search, and find_related_papers have unclear boundaries. Also zotero_semantic_search and find_related_papers both appear to provide similar-paper semantic search.
Naming Consistency3/5
Most names are snake_case and verb_noun, but prefix usage is inconsistent: zotero_* is mixed with bare search_* and action-style names like build_reading_list, smart_add_paper, and export_bibliography. Some near-duplicate functions have very different naming (zotero_semantic_search vs find_related_papers).
Tool Count4/5
17 tools is slightly above the typical well-scoped range, but the domain (search, collection management, external import, bibliography export, library configuration) justifies most of the surface. The extra weight comes from some redundant search variants rather than truly unnecessary tools.
Completeness3/5
The server covers searching, metadata, fulltext, collection listing, external imports, and export, but lacks essential library management operations such as updating or deleting items, creating/deleting collections, and tag management. Common Zotero workflows still have noticeble gaps.
Average 3.3/5 across 17 of 17 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 is failing
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only 'Build a curated reading list' and leaves unclear whether the tool searches external sources, modifies a Zotero library, creates a saved collection, or simply returns a temporary list. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is appropriately short, though the brevity contributes to the overall under-specification rather than being a structural problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too thin to be complete. It does not explain the data source, whether the reading list is saved anywhere, what the return value looks like, or how it relates to the many similar search-and-collection sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented by the input schema. The description itself does not add nuance about min_year or max_papers beyond what the schema provides, which matches the baseline for full schema 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 states a clear verb ('build') and resource ('curated reading list') scoped to a research topic, so an agent can identify the basic function. It does not explicitly differentiate from sibling tools like smart_add_paper or search_multi_source_to_collection, but the verb and object are specific enough to avoid being a tautology.
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 any of its many siblings, such as search_pubmed_to_collection, search_arxiv_to_collection, or smart_add_paper. There are no prerequisites, exclusions, or alternative conditions mentioned.
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 doesn't state whether the export is read-only, what the response looks like, whether it downloads a file, or what happens when neither parameter is supplied. For an export tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler and the action front-loaded. It is terse but not tautological; it conveys the verb, object, and output format efficiently.
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 tool is simple (2 optional params, no nested objects, no output schema), but the description doesn't explain the interaction between tag and collection_name or the behavior with no parameters provided. Adequate for basic selection, with clear gaps for invocation correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both tag and collection_name have inline descriptions in the schema. The tool description adds no parameter meaning beyond that, so the schema does the heavy lifting; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Export papers') and names the output format (BibTeX bibliography), which makes the tool's function clear. However, it doesn't explicitly differentiate from sibling tools like build_reading_list or search_personal_library beyond the format mention, so it stops short of full sibling differentiation.
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 given on when to use this tool versus alternatives such as zotero_search, zotero_get_metadata, or build_reading_list. The description implies use for bibliography export but provides no exclusions, prerequisites, or context for 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?
With no annotations provided, the description bears the full burden of behavioral disclosure, yet it only states the basic action. It does not reveal that the tool writes to the user's Zotero library, that it can add up to max_results_per_source items per source, or how duplicate results across sources are handled. The meaning of 'combine' and any side effects are left unstated.
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 well-ordered sentence with no filler: the verb 'Search' is front-loaded, and each phrase carries meaning (sources, outcome, destination). It is as compact as a correct description can be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, the description must carry substantial load but does not. It omits when to prefer this over single-source siblings, the write/side-effect profile on Zotero, and how combined results behave. An agent needs more than this one sentence to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters and the baseline is 3. The description only echoes what the schema states ('multiple sources' maps to sources, 'Zotero collection' maps to collection_name) without adding deeper detail about formats, constraints, or parameter interactions.
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 states a specific verb ('Search'), names both concrete sources ('PubMed, arXiv'), and specifies the resulting action ('combine results in a Zotero collection'). It is clear and actionable, and the 'multiple sources' phrasing implicitly distinguishes it from single-source siblings like search_pubmed_to_collection, but that differentiation is not made explicit.
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 offers no guidance on when to use this tool versus the closely related single-source siblings search_pubmed_to_collection, search_arxiv_to_collection, or the general zotero_search. An agent must infer the selection criteria entirely from sibling names and the schema, with no stated conditions 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 must carry the full behavioral disclosure burden. It only states the outcome and does not mention what happens when no full text is available, whether it extracts from PDFs, or what format the returned content takes.
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 one concise sentence with no filler. The primary action and object are front-loaded, and the brevity is appropriate for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter, the description should explain what the returned full text looks like and how missing content is handled. It does neither, leaving an incomplete picture for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter already has a basic description ('Zotero item key'). The tool description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action (Get) and resource (full text content of a paper), making the purpose clear and broadly distinguishable from sibling tools like zotero_get_metadata. It does not explicitly differentiate itself from siblings, but the core object is specific enough.
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?
There is no guidance on when to use this tool versus alternatives such as zotero_get_metadata or zotero_search. The description provides no usage context, prerequisites, or exclusions, leaving the agent to infer when it should be selected.
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 only says the search is 'AI-powered' and 'semantic' but does not explain how results are ranked, whether it searches the user's Zotero library, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but 'AI-powered' is filler that does not add actionable information. It is concise yet under-specified, and it lacks structured details that would help an agent use the tool confidently.
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 tool is simple with only two parameters and a fully documented schema, so the description does not need extensive detail. However, without an output schema or annotations, the description should at least clarify the search source and result behavior; it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'query' and 'limit' already documented in the input schema. The description adds only the notion of semantic similarity, which is marginal beyond what the schema already conveys.
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 names a specific action ('search') and a resource ('papers'), and adds the qualifier 'semantic' to distinguish it from a plain keyword search like zotero_search. It is not a tautology and communicates the core function, though 'similar papers' is slightly ambiguous about the input source.
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?
There is no guidance on when to prefer this tool over zotero_search, find_related_papers, or search_personal_library. No exclusions or alternative selection criteria are provided, so an agent must infer use cases from the name alone.
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. It implies a read-only 'get' operation but does not disclose pagination, whether subcollections are included, what fields are returned, or how empty results are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the core operation. It earns its place without redundancy, though it could add useful detail without losing 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?
For a simple one-parameter read tool, the description captures the essential operation. However, it omits how collection_key is obtained, what the response looks like, and any limitations such as pagination or item-type handling. With no output schema and no annotations, the agent is left with some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because collection_key has a description ('Collection key'), so baseline 3 applies. The description itself adds no parameter meaning beyond the schema, and the schema's parameter documentation is terse.
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 states a clear action ('Get') and resource ('all items in a specific collection'), making the tool's purpose obvious. It is specific enough to distinguish from sibling tools like zotero_list_collections, though it does not explicitly name alternatives.
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 zotero_search or zotero_list_collections. There is no mention of prerequisites such as obtaining a collection_key from zotero_list_collections, nor any exclusions or alternative routing.
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 the burden of behavioral disclosure, but it only says 'search'. It does not state whether the search covers metadata, full text, or both; what ranking/pagination behavior to expect; or any auth/scope constraints.
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?
A single, front-loaded sentence with no filler. The wording is compact and direct, though it is also quite minimal in the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search with a documented schema, this is minimally viable. However, with no output schema and no description of return format or search behavior, an agent is left guessing about what the tool actually returns and how matches are determined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents query and limit. The description adds minor context by clarifying that the query is scoped to the personal library, but adds little 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 states the tool searches papers in the user's personal library, making the verb and resource clear. It is somewhat distinguishable from search_group_library by the word 'personal', but it does not explicitly differentiate from zotero_search or zotero_semantic_search.
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 phrase 'in your personal library' implies this is for querying a user's own collection rather than external sources or group libraries. However, it gives no explicit guidance on when to prefer this over the many sibling search tools, nor any 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 behavioral burden. It only says the search is semantic and does not clarify whether the tool is read-only, whether it searches the user's library or an external corpus, or what the returned related papers actually contain. The verb 'Find' implies no mutation, but other behavioral traits are left undisclosed.
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 focused sentence with no filler, front-loaded with the action. Every word contributes to the core meaning. This is appropriately concise for a two-parameter tool.
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 schema fully covers both parameters, so invoking the tool is straightforward. However, there is no output schema and no statement about the search scope, relation criteria, or return format. The agent can call the tool, but some ambiguity remains about what it will receive.
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 schema description coverage is 100%, so both item_key and limit are already documented. The description just rephrases item_key as 'a given paper' and adds no extra constraints, format details, or interaction between limit and results. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Find'), a specific resource ('papers related to a given paper'), and a method ('semantic search'). The required item_key makes it inferable that this is paper-to-paper relatedness rather than query search, but it does not explicitly contrast it with zotero_semantic_search.
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 phrase 'related to a given paper' implies that the tool should be used when the agent already has a Zotero paper key and wants connected papers. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling tool is named.
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 available, the description carries the full burden of disclosing behavior, but it only states the basic action. It does not mention side effects like creating a collection if it doesn't exist, any duplicate handling, behavior with max_results, or what happens on partial failure — important for a tool that writes to an external system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise and easy to parse, though it omits behavioral details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations, yet the description only provides a high-level summary. It does not explain return behavior, side effects, default collection creation, or interaction with the Zotero library, so an agent would need to rely on the schema and guess about runtime behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents query, max_results, collection_name, and create_collection with helpful descriptions and defaults. The description adds no extra parameter meaning, but it does not need to since the schema is sufficient.
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 states a specific action ('Search arXiv') and a clear destination effect ('add results to a Zotero collection'), making the tool's purpose immediately identifiable. It also distinguishes itself from siblings like search_pubmed_to_collection by explicitly naming arXiv as the source.
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 the tool should be used when the agent needs to find arXiv papers and place them into a Zotero collection. However, it provides no explicit guidance about when not to use it or which sibling alternative to prefer, such as search_pubmed_to_collection or zotero_search.
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 bears the full burden of disclosing side effects. 'Set' clearly signals mutation, but the description does not say whether the default persists across sessions, affects all later operations, requires authorization, or has a confirmation/return value. This is a meaningful gap for a state-changing 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 front-loaded sentence with no filler or redundancy. It communicates the essential action immediately and every word earns its place.
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 one-parameter setter with a fully documented enum, this description is minimally viable: an agent knows what to call and with what value. However, with no annotations or output schema, the lack of persistence/side-effect information and any guidance on how the returned state is reported leaves the context incomplete for confident 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?
The input schema fully documents the single parameter, including the enum values 'group' and 'personal' and a description for 'library'. The tool description adds no parameter detail, but with 100% schema coverage the baseline of 3 is appropriate; nothing extra is needed.
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 names a specific action ('Set') and resource ('default library'), making the tool's purpose clear. It is distinct from the search/list sibling tools, though it does not explicitly contrast itself with them. It is slightly generic in not defining which 'operations' are affected, but the core function 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when the user wants to establish a persistent default, contrasting implicitly with siblings like search_personal_library or search_group_library. However, it gives no explicit when-to-use instructions, prerequisites, or alternatives, leaving the agent to infer placement.
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 only restates the basic effect ('Get detailed metadata') and adds no details about what metadata is included, whether the item must exist, error behavior, or access requirements. The word 'Get' hints at a read-only operation, but little else is disclosed.
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 short sentence with no filler or redundancy. It is front-loaded with the action and object, making it easy to parse quickly. Given the tool's simplicity, this level of conciseness is appropriate.
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?
This is a simple one-parameter read tool, and the description names the core purpose. However, there is no output schema, so the description should clarify what 'detailed metadata' means or what fields the agent can expect, and it does not. The gaps are minor but present for a tool with no annotations or output schema.
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 fully documents the only parameter (item_key as 'Zotero item key'), so schema coverage is 100% and the baseline of 3 applies. The description adds no additional parameter meaning, but that is acceptable because the schema already provides sufficient semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed metadata for a specific paper'), making the tool's function immediately clear. It also distinguishes it from sibling tools like zotero_search, zotero_get_fulltext, and zotero_list_collections by focusing on metadata retrieval for one known 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 explicit guidance is given about when to use this tool versus alternatives, nor are any exclusions or sibling comparisons mentioned. The phrasing 'for a specific paper' implies use when an item key is known, but an agent is not told when to prefer this over zotero_search or zotero_get_fulltext.
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 behavioral disclosure burden. It indicates a read-style search operation but does not clarify whether the search covers metadata only, whether full text is included, what item types are searched, or whether any authentication or local Zotero instance is required. This is a meaningful gap given sibling tools like zotero_get_fulltext.
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, well-structured sentence that immediately conveys the tool's core purpose. No extraneous words or redundant schema details are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool, the description is mostly sufficient, but it omits important scoping details such as whether it searches the default library only versus group libraries, and how it differs from search_personal_library or search_group_library. The absence of an output schema and annotations raises the need for a bit more context than provided.
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 already documents both parameters (query and limit) with 100% coverage, so the description does not need to add much. It reinforces that query is a keyword, but it does not add details about limit behavior or query formatting beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('Zotero library'), and the method ('by keyword'). It is distinct from semantic search in intent, but it does not explicitly name or differentiate from sibling tools like zotero_semantic_search or search_personal_library.
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 phrase 'by keyword' implies this is the right tool for keyword-based lookups rather than semantic search, but the description gives no explicit when-to-use, when-not-to-use, or alternative recommendations. The guidance is 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the key side effect ('add results'), which signals a write to Zotero, and no annotations are present. It does not disclose details like collection creation, duplicate handling, or rate limits, but the schema covers creation behavior via create_collection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler and front-loads the main action. It is concise but slightly underspecified for usage context.
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 moderate-complexity tool with no output schema and no annotations, the description plus full parameter schema is mostly sufficient to call it. It lacks sibling differentiation and behavioral caveats, but the core operation is adequately conveyed.
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?
Input schema covers 100% of parameters with descriptions, so the description needs to add little. The description aligns with query and collection_name, but adds no semantics 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 uses a specific verb ('search') and resource ('PubMed') and specifies the destination ('a Zotero collection'), making the operation clear. It does not explicitly distinguish from sibling tools like search_arxiv_to_collection or search_multi_source_to_collection, so it stops short of full differentiation.
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 implied use case is evident: when a user wants PubMed results added to a Zotero collection. However, the description provides no explicit when-to-use guidance, no exclusions, and no mention of alternative sibling tools for Arxiv or multi-source searches.
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 the full behavioral disclosure burden. The verb 'Get' implies a read-only status check and does not suggest mutation, but the description does not explicitly state side-effect-free behavior or clarify what 'status' includes, which is a moderate 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?
The description is a single, front-loaded sentence with no filler or redundant wording. Every word earns its place, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only status tool, the description is mostly complete: it names the resource and scope. However, it does not describe what status information is returned or any prerequisites, which would help but is not critical given the low complexity.
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 tool has zero parameters, so parameter semantics are trivially satisfied. The description does not need to explain parameter meaning, and the baseline of 4 applies.
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 ('Get') and the resource ('status of configured libraries'), and the parenthetical '(group and personal)' adds useful scope. It is clear about what the tool does, though it does not explicitly differentiate itself from sibling tools by naming alternatives.
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?
There is no guidance on when to use this tool versus siblings like set_default_library, search_group_library, or zotero_list_collections. The description only states what the tool does, leaving the agent to infer when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, but it only says 'List all collections', which conveys a read-only listing and an 'all' scope. It does not disclose whether nested collections are included, how results are returned, or that it operates on the current/default library.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no repetition, filler, or redundant detail. The key action and resource are front-loaded.
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 zero-parameter, low-complexity tool, the description is mostly complete for selecting and invoking the call. It leaves minor gaps around library scope and return shape, but no parameters or output schema are present to contradict or complicate the basic behavior.
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 zero parameters, so there is no parameter semantics for the description to add; the rule for zero-parameter tools sets a baseline of 4. No additional parameter guidance is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('List') with a clear resource ('all collections in the Zotero library'), making the operation unambiguous. It also distinguishes itself from sibling tools that operate on items, metadata, or search rather than listing collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as zotero_get_collection_items or zotero_search. The description only states what it does, leaving the agent to infer selection context from the name.
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?
There are no annotations, so the description must carry the behavioral bur. 'Search for papers' signals a read-only lookup, but it does not clarify what fields are searched, whether full text is included, or what the response shape is. Some transparency, but not rich.
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, front-loaded sentence with no filler. Every word contributes to the purpose and scope. It is appropriately sized for a simple search operation.
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 low-complexity tool with two well-documented parameters and no output schema, the description gives the essential scope and action. It could improve by naming the alternative for personal-library search or noting what the result contains, but it is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (query and limit) are fully documented in the schema, including the default for limit. The description adds no parameter-level detail, but the schema already provides complete coverage, so the baseline of 3 is appropriate.
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 states a specific verb ('Search') and identifies the exact resource scope ('group (shared team) library'). This makes the purpose unmistakable and distinguishes it from sibling like search_personal_library by naming the group context.
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 clearly establishes the use case: search within the shared team library, not the personal library. It doesn't explicitly name alternatives or when-not conditions, but the scope is concrete enough for an agent to select it appropriately.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly explains the non-destructive probe mode, the write mode, and the duplicate-handling behavior of attaching to an existing collection instead of creating a duplicate. It does not detail return values or error cases, but the critical behaviors are transparent.
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 compact and front-loaded with the primary purpose. The second sentence earns its place by explaining the crucial behavioral distinction between the two modes. There is no filler or redundant repetition of schema details.
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 covers the core decision an agent needs: when the tool will write, when it will not, and how duplicates are handled. Since there is no output schema, a bit more return-value detail for the probe mode would improve completeness, but the key usage context is well covered.
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 coverage is 100%, so the schema already documents all parameters. The description adds meaningful conditional semantics for collection_name (probe vs. actual write) and clarifies that tags are applied to newly created items, going beyond simple 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 a specific action ('Add paper from DOI') on a specific resource and describes its main behaviors: duplicate checking and optional collection/tag assignment. The conditional dual-mode behavior further distinguishes it from sibling search-and-add tools, so an agent can tell this is the DOI-based add tool.
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 gives clear context for when the tool writes versus when it acts as a probe: without collection_name it is a dedup/metadata probe, and with collection_name it fetches from Crossref and writes to Zotero. It does not explicitly name sibling alternatives or state exclusions, but the conditional guidance is strong enough for correct selection.
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-comfort MCP server](https://glama.ai/mcp/servers/BIH-CEI/zotero-comfort/badges/card.svg)](https://glama.ai/mcp/servers/BIH-CEI/zotero-comfort)

Score Badge

Copy to your README.md:

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

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/BIH-CEI/zotero-comfort'

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