Skip to main content
Glama
oscardvs

Zoteus

by oscardvs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Zotero groups

zotero_groups
Read-only

Lists accessible Zotero group libraries, returning each group's ID and name so you can select one for subsequent operations.

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. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. 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#"
  3. 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"
+}
  4. Changed1 schema field changedv1.18.0
    • addedInput schema / additionalProperties
      Added value: +false
  5. First observedv1.0.4

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already mark this readOnlyHint=true and destructiveHint=false, and the description substantially expands on them: it discloses that it never sends a write, explains canWrite is derived from the key's access map, describes the cloud-versus-local fallback, distinguishes 'source' values, and explains when indexed will become true after another tool runs. This goes well beyond what annotations alone communicate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and dense, but the core line is front-loaded and nearly every sentence adds genuinely useful distinctions (cloud vs local, source, indexed, write path). It would earn a 5 with better paragraph or bullet structure; as written, it is a wall of text that an agent must parse carefully.

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 zero-parameter read-only listing tool, this description is exceptionally complete: it covers return values, keyless fallback behavior, write implications, indexing semantics, and how to use the output with sibling tools. There is an output schema, and the description also pre-explains the important row fields, so an agent is unlikely to be left with unresolved setup questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is an empty object, so there are no parameter semantics for the description to clarify. The 0-parameter baseline of 4 applies, and the description wisely spends its space explaining the output dimensions rather than inventing parameter guidance.

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: 'List the group libraries this server can reach, with each group's id and name.' It clearly distinguishes the tool from siblings by explaining exactly what kind of object it returns and how the returned id is meant to be consumed by other 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?

It provides clear context for when the tool is useful: it lists newly accessible groups arbitered by a cloud key or a local Zotero desktop app, and it explicitly tells the agent to feed returned group ids into library_id/library_type parameters elsewhere. It does not name exclusions or alternative list tools, but for a standalone list operation the guidance is direct and actionable.

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