Zotero MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct functionality: local Zotero operations (get item, children, fulltext, list collections/tags, search) are separate from Semantic Scholar operations (search, related, citations, references). No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_item, list_collections, search_semantic_scholar). Although verbs vary (get, list, search, find), they accurately describe the action and maintain predictability.
Tool Count5/5
With 10 tools, the server is well-scoped for a Zotero integration that includes both local library retrieval and external paper discovery via Semantic Scholar. Each tool serves a distinct need without bloat or deficiency.
Completeness3/5
The tool surface covers extensive read operations for Zotero items, collections, tags, and full-text, plus comprehensive Semantic Scholar searches. However, it lacks CRUD operations (create, update, delete items) that are typical for library management, leaving notable gaps.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the return format (JSON with full item data) but does not discuss error handling, authentication requirements, or behavior when the key is not found. For a simple retrieval, this is adequate but has gaps.
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 short, front-loaded, and well-structured with Args and Returns sections. Every sentence serves a clear purpose.
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 no annotations, a single required parameter, and an output schema, the description covers core functionality. However, it lacks usage context relative to siblings and does not address edge cases, making it incomplete for a fully informed 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 coverage is 0%, so the description must compensate. It adds only 'The Zotero item key' for the 'key' parameter, which adds minimal meaning beyond the schema's property name. No format, examples, or constraints are provided.
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 a single Zotero item by its key', specifying the verb and resource. It distinguishes from sibling tools like 'find_related', 'get_children', and 'search', which have 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 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 its siblings. There is no mention of prerequisites, limitations, or alternative tools for similar tasks.
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 provided, so the description carries full burden. It states returns a JSON array of child items but does not disclose read-only nature, required authentication, error handling (e.g., invalid key), or rate limits. The description is minimal beyond basic function.
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?
Description is concise with two sentences plus Args/Returns sections. It front-loads the purpose and avoids fluff. The structure is clear and easy to scan. Minor improvement could be merging the first line with Args for even tighter format.
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?
Tool has one parameter and an output schema, and the description adequately covers input and output. For a simple get-child-items tool, this is sufficient. It does not mention error scenarios or prerequisites, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'key' is described as 'The Zotero item key,' which adds basic meaning beyond the schema's type-only definition. However, it lacks specifics such as format, source, or any constraints. With 0% schema coverage, the description partially compensates but could be more helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (get) and resource (child items) with parenthetical examples (attachments, notes) and specifies the scope (of a Zotero item). This distinguishes it from sibling tools like get_item or find_related which serve 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to retrieve child items of a Zotero item) but does not provide explicit guidance on alternatives or when not to use. For example, it does not contrast with get_item or list_collections. This is acceptable for a simple retrieval tool but lacks explicit differentiation.
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 exist, so the description must fully disclose behavior. It only states the return format (JSON array of tag strings) and does not address read-only nature, limits, or error handling.
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 with three short sentences, front-loading the main purpose, and contains no wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description covers the basics. It lacks details on behavior when no results or errors, but is largely sufficient given the simplicity.
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 explains the 'collection' parameter as an optional filter, adding meaning beyond the schema's empty title and default. However, with 0% schema coverage, more detail would be beneficial.
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 'List all tags in the Zotero library' with a specific verb and resource, and distinguishes from siblings like search or list_collections by focusing exclusively on tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by collection, providing basic context, but does not give explicit guidance on when to use this tool versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions default values, max limit, and return format (JSON with count and papers), but does not disclose error handling, rate limits, or side effects. This is adequate but not thorough.
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 highly concise with a clear structure: one-line purpose, then a bulleted args list, then return statement. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters (1 required), the presence of an output schema (mentioned), and no nested objects, the description covers purpose, parameter details, and return format sufficiently for an agent to use the tool correctly. Minor omissions like error handling or external dependencies do not significantly hinder understanding.
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 description coverage is 0%, but the description adds meaningful context for each parameter: DOI format implied, limit with max, min_citations as filter, check_library with behavior explanation. This compensates well for the missing 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 action ('Find papers referenced') and the resource ('by a given paper using Semantic Scholar'). It distinctly differentiates from siblings like get_citations (citations) and find_related (related papers).
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 explicit guidance on when to use this tool versus alternatives such as get_citations or find_related. It does not mention exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses return format (JSON array with fields) and limit behavior, but does not mention performance, auth, or side effects. Adequate 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?
Three clear sentences, front-loaded with purpose. Zero filler. Efficient and to the point.
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?
Simple tool with one param and output schema exists. Description covers core behavior. Sibling tools are distinct. Complete for this complexity level.
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?
Single parameter 'limit' has default 0 in schema but no description. Description adds 'Maximum number of collections to return (0 for all)', providing necessary meaning beyond schema type.
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 'List all collections in the local Zotero library' with a specific verb and resource. No ambiguity about what the tool does.
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 on when to use this tool vs siblings like get_children or search. No context for when to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses use of Semantic Scholar and return format (JSON with count and papers). But lacks details on rate limits, data freshness, pagination, or error behavior.
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?
Description is clear and well-structured with a brief summary followed by parameter list. No unnecessary text. Could be slightly more concise by integrating parameter descriptions, but still efficient.
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 no annotations and 0% schema coverage, description covers parameters and return type adequately. But missing behavioral context (rate limits, error handling) and fails to discuss usage alongside sibling tools. Not fully complete for a complex tool.
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%, so description compensates fully. Lists all parameters (doi, limit, min_citations, check_library) with clear explanation of each, including defaults and max for limit. Adds value 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?
Description states 'Find papers that cite a given paper using Semantic Scholar.' The verb 'find' and resource 'citing papers' are specific. Differentiates from siblings like get_references (citations vs references) and search_semantic_scholar (general 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?
Usage is implied: use when you need citations of a paper. No explicit when-not or alternatives mentioned. Lacks guidance on when to use this versus find_related, get_references, or search_semantic_scholar.
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 full burden. It discloses that the tool is a read-only search, returns JSON with specified fields, and explains each parameter's effect. However, it does not mention authentication, rate limits, error handling, or whether the API call modifies any state. The behavior is adequately inferred but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It starts with a clear one-line purpose, then lists parameters in Args with their descriptions, and ends with Returns. Every sentence adds value, with no repetition or unnecessary 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?
For a 7-parameter tool with no annotations and an output schema (described in text), the description covers all inputs and the output structure (count, total, papers list). It lacks details on error conditions, pagination (beyond 'max 100'), or API behavior under heavy load, but is sufficient for typical use.
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?
Despite 0% schema description coverage, the description thoroughly explains all 7 parameters: query, limit, year, open_access, sort, min_citations, and check_library. It provides meaning beyond the schema by clarifying formats (e.g., year filter '2020-2022'), options (sort by citations or year), and the purpose of check_library. This significantly aids correct usage.
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 'Search for papers on Semantic Scholar.' This is a specific verb (Search) and resource (papers on Semantic Scholar). It distinguishes from sibling tools like 'search' (likely local Zotero) and other paper-related tools (find_related, get_citations, etc.), as it explicitly names the external 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?
No guidance is given on when to use this tool versus alternatives. The description does not mention scenarios where this tool is preferred or when to avoid it. Sibling tools like 'search', 'get_citations', etc., are not referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions it uses Semantic Scholar (external API) and returns JSON, but does not disclose whether it requires authentication, rate limits, or potential side effects. It is adequate but not thorough for a no-annotation scenario.
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?
Description is concise and well-structured: one line for purpose, one line for method, then bulleted args and return. Every sentence is necessary and front-loaded with overall purpose.
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?
Has output schema and describes return format. Covers key aspects like parameters and method, but lacks details on error handling, rate limiting, or performance. Fairly complete for this complexity level.
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?
With 0% schema description coverage, the description compensates well by listing each parameter with clear explanations (doi, limit with default/max, min_citations, check_library with behavior). Adds significant meaning 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 finds papers related to a given paper using Semantic Scholar with SPECTER2 embeddings. It uses specific verbs and clearly identifies the resource, differentiating it from siblings like search and get_references.
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 for semantic similarity-based relatedness rather than citation-based, but does not explicitly state when to use vs alternatives or when not to use. Provides implied context but no exclusions.
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?
The description implies read-only behavior ('Get') and details the return fields (content, indexedPages, totalPages). With no annotations, this provides adequate behavioral context for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short lines: purpose, args, returns. Every sentence is necessary and front-loaded with the main action.
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 simplicity (one parameter, no nested objects, output schema exists), the description fully covers what the tool does, what input is needed, and what output to expect.
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?
The only parameter 'key' has no schema description (0% coverage), but the description compensates fully by stating it must be an attachment key, not a top-level item, adding crucial semantic meaning.
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: 'Get full-text content of a Zotero attachment.' It uses a strong verb and resource, distinguishing it from siblings like 'get_item' (metadata) and 'search' (query-based).
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 the key must be an attachment item, not a top-level item, providing clear when-to-use guidance. It does not name specific alternatives but implies correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes search behavior, full-text support, filtering, and pagination. It does not explicitly state read-only or side effects, but these are implicit for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, no fluff. Each sentence adds value. It is concise yet comprehensive.
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 7 diverse parameters and no required ones, the description provides complete documentation. It mentions return format (JSON with count and items). The output schema exists but is not shown; the description covers return structure sufficiently.
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%, so the description must compensate. It explains all 7 parameters with clear semantics, including defaults and usage examples (e.g., 'use || to combine types'). Adds significant meaning 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 starts with 'Search the local Zotero library', providing a clear verb and resource. It distinguishes from sibling tools like search_semantic_scholar (external search) and other specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details parameters and their usage, but does not explicitly state when to use this tool over alternatives. However, the mention of 'local Zotero library' implies context, and the comprehensive parameter descriptions guide usage.
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-server MCP server](https://glama.ai/mcp/servers/awsl5714/zotero-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/awsl5714/zotero-mcp-server)

Score Badge

Copy to your README.md:

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

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

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