zoty

by eric-tramel

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct operation: adding papers, retrieving citations, getting full metadata, listing recent items, collection browsing, and searching. Descriptions clearly differentiate similar functions like get_item vs search_library.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., add_paper, list_collections, search_library). Even longer names like get_bibtex_and_citation_for_items adhere to this convention.
Tool Count5/5
With 8 tools, the set is well-scoped for a Zotero reference management server. It covers essential operations without being overwhelming or too sparse.
Completeness3/5
Tools cover adding, retrieving, and searching, but lack update and delete functionality for items or collections. While core workflows are supported, notable lifecycle operations are missing.
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.5/5.
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
- Last stable release on May 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
The description only outlines the return format. It lacks disclosure of behavioral traits such as potential large response size, authentication requirements, rate limits, or any side effects. Since no annotations are provided, the description carries the full burden, which is not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, straight to the point, with no extraneous information. It front-loads the purpose and lists the return fields clearly.
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 covers the basic purpose and output for a simple list tool, it omits context about potential pagination, filtering, or scope (e.g., 'all collections' for the user). The presence of an output schema reduces some burden, but usage guidance is missing.
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 and 100% schema coverage, so no parameter documentation is needed. Baseline score 4 is appropriate per the scoring guide.
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 explicitly states 'List all Zotero collections' with specific fields (keys, names, item counts). It clearly distinguishes from sibling tools like list_collection_items (which lists items within a collection) and search_library (which searches across items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other listing/searching tools. The description does not mention prerequisites, alternatives, or scenarios where it is appropriate or inappropriate.
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 full burden for behavioral disclosure. It transparently explains the limit parameter behavior (capped at 25, limit=0 returns empty, response metadata for clamping). It also details the return structure including 'collection_found', 'total', 'returned_count', and item fields. This goes beyond minimal expectations.
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 well-structured with a one-line summary followed by 'Args:' and 'Returns:' sections. While it is somewhat lengthy, every sentence adds value (parameter behavior, return fields). The most important information is front-loaded in the first sentence. A minor improvement would be tightening some phrasing, but overall it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has only 2 parameters, the description is remarkably complete. It covers the purpose, parameter details, and a comprehensive list of return fields including limit metadata and item structure. It anticipates potential questions (e.g., what 'total' means, what happens with limit=0) and addresses them. No gaps are apparent.
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?
For 'collection_key', the description adds crucial context: 'The Zotero collection key (from list_collections)' – the input schema only specifies type string, so this tells the agent where to obtain the key. For 'limit', the description reinforces the schema's explanation and adds the example of limit=0 returning empty, which aids understanding. Despite 50% schema description coverage, the description compensates effectively.
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 begins with a clear, specific verb+resource statement: 'List items in a specific Zotero collection.' This unambiguously states the tool's action and scope. It also implicitly distinguishes from siblings like 'list_collections' (which lists collections, not items) and 'search_library' (which searches across 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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention that for items not belonging to a collection, 'search_library' would be appropriate, or that 'get_item' is for a single item. Usage context is only implied by the tool's purpose.
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, the description carries the full burden. It discloses clamping behavior for limit, metadata in responses, truncation of abstract to 500 chars, and return structure. However, it does not mention authentication requirements or what 'skipped items' refers to.
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 well-structured with Args and Returns sections, and the main purpose is front-loaded. Every sentence provides useful information, though it could be slightly more concise without losing detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and the detailed return description (acting as an output schema), the tool is well-covered. It explains limit behavior, return fields, and truncation. Missing: error conditions and authentication requirements, but these are not critical for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining default, capping, edge case for limit=0, and return metadata (requested_limit, applied_limit, etc.), which goes beyond the schema description.
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 'Get recently added items from the Zotero library, sorted by date added.' This is a specific verb-resource combination that distinguishes it from sibling tools like search_library or list_collection_items, which are for filtered or collection-specific retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (to get recent items) but does not explicitly mention alternatives or when NOT to use it. For example, it does not contrast with search_library for keyword-based retrieval or list_collection_items for collection-scoped queries.
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, the description fully discloses important behaviors: limit clamping at 25, response includes clamping indicators, return structure for single vs multi-item calls, attachment info without leaking local paths, and omission of redundant fields. No contradictions.
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 well-structured with a clear first sentence, an Args section, and detailed return info. While somewhat lengthy, every sentence provides value and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, rich return structure) and presence of output schema, the description covers all necessary aspects: parameter sources, limit behavior, and response format distinctions. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 add all parameter meaning. It explains `item_keys` as Zotero keys from specific sources, `query` as keywords for metadata and attachments, and `limit` with default and cap. This fully compensates for absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds passages within known items matching a keyword query, with specific verb 'find' and resource 'passages within items'. It distinguishes from sibling `search_library` by positioning itself as a drill-down 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 explicitly says to use after `search_library` to drill into one paper or compare across several papers, providing clear usage context. It lacks explicit when-not-to-use guidance but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the return format (JSON with citation, bibliography, BibTeX), batch behavior (always uses batch `items` shape), and typical usage. No contradictions.
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?
Well-structured with clear sections: overall purpose, Args list, Returns. Informative yet concise, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers arguments, key sources, style examples, and return format. Lacks discussion of error handling or limitations, but for a 4-parameter tool with no annotations, it is very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: explains where to get item keys, provides example values for style and locale, and clarifies that at least one key must be provided. Compensates for 50% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states tool gets BibTeX, citation, and bibliography for Zotero items. Verb 'Get' and specific resources are identified. Tool name itself is descriptive and distinguishes it from sibling tools like search_library.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires at least one of `item_key` or `item_keys`, explains how to obtain keys from other tools, and provides examples for style. While it doesn't explicitly contrast with alternatives, the specific purpose makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses response shape differences, deduplication, privacy-safe attachment metadata, and large creator list summarization. Lacks mention of authentication or rate limits but is otherwise transparent.
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?
Well-structured with clear sections for purpose, parameters, returns. Slightly lengthy but every sentence adds value. Front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, and description details return shapes for both single and multi-key requests. All important aspects (inputs, behavior, outputs) are covered. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The tool description fully explains item_key and item_keys, including how to obtain keys, combination rules, and deduplication. Adds significant meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full metadata for one Zotero item or a batch of items,' specifying the verb and resource. It distinguishes from sibling tools like search_library and get_recent_items, which are for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Search results already include most fields, so use this only when the full abstract or full attachment records are needed.' Also explains batch vs single behavior and deduplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral details: query interpretation, filters, limit clamping and special behavior at 0, attachment inclusion control, duplicate collapse, response structure, and warnings for invalid filters. This exceeds typical expectations.
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 long but well-structured with Args/Returns sections and front-loaded purpose. Minor redundancy (duplicate collapse mentioned twice) but every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still explains return fields (items, total, returned_count, warnings) comprehensively. It covers all parameter behaviors and edge cases, making it complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, but the description compensates thoroughly. It explains query semantics (BM25, example), collection_key purpose, item_type canonical values and fallback behavior, limit clamping and reporting, and include_attachments trade-offs. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find items in Zotero library matching a keyword query. It specifies BM25 ranking over title, abstract, and attachment full text, which distinguishes it from sibling tools like search_within_item that focus on a single item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on query format (e.g., 'transformer attention' not full questions) and explains duplicate handling. However, it does not explicitly contrast with sibling tools like search_within_item or list_collections, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: fetches metadata, creates item, downloads PDF, assigns to collection, requires Zotero running and zoty-bridge plugin. Describes return types (success, duplicate, error).
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?
Well-structured with summary, usage details, behavior, and parameter descriptions. Some repetition of information (e.g., precedence stated twice), but overall concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no annotations, the description covers usage, behavior, dependencies, and return values comprehensively. Missing only minor details like exact error format, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates thoroughly: explains each parameter, conditions (required unless), precedence, and provides examples. Adds meaning beyond schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'add', resource 'paper to Zotero', and method 'by arXiv ID or DOI'. Distinguishes from sibling tools (none add papers) and is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use each parameter: 'Provide at least one of arxiv_id or doi', explains precedence (arxiv_id takes priority), and notes optional collection_key. No sibling alternatives, but usage is clear.
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:

[![zoty MCP server](https://glama.ai/mcp/servers/eric-tramel/zoty/badges/card.svg)](https://glama.ai/mcp/servers/eric-tramel/zoty)

Score Badge

Copy to your README.md:

[![zoty MCP server](https://glama.ai/mcp/servers/eric-tramel/zoty/badges/score.svg)](https://glama.ai/mcp/servers/eric-tramel/zoty)

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/eric-tramel/zoty'

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