Zoteus

Server Quality Checklist

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

Latest release: v1.4.2
Disambiguation3/5
Most tools have distinct purposes, but several pairs overlap: zotero_fulltext vs zotero_get_fulltext (indexing vs retrieval), zotero_bibliography vs zotero_format_bibliography (library items vs arbitrary), and zotero_search_items vs zotero_semantic_search vs zotero_scholar all involve search but target different scopes. Descriptions mitigate confusion with cross-references, but an agent may still misselect without careful reading.
Naming Consistency4/5
The vast majority follow a consistent zotero_verb_noun pattern (e.g., create_items, update_item, search_items). There are minor deviations: one tool lacks the prefix (search_tools), and the pair zotero_fulltext/zotero_get_fulltext disrupts the verb pattern. Overall predictable but not perfectly uniform.
Tool Count3/5
With 30 tools, this is on the heavy side for an MCP server, though the Zotero domain is broad and each tool covers a specific function. Some could be consolidated (e.g., list_tags/manage_tags, list_collections/manage_collections), but the count is justified by the breadth of features.
Completeness4/5
The surface covers CRUD for items, collections, tags, attachments, annotations, import/export, bibliography formatting, full-text, semantic search, sync, and index management. Minor gaps exist—saved searches cannot be updated (only created/deleted)—and batch updates are limited to create_items. Overall, no critical dead ends for core workflows.
Average 4.6/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 8 community issues answered or closed in the last 6 months
- 81 commits in the last 12 weeks
- Last stable release on August 19, 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true. The description adds that it enumerates via the cloud Web API, reports off-taxonomy tags, and handles required tiers. No contradictions found.
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 paragraph of five sentences, covering purpose, input format, output, and read-only nature. It is mostly concise and front-loaded, though slightly verbose in explaining reports.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description adequately explains what the tool does and what reports it produces. Annotations support completeness. Minor gaps remain in output structure details.
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 low (43%), but the description adds meaning for key parameters like `vocabulary` (inline example) and `include_auto`. However, parameters like `limit`, `library_id`, `library_type`, and `vocabulary_path` are not explained in the description, limiting full compensation.
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 audits tags against a controlled vocabulary with priority tiers, distinguishing it from tag listing or management tools. It specifies three types of reports, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for auditing tags), including the types of reports generated. It does not explicitly mention when not to use it or provide alternatives, but the context is clear enough for an AI agent.
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?
Annotations already declare readOnlyHint=true; the description adds details about returned data (usage count, auto-applied flag) and that it works in read-only mode, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundancy: purpose, param mention, and sibling differentiation. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields. However, missing param descriptions for library_id and library_type reduce completeness; overall adequate but with gaps.
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?
Only 2 of 4 parameters (q, limit) are mentioned in the description; library_id and library_type are undocumented. With 50% schema coverage, the description should compensate but does not, leaving key params unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tags with usage count and auto-applied status, and distinguishes it from siblings like zotero_manage_tags (write) and zotero_tag_audit (hygiene).
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 describes read-only availability, contrasts with zotero_manage_tags for writing, and suggests zotero_tag_audit for taxonomy hygiene, providing clear when-to-use and when-not-to-use guidance.
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 adds behavioral details beyond the annotations: it states this is a read operation via the cloud Web API, consistent with readOnlyHint=true. It describes the return structure (map of keys→version per object type, deletion log) and that it follows the Zotero sync algorithm. No contradictions with annotations.
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 concise at four sentences, each earning its place. It is front-loaded with the purpose, then explains the key parameter, return structure, and usage guidance. No fluff or 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?
For a tool with 5 parameters and no output schema, the description adequately covers purpose, usage, return structure, and complementary tools. It lacks error handling details but provides enough context for an AI agent to use it effectively.
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 60%, baseline is 3. The description adds meaning for 'since' (0 = everything) and implies types. However, it does not explain 'library_id', 'library_type', or 'include_deleted' beyond what the schema provides. Some value added, but incomplete for undocumented parameters.
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 returns what changed in a library since a given version for efficient incremental sync. It uses specific verbs ('Return what changed') and distinguishes itself from sibling tools like zotero_get_item and zotero_search_items by positioning as the delta mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for efficient incremental sync. It explains the key parameter 'since' and what to do with the results (fetch changed keys, then pull only those with other tools). It does not explicitly state when not to use or list alternatives, but the usage context is well-defined.
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?
Annotations only provide readOnlyHint=false and openWorldHint=true. The description adds crucial behavioral details: file bytes are read/written to disk (not streamed), and operations use cloud Web API and consume storage quota. This goes beyond annotations.
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 focused paragraph with front-loaded purpose and action breakdown. It is concise but could benefit from bullet-point structure for the three actions to improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 3 actions, no output schema), the description covers action behaviors, key parameter roles, and file handling. Return values are mentioned for upload and download but not explicitly for info, which is a minor gap.
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 only 44% schema description coverage, the description compensates well by explaining which parameters apply to which action (e.g., parent_item for upload, item_key for download/info) and their roles. It adds meaning beyond the bare 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 handles attachment files with three specific actions: upload, download, and info. It uses specific verbs and distinguishes itself from sibling tools like zotero_get_item and zotero_fulltext by focusing on file operations.
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 explains each action's purpose and associated parameters, providing clear context for when to use each. It does not explicitly compare to sibling tools, but the action-oriented structure and mention of alternatives are sufficient.
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?
Annotations already declare readOnlyHint and openWorldHint. Description adds that it's available in read-only mode and contrasts with the write sibling. No contradictions, but lacks mention of pagination or empty library behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, zero wasted words. Efficiently covers main points.
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 simple list operation, description is nearly complete: purpose, usage, sibling differentiation, and returned fields. Lacks parameter details for library_id and library_type, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%, only 'top' described). Description does not add meaning for library_id or library_type, leaving them unexplained. With low coverage, description should compensate.
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 specific verbs ('list') and resource ('collections'), lists returned fields, and distinguishes from sibling zotero_manage_collections by noting it's read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (listing, read-only mode) and when not to (for writing, use zotero_manage_collections). Also provides downstream usage of keys for other tools.
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?
Description discloses that writes go to the cloud Web API, consistent with readOnlyHint=false. It does not mention rate limits or error states, but the three actions (list, create, delete) are clearly described. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and critical caveat. Every sentence provides value, no repetition or filler. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists; description does not mention return values for list/create/delete. Given 6 parameters and nested conditions, some description of expected output would improve completeness, especially for 'list' action.
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 50% (3 of 6 parameters described). The description adds context for conditions format and which parameters are needed per action, but does not explain library_id or library_type. Partially compensates for coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists, creates, or deletes saved-search definitions, with specific actions and prerequisites. It distinguishes itself from sibling tool zotero_search_items by explaining that this tool only manages definitions, not executes queries.
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?
Provides explicit guidance on when to use this tool versus alternatives: mentions that the Zotero cloud Web API does not execute searches, directing users to zotero_search_items for actual matching results, and suggests desktop local API as alternative.
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?
Annotations already indicate readOnly and openWorld. Description adds that the tool verifies fetchability, resolves dependent styles to independent parent, and accepts any CSL repository id. 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?
Two sentences, front-loaded with main purpose. Second sentence is somewhat dense but still readable. No unnecessary 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?
Covers both actions, input examples, output usage, and automatic resolution of dependent styles. Lacks mention of error handling for unresolvable names, but overall adequate given no output schema.
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?
Adds examples of style names (APA 7th, IEEE, etc.) and explains the output usage (pass styleId to other tools). The schema had 50% coverage; description compensates well by giving context beyond property 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?
Description clearly states the tool resolves human citation-style names to CSL ids or lists aliases, with specific actions. It distinguishes from siblings by mentioning its output is used by other formatting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use each action (resolve vs. list), and tells the agent to pass the returned styleId to other tools. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that 'set' performs a write via the cloud Web API and describes the three modes. Annotations show readOnlyHint=false and openWorldHint=true, which align with the description. No contradictions, but could mention if setting overwrites existing text.
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, front-loading the crucial 'not a search' disclaimer, then clearly enumerating the three actions with brief, informative bullet points. No unnecessary sentences.
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 tool with 10 parameters and no output schema, the description adequately explains the core functionality and return types (text content, stats, map of keys). However, it does not specify the response format for 'set' or detail the exact structure of returned data.
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 low (30%), but the description adds meaning by explaining the roles of 'action', 'content', 'item_key', and 'version'. However, it does not explicitly map all parameters (e.g., total_chars, indexed_chars) to their usage, leaving some ambiguity.
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 reads, sets, or tracks full text for an attachment item by key. It immediately distinguishes from search, making the purpose precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when NOT to use (for search, use zotero_search_items) and clarifies that only attachment items support full text. Provides clear context for each action (get, set, since).
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?
Annotations already mark readOnlyHint=true, so the description adds value by explaining the progressive disclosure pattern and behavior with no query (returns full catalog). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence serves a clear function: purpose, use case, parameter explanation, and result description.
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 no output schema, the description explains that it returns matching zotero_* tools. Could be slightly more explicit about the structure of returned data (e.g., tool definitions), but sufficient for an agent to understand usage.
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 100%, but the description adds meaning beyond schema: explains that query matches against 'tool names, titles, and descriptions', and clarifies detail default and output difference ('descriptions' vs '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 it discovers Zotero tools by keyword, using specific verb 'Discover' and resource 'Zotero tools'. It distinguishes from siblings like zotero_schema or action tools by focusing on tool discovery itself.
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 explicit context: 'useful for progressive disclosure when you do not want to load every tool definition up front'. It does not explicitly say when not to use, but the use case is clear and well-motivated.
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 adds behavioral context beyond annotations (readOnlyHint, openWorldHint) by specifying that it lists what the API key can access, and it enumerates the fields returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Every sentence adds value: first explains what the tool does, second explains how to use the output. Efficient and front-loaded.
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?
For a read-only list operation with no parameters and no output schema, the description is complete: it states what is returned and how to use the results. No gaps.
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 no parameters (schema coverage 100%), so the description is not required to explain parameters. Baseline for 0 parameters is 4, and the description meets that.
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 it lists group libraries accessible by the current API key, with specific fields (id, name, type, item count, edit permissions). It distinguishes from sibling tools like zotero_whoami (user info) and zotero_search_items (search items) by focusing on groups and their usage.
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 explains how to use returned group ids with other tools via parameters, and mentions the requirement for a cloud API key. It provides clear context for use but does not explicitly state when not to use it or list alternatives.
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?
Annotations indicate readOnlyHint=false (writes) and openWorldHint=true. The description adds context: 'All actions except 'list' write to the cloud Web API.' It also explains the side effect of add_items/remove_items modifying membership. No contradiction with annotations. Full disclosure of write 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?
The description is well-structured with action summaries, but it is somewhat lengthy. It front-loads the list of actions and provides necessary details. Could be slightly more concise, but the information density is high and easy to parse.
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 tool with 7 parameters and 7 actions, the description covers the core behaviors well. It mentions that 'list' returns keys/names/parent but does not specify the exact format. No output schema exists, so return values are implied but not fully detailed. Still, it is mostly complete for agent usage.
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 57%, but the description compensates by explaining the action enum in detail, clarifying when each parameter is needed (e.g., collection_key for rename, delete, etc.), and adding meaning like 'omit for top-level' for parent_collection. 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 can list, create, rename, reparent, delete collections, and move items. It distinguishes itself from siblings like zotero_list_collections by covering all these actions. The verb 'manage' plus the list of actions makes the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for each action (e.g., 'create' needs name, optional parent_collection). It implies when to use each sub-operation but does not explicitly say when not to use this tool in favor of siblings like zotero_list_collections. However, the action list itself effectively directs 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?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds behavioral context by specifying return values (schema version, item type list, fields, creator types) and that the primary creator type is listed first. 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?
Three sentences, all front-loaded with the main purpose. Each sentence adds value without redundancy. Very efficient.
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?
For a read-only schema tool with one optional parameter and no output schema, the description is complete. It explains both modes of operation and provides usage advice, leaving no gaps.
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% with a clear description for the only parameter item_type. The description adds meaning: 'the primary creator type is listed first' and clarifies that certain item types bypass the normal model, which is not in 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: 'Return the Zotero data model so you never hardcode item shapes.' It explains behavior with and without arguments, and distinguishes itself from sibling tools by being the only schema-related 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?
It advises to use this to 'validate an item before creating or updating it' and notes that notes, attachments, and annotations are item types but 'bypass the normal field/creator model.' This provides clear context for when to use the tool, though it doesn't explicitly exclude alternatives.
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?
Annotations already indicate readOnlyHint=false, and the description adds valuable behavioral detail: delete 'trashes' annotations, writes go to the running Zotero desktop app via connector protocol or local API, and highlights require a position to render. This goes beyond the annotation metadata without contradicting it.
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 front-loaded with a clear overview, then efficiently covers action-specific behavior, position requirements, and write targets. Every sentence adds useful operational detail without fluff, and the structure mirrors the tool's action-based usage.
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?
For a complex tool with six parameters, nested annotation objects, and no output schema, the description covers the essential usage paths: add with required parent/annotations, delete with annotation_keys, position semantics, and write destination. Remaining parameters like library_id and tags are documented in the schema, so the description is sufficiently 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?
The description adds substantial meaning beyond the schema: it explains that action:'add' needs parent and annotations, defines the exact highlighted passage requirement, specifies the position format with PDF points and bottom-left origin, and clarifies that without a position highlights cannot render. This compensates for the 67% 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?
The description opens with a specific verb and resource: 'Add or delete Zototero PDF annotations (highlights, underlines, notes)' and explicitly ties them to the same objects created in the Zotero PDF reader. This clearly distinguishes the tool from siblings like zotero_attachment or zotero_attach_file.
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 to use the tool: for adding or deleting PDF annotations with add/delete actions. It explains the write target (desktop app vs cloud Web API) but does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
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 annotations only indicating not read-only and open-world, the description discloses all-or-nothing schema validation, no partial writes on invalid items, server-side chunking into groups of 50, cloud Web API writes, and ZOTERO_API_KEY requirement. This substantially exceeds annotation information and does not contradict it.
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 dense but well-structured, front-loading the core purpose and batching fact, then item-data semantics, update/create rules, validation behavior, and auth requirement. The example JSON is compact and directly illustrates the format without unnecessary prose.
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 batch create/update tool with no output schema, the description covers purpose, data shapes, update semantics, validation, batching, and auth. Minor gaps remain: return/response shape beyond 'problems are returned' and how library_id/library_type affect the target library are not addressed.
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 `items` parameter is richly described: itemType as plain string, creator/tag/collection shapes, update key/version semantics, and validation. However, `library_id` and `library_type` are not explained in the description, and schema description coverage is only 33%, so the parameter semantics are incomplete despite strong coverage of the main parameter.
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 opens with a specific action: 'Create new items or update existing ones in a single batch,' naming the resource (Zotero items), operation (create/update), and batching scope. This clearly differentiates it from single-item siblings such as zotero_update_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit create-vs-update rules: include `key` and current `version` to update, omit both to create. It also points to zotero_schema for valid fields/creator types, but does not explicitly contrast this batch tool with zotero_update_item or state when to prefer one over the other.
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?
Annotations already provide readOnlyHint and openWorldHint, and the description adds context by stating 'no Zotero library write required' and mentioning it uses citeproc-js, which is client-side rendering. 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?
The description is a single, well-structured paragraph of three sentences. It is front-loaded with the main purpose, covers all key aspects without redundancy, and is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's seven parameters and no output schema, the description is quite complete. It explains input methods, main parameters, defaults, and comparison with a sibling. It could mention return format more explicitly, but it's sufficient.
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 71%, and the description adds value by explaining the two input methods (items vs item_keys) with examples, and noting values like style='APA 7th' and default values. It goes beyond the schema definitions.
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 'Render a formatted bibliography in any CSL style' and explicitly distinguishes from the sibling tool zotero_bibliography by noting 'no Zotero library write required' and mentioning the alternative for library items.
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?
The description provides explicit guidance on when to use this tool vs the sibling: 'Use this for arbitrary items or styles; for items already in the library you can also use zotero_bibliography.' It also explains the two input methods (items vs item_keys).
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?
The description provides extensive behavioral details beyond annotations: it explains the save-to-library flow, desktop vs cloud handling, fallback to OpenAlex/Crossref and arXiv API, and the 'source' field in the result. It fully discloses the mutation and optional saving behavior, complementing the readOnlyHint:false annotation.
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, well-structured paragraph that front-loads the core purpose and then flows into action specifics, saving behavior, and fallback logic. Every sentence adds useful detail without unnecessary fluff.
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?
The description is exceptionally complete for a tool of this complexity: it covers all main usage scenarios, environmental dependencies, and output characteristics. With no output schema, it clearly explains the source field and fallback behavior, leaving minimal ambiguity.
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 description adds significant meaning for key parameters (action, identifier, url, save_to_library, collection_key, attach_url) beyond the schema. With 67% schema description coverage, the description compensates well for the gaps, though library_id and library_type remain under-specified.
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: resolving bibliographic metadata to Zotero item-data with optional saving. It distinguishes between 'by_identifier' and 'by_url' actions, making it distinct from sibling tools like zotero_create_items.
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 explains when to use each action and the conditions for different fallback paths. It clearly specifies when a translation-server is required and mentions the API key for cloud fallback. However, it doesn't explicitly contrast with sibling tools like zotero_create_items, though the purpose is clear.
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?
Discloses retry logic, behavior with un-indexed PDFs, API routing (local vs cloud), and response format options. Complements annotations (readOnlyHint, openWorldHint) without contradiction.
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 front-loaded purpose and logical detail. Slightly long but necessary given complexity; each sentence adds value.
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?
Thoroughly covers search modes, filter syntax, pagination, response formats, and API routing. Addresses edge cases (presence checks, un-indexed PDFs). Lacks explicit error handling but is very complete overall.
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?
Adds significant meaning to q, qmode, tag, itemType, and response_format beyond schema. Explains retry logic for q. With 53% schema coverage, description compensates well but could explicitly cover remaining parameters.
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 or list items in a Zotero library or collection' with specific verb and resource. It distinguishes from siblings like zotero_semantic_search (conceptual) and zotero_get_item (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?
Provides explicit guidance on when to use default vs everything qmode, presence check behavior, and mentions alternative tool for conceptual queries. Could be more exhaustive about when not to use.
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?
The description adds significant context beyond annotations: it reveals the underlying flag mechanism (`deleted` 1/0), confirms reversibility, and specifies the API path (local vs web). Annotations already indicate a write operation (readOnlyHint=false) and non-destructive intent (destructiveHint=false), and the description aligns without contradiction.
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 concise and well-structured, fitting in three sentences. It front-loads the core action, then explains the flag behavior, usage guidance, and parameter details without any redundant filler.
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 write operation with no output schema, the description covers the essential behavioral aspects: reversibility, default action, API routing, and alternative tools. It lacks explicit mention of response formats or error handling, but these are less critical for a straightforward toggle operation. The omission of `library_id`/`library_type` is a minor gap, but the overall description is sufficiently complete for likely use cases.
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 50%, with only `action` and `item_keys` having descriptions. The description explains these two parameters (default action, required keys) but completely omits `library_id` and `library_type`. While it mentions 'your personal library' implying group libraries aren't covered, it doesn't clarify these parameters, leaving ambiguity for group use cases.
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: 'Move items to the trash' or 'restore them'. It uses a specific verb and resource, and explicitly differentiates from zotero_delete_items by emphasizing reversibility and the `deleted` flag mechanism.
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?
The description provides explicit guidance on when to use this tool: 'Use this instead of zotero_delete_items unless you truly need irreversible removal.' It also explains the default action and the optional `action` parameter, covering both use cases and alternatives.
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?
Goes far beyond annotations by disclosing optimistic concurrency handling (version fetch, retry on 412), cloud Web API writes, dry_run diff preview, and PATCH array replacement behavior. These are critical behavioral traits not available from readOnlyHint/idempotentHint.
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?
Every sentence earns its place: PATCH semantics, examples, value formatting, concurrency handling, endpoint, dry-run behavior. No filler or redundant repetition of annotations or schema.
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?
Highly detailed for a complex mutation tool with nested patch objects. Covers key behaviors, concurrency, and param formats. However, it does not describe the return value (no output schema exists) and omits library_id/library_type entirely, leaving some ambiguity for agent invocation.
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?
Description adds significant meaning beyond the schema for the 'patch' object, including plain-value format, no nested wrappers, and array replacement semantics. It also explains 'version' auto-fetch and 'dry_run' behavior. However, library_id and library_type are left undocumented, and schema coverage is 67%, so some gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it partially updates one item with HTTP PATCH semantics, specifying verb, resource, and scope. Distinguishes from sibling tools like zotero_create_items and zotero_delete_items by emphasizing 'update' and 'omitted fields are preserved'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (updating an existing item with partial changes) and explains PATCH semantics with examples. However, it does not explicitly mention exclusions or alternatives like 'use zotero_create_items for new items' or 'use zotero_delete_items for removal'.
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?
Annotations provide readOnlyHint, but description adds depth: behavior depends on API key presence, reports specific identity fields and backend availability. 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?
Three sentences covering purpose, usage, and edge case. No filler, front-loaded with most important information.
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 all essential aspects: identity fields, scopes, backends, and local-only fallback. Lacks explicit output format but lists fields sufficiently for a simple read-only 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?
No parameters, so schema coverage is 100%. Description does not need to elaborate on parameters. Baseline of 4 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 clearly states the tool resolves identity (userID, username, display name) and access scopes, and reports available backends. It also explicitly instructs to call this first, distinguishing it from other tools that perform searches or manage items.
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?
Explicit guidance to call this first and never ask user for numeric ID. Mentions local-only mode when no API key. No explicit alternatives needed as no sibling tool provides identity.
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?
Annotations (readOnlyHint=false, openWorldHint=true) align with the description's 'Add' action. The description adds extra behavioral context: the file is 'stored', meaning it persists; the URL is downloaded first; filename/content_type inference; and the return of a new attachment key. It also mentions the potential permission prompt. While not exhaustive (e.g., what happens if both path and url are provided is not specified), it provides meaningful beyond-annotation details.
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 concise and well-structured: three sentences. It front-loads the core purpose, then explains required parameters, then optional parameters and environment context, and finally the return value. Every sentence contributes useful information without redundancy or fluff.
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?
For a tool with 6 parameters and no output schema, the description covers all essential aspects: what the tool does, how to specify the file (path or url), inference rules for optional parameters, environment requirements (Zotero 10+), permission handling, and the return value (new attachment key). It is sufficiently complete for an agent to invoke correctly.
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 100%, but the description adds value beyond the schema: it clarifies that 'parent' is an item key, 'path' must be readable by the Zoteus process, 'url' is downloaded first, and 'filename' and 'content_type' are inferred when omitted (with a concrete example for content_type: pdf -> application/pdf). This enhances the agent's understanding of parameter semantics.
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: 'Add a stored file attachment (e.g. a PDF full text) under an existing item.' It identifies the specific verb (attach), resource (file attachment), and the target (existing item). It distinguishes from sibling tools by specifying 'stored file attachment' and the need for a parent item key, setting it apart from general item creation or management tools.
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?
The description provides explicit guidance: 'Give `parent` (the item key) and either `path` (a local file the Zoteus process can read) or `url` (downloaded first).' It also explains that `filename` and `content_type` are inferred when omitted, and notes the requirement for Zotero 10+ and a one-time write permission prompt. This tells the agent exactly when and how to use it, including prerequisites and alternatives.
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?
Annotations already mark readOnlyHint and openWorldHint. The description adds valuable behavioral details: the returned fields, the importance of the 'version' field for later updates/deletes, and the effect of optional parameters. 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?
The description is a single paragraph that front-loads the main action and then explains optional features. Every sentence serves a purpose without redundancy. 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 the tool's complexity (7 parameters, no output schema), the description covers the main action, return fields, optional children, and formatted output. It also explains the version field's role. No critical gaps remain.
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 71%; the description adds meaning by explaining how parameters like 'include', 'style', and 'locale' work together, and clarifies the optionality of 'include_children'. For undocumented parameters like 'library_id' and 'library_type', the description does not add value, but overall it enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'one item by its key', listing the full record fields. It distinguishes this tool from search, update, and other sibling tools by its specific function of retrieving 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 explicit guidance on optional parameters like 'include_children' and 'include', and how to combine 'include' with 'style' and 'locale'. It does not explicitly contrast with sibling tools, but the context is clear for a retrieval tool.
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?
Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true. The description adds critical behavioral details: tags are stored on the parent item's tag array, edits happen via cloud Web API, and tag names are case-sensitive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with the essential action classification, then details. Every sentence contributes value.
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?
No output schema, but the description covers all necessary aspects: actions, required parameters, side effects, and context about tag storage. Sufficient for an agent to select and invoke correctly.
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 43% (low), but the description compensates by explaining the purpose of `action`, `q`, `tags`, `item_keys`, and the case-sensitivity of tags. It adds meaning beyond schema definitions.
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 three actions (list, add, remove) with specific verb-resource combinations. It distinguishes itself from sibling tools like zotero_list_tags which is solely for listing.
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 tells when to use each action: set `action` to 'list', 'add', or 'remove'. It provides context on when `q` filter applies and that `item_keys` are needed for add/remove. However, it does not explicitly mention when not to use this tool in favor of alternatives.
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?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds beyond this: it specifies the tool is server-rendered, returns XHTML, is item-only, and capped at 150 items. No contradictions with annotations. The description provides valuable behavioral context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, then options, then a note about limits and an alternative. Every sentence adds value, no redundancy, and it is structured logically for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description covers purpose, usage limits, alternative tool, output format (XHTML), and parameter hints. It could mention error handling or behavior when items are missing, but it is reasonably complete for an agent to select and invoke the tool correctly.
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 schema has 6 parameters with 67% description coverage. The description explains item_keys, style, locale, linkwrap with added context (e.g., 'style (name or CSL id; Zotero default is chicago-note-bibliography)'). It does not mention library_id and library_type, but these are common and likely inferred from the library context. The description adds meaning beyond the schema for most parameters.
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 'Produce a formatted bibliography for items already in a Zotero library, rendered server-side by Zotero in a CSL style.' This provides a specific verb and resource, and it distinguishes from the sibling tool zotero_format_bibliography by noting that this tool is for library items only, while the other handles arbitrary CSL-JSON.
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?
The description explicitly states when to use this tool: 'item-only and capped at 150 items.' It also provides an alternative: 'For arbitrary CSL-JSON or items not in the library, use zotero_format_bibliography instead.' This gives clear context on usage boundaries and alternatives.
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?
Discloses several behaviors beyond the annotations: background job execution, immediate return, 100-at-a-time pagination with a 5000-item cap, atomic persistence, partial index usability, and CPU-bound embedding. The readOnlyHint=false is consistent with the mutation intent, and openWorldHint=true aligns with the external embedding provider dependence.
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 dense paragraph, but each sentence carries necessary operational detail. It could be more scannable with bullet points per action, but it remains efficient and front-loaded with the core 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?
Despite lacking an output schema, the description explains the return semantics of status (reports state, progress, index size, active embedder), the lifecycle of actions, and side effects like stop keeping partial data. It gives enough context to invoke the tool correctly and interpret results.
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 description adds meaning for the action enum (explains build/refresh, status, stop) and the limit parameter (default 5000 cap). However, library_id and library_type are not described, and with only 25% schema coverage, the description does not fully compensate for those two parameters.
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 opens with 'Manage the local hybrid-search index used by zotero_semantic_search', which clearly identifies the tool's resource and action. Listing the actions (build, refresh, status, stop) further distinguishes it from sibling search-related tools.
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 instructs the user to poll status after starting a build, warns that builds are non-blocking and may take a while, and advises polling rather than retrying build. It also clarifies that calling build again during a running build just returns progress.
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?
Annotations already mark destructiveHint=true, but the description adds critical details: the operation is irreversible and purges (not trash), requires explicit confirmation, is disabled without a server flag, and routes via local app or cloud API. It also notes the library version precondition and auto-chunking, going well beyond the annotations.
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, dense paragraph that front-loads the critical warning and then details requirements and behavior. Every sentence adds essential information with no redundancy, making it appropriately concise for a high-stakes operation.
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?
For a destructive tool with no output schema, the description fully covers safety (irreversible, requires confirm), operational prerequisites (server flag), behavioral specifics (chunk size, library version precondition), and routing (local app vs. cloud API). It gives an agent everything needed to decide and invoke correctly.
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 covers confirm and item_keys with descriptions (50% coverage), and the description reinforces their meaning: 'requires `confirm: true`' and 'delete items by key.' It also mentions auto-chunking to 50 keys, which adds operational context. However, it does not explain library_id/library_type beyond the schema, so it doesn't fully compensate for the 50% gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'PERMANENTLY and IRREVERSIBLY delete items by key' with a specific verb and resource, and explicitly distinguishes from the reversible 'zotero_trash_items'. This clearly defines the tool's unique function among siblings.
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?
The description explicitly says 'Prefer zotero_trash_items, which is reversible' and details the server flag requirement and the `confirm: true` prerequisite. This provides clear when-to-use and when-not-to-use guidance, plus operational constraints.
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?
Annotations already include readOnlyHint=true and openWorldHint=true, but the description adds significant behavioral detail: automatic PDF resolution, fallback download/parsing, page approximation vs exact with precise_pages, truncation behavior, and fulltextSource marking. This far exceeds what annotations alone provide.
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 dense paragraph that front-loads purpose and then details options. It is long but each sentence carries weight, covering modes, fallback, page precision, and use case. Slightly long, but well-structured with a clear flow from general to specific.
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 9 parameters, no output schema, and the tool's complexity, the description covers all essential aspects: input modes, output structure (passages with locators, offsets, nearest section, page), fallback behavior, page precision, and truncation. It also mentions when to use it. Complete for an agent to invoke correctly.
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?
With 78% schema coverage, the baseline is 3. The description enriches meaning for item_key (parent or attachment), query (top relevant passages), page_range (span '3-7'), fallback (on by default), precise_pages (re-extract for exact pages), and max_chars (never splits a passage). It explains behavior beyond the schema, e.g., automatic attachment resolution and page estimate behavior.
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 opens with a specific verb and resource: 'Retrieve an item's PDF text for grounding.' It clearly distinguishes its function from sibling tools by mentioning zotero_search_items and zotero_semantic_search, and explains the three modes (query, page_range, head) that make it unique.
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?
Explicit guidance is provided: 'Use this to cite a claim with a page after finding an item via zotero_search_items / zotero_semantic_search.' It also explains when fallback applies and how to get precise pages, which helps an agent decide when to use it versus alternatives.
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?
Annotations provide readOnlyHint and openWorldHint, and the description adds substantial context: it queries external scholarly APIs, uses Crossref as a fallback, never touches the user's library unless include_in_library is set, and describes the expensive scanning behavior. This goes well beyond the structured annotation data and is consistent with it.
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 dense but every sentence earns its place: scope, exclusions, action values, optional flag behavior, and safety. It front-loads the core purpose and then logically expands into usage details without 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?
The description gives strong context for selecting and invoking the tool, including action semantics and external data source behavior. It does not describe the result shape beyond 'works' and citation counts, but given the complexity of four action modes and no output schema, this is a minor gap rather than a critical omission.
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 schema covers parameter names and types, but the description adds crucial meaning for each parameter: the doi prefix tolerance, the exact meaning of each action enum value, the default and role of limit, and the behavioral tradeoff of include_in_library. This significantly enriches the schema, especially for the action parameter.
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 identifies the tool as exploring the external scholarly graph around a paper via OpenAlex and Crossref, with explicit action modes (lookup, references, citations, related). It distinguishes itself from sibling library tools by stating it does NOT search, list, or read the Zotero library.
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?
The description explicitly states what the tool does not do and names alternative tools (zotero_search_items, zotero_semantic_search, zotero_get_item, zotero_list_tags) for library operations. It also clarifies when to enable include_in_library and how the default avoids expensive library scanning.
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?
Even with readOnlyHint and openWorldHint annotations, the description adds crucial non-obvious behavior: the empty-index case triggers a background build, the tool instructs polling and retrying, and the hybrid behavior depends on whether an embedding provider is configured. This does not contradict the annotations and provides substantial practical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: core behavior, mode semantics, index bootstrap behavior, and sibling-tool alternatives. It is front-loaded with the primary purpose and filters into operational details without wasted repetition.
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?
This is a nuanced tool with no output schema, and the description manages to cover the return shape ('snippet and score'), the bootstrap failure mode, the retry protocol, and relevant sibling tools. An agent has enough information to select, invoke, and recover from the only realistically surprising condition.
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 75% and q/limit/auto_build already have descriptions, so the baseline is a 3. The description adds meaningful extra semantics for the mode enum, explaining what 'auto', 'keyword', and 'semantic' actually do, and clarifies the auto_build flow. It does not add much for q, but the schema already covers it adequately.
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 opens with a specific verb and resource: 'Search the library by meaning, not just keywords.' It clearly defines the mechanism (BM25 + vector similarity via reciprocal-rank fusion) and explicitly distinguishes this semantic tool from exact-filter search, making its purpose unmistakable.
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?
The description gives strong when-to-use guidance: use for conceptual/'papers about X' queries, and use zotero_search_items for exact field/tag/itemType filtering. It also tells the agent how to handle first-use index building: poll zotero_index action 'status' and retry, or pass auto_build:false.
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?
Discloses that export is read-only (matches readOnlyHint) and returns raw text. Explains better-biblatex availability and degradation, and that a limit is always applied. No annotation contradiction.
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?
Front-loaded with main purpose, then details format options, narrowing, and limit. Each sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, multiple enums, no output schema), the description is complete: explains output, format behaviors, narrowing, limit, and points to alternative tools.
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 adds meaning for all parameters: explains format options in detail, distinguishes better-biblatex, and explains how to use item_keys, collection_key, q, item_type, and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'Zotero items', and the output 'raw text'. It distinguishes from sibling tools like bibliography tools, which are for styled bibliographies.
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 says when to use (for raw text) and when not to (for styled bibliographies, use bibliography tools). Provides guidance on choosing between better-biblatex and biblatex, and explains narrowing options.
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:

[![zoteus MCP server](https://glama.ai/mcp/servers/oscardvs/zoteus/badges/card.svg)](https://glama.ai/mcp/servers/oscardvs/zoteus)

Score Badge

Copy to your README.md:

[![zoteus MCP server](https://glama.ai/mcp/servers/oscardvs/zoteus/badges/score.svg)](https://glama.ai/mcp/servers/oscardvs/zoteus)

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/oscardvs/zoteus'

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