Skip to main content
Glama
oscardvs

Zoteus

by oscardvs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Zotero groups

zotero_groups
Read-only

List accessible Zotero group libraries with IDs and names. Use a group ID with library_id and library_type:"group" to operate on that group.

Instructions

List the group libraries this server can reach, with each group's id and name. Use a returned group id with the library_id/library_type:"group" parameters of other tools to operate on that group library; library_type alone does not address a group. With a cloud API key each group the key can access is listed with its type, item count, description and edit permissions, plus canWrite: whether this key may write to that group, decided from the key's own access map without sending a write, and writeBlockedReason naming the remedy when it may not. Without a key the list falls back to the group libraries a running Zotero 10+ desktop app holds, which are exactly the groups still readable, key-free, from that app: those rows carry id, name, description and the desktop's own item count, and no type, edit permissions or canWrite, because the desktop does not store them. On every row numItems counts ALL the items the library holds, child attachments, notes and annotations and the trash included, so it is larger than a zotero_search_items count and is not a number of papers; numItemsNote says how to count top-level items instead. Where both are available every row says which it came from, in source: "cloud", "local", or "both" for a group the key can see and the desktop also holds. Rows also carry indexed: whether this data directory holds a search index for that group, which is what makes it searchable by meaning. Each library gets its own index file, so several rows can be true, and a false row becomes true after zotero_index action:"build" library_type:"group" library_id:. Writing to a group always goes through the cloud, even when the Zotero desktop app holds that group, and needs a key with write access to it; libraryEditing says whether the group itself lets ordinary members edit its library.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoWhat a desktop-served row does and does not say; present only when one is listed.
groupsYesThe group libraries this server can reach.
numItemsNoteNoWhat `numItems` counts (every item, children and the trash included) and how to count top-level items instead; present whenever a row carries numItems.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.22.4
    • changedOutput schema / properties / groups / items / properties / numItems / description
      Previous value: -"Item count. A desktop row counts every row it holds, so it differs from the cloud's figure."New value: +"Every item the library holds: top-level items, child attachments, notes and annotations, and the trash. Not comparable with a zotero_search_items totalResults; see numItemsNote. A desktop row counts the desktop's copy, a cloud row the cloud's."
    • addedOutput schema / properties / numItemsNote
      Added value: +{
+  "description": "What `numItems` counts (every item, children and the trash included) and how to count top-level items instead; present whenever a row carries numItems.",
+  "type": "string"
+}
  2. Changed3 schema fields changedv1.21.0
    • addedOutput schema / properties / groups / items / properties / canWrite
      Added value: +{
+  "description": "Whether the configured cloud API key is allowed to write to this group, from the key's own access map. Absent on a desktop-only row, and absent when the key reported no access map at all, which means unknown rather than no. A group can separately be configured so only admins may edit its library (see `libraryEditing`), which no key setting overrides, so true is the key's permission and not a guarantee the group accepts the write.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / groups / items / properties / indexed
      Added value: +{
+  "description": "Whether this data directory holds a search index for this group library, which is what zotero_semantic_search needs to search it by meaning. Each library gets its own index file, so several rows can be true. A false row is still searchable by keyword through the Zotero API, and becomes searchable by meaning after zotero_index action:\"build\" library_type:\"group\" library_id:<id> (action:\"libraries\" lists the ones that exist). Absent only where the answer is unknown: no per-library index registry and an index that records no library.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / groups / items / properties / writeBlockedReason
      Added value: +{
+  "description": "Why this key cannot write to this group, and what to change; present only when canWrite is false.",
+  "type": "string"
+}
  3. Changed2 schema fields changedv1.20.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed1 schema field changedv1.20.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "groups": {
+      "description": "The group libraries this server can reach.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "description": {
+            "description": "Group description.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Group id; pass it as library_id together with library_type:\"group\".",
+            "type": "number"
+          },
+          "libraryEditing": {
+            "description": "Who may edit the group library, e.g. \"members\" or \"admins\"; absent on a desktop-only row.",
+            "type": "string"
+          },
+          "name": {
+            "description": "Group name.",
+            "type": "string"
+          },
+          "numItems": {
+            "description": "Item count. A desktop row counts every row it holds, so it differs from the cloud's figure.",
+            "type": "number"
+          },
+          "source": {
+            "description": "Where the row came from: \"cloud\", \"local\", or \"both\".",
+            "type": "string"
+          },
+          "type": {
+            "description": "Zotero group type, e.g. \"Private\" or \"PublicClosed\"; absent on a desktop-only row.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "What a desktop-served row does and does not say; present only when one is listed.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "groups"
+  ],
+  "type": "object"
+}
  5. Changed1 schema field changedv1.18.0
    • addedInput schema / additionalProperties
      Added value: +false
  6. First observedv1.0.4

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the read/safety profile; the description adds substantial behavioral context: cloud-vs-local fallback semantics, that numItems includes children/notes/trash, that canWrite is derived without a write attempt, how indexed becomes true after a build action, and that writes always route through the cloud. This is far beyond what the annotations convey.

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?

Front-loaded with the core purpose before diving into cloud/local modes. The prose is dense and some clauses are long, but nearly every sentence carries distinct information about modes, counts, or write behavior, so little is wasted.

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 a no-parameter list tool with an output schema, the description covers the two operating modes, the meaning of every non-obvious field, and the write path. An agent has everything needed to call it and interpret the results 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 tool takes no input parameters, so the baseline is 4. Despite zero params, the description usefully documents output field semantics (source, numItems, canWrite, indexed), which aids correct interpretation even though an output schema exists.

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?

States a specific verb (List) and resource (group libraries reachable by the server) and immediately scopes the output (id and name). It is clearly distinguishable from siblings like zotero_list_collections and zotero_list_tags, which target different resources.

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 tells the agent exactly what to do with the result ('Use a returned group id with the library_id/library_type:"group" parameters of other tools') and warns that library_type alone does not address a group. It also explains the prerequisite (write access needs a key via the cloud). It stops short of naming explicit when-not-to-use cases, so it is strong but not a full routing rubric.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools