Skip to main content
Glama
edouardArmit

Zotero MCP Server

by edouardArmit

get_library_stats

Get library stats: item, collection, and tag counts, plus full-text index coverage. Scope to a specific library or get combined totals across all.

Instructions

Overall library stats: item/collection/tag counts and full-text index coverage (how many PDFs/notes are searchable via search_library's fulltext/notes scopes right now), including fulltext_index.index_last_updated. Omit library_id to get combined totals across your personal library and every group/shared library, with a by_library breakdown (see list_libraries for names); pass a specific library_id to scope to just one. Mention the index_last_updated timestamp to the user whenever you report these stats or otherwise rely on the full-text index.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
library_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses aggregation behavior, the meaning of full-text coverage, and the presence of index_last_updated. It does not explicitly state read-only or side-effect-free, but the 'stats' framing makes that reasonably clear. The instruction to surface the timestamp adds useful behavioral 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?

Three sentences, each with distinct value: the stat contents, the parameter behavior, and the user-facing timestamp instruction. Front-loaded with the core purpose. No filler or 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?

Given no output schema and no annotations, the description provides enough conceptual detail about return contents (counts, coverage, timestamp, breakdown) and cross-references list_libraries for names. An agent can call the tool and correctly interpret the results.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. It fully explains the library_id parameter: omitting it yields combined totals across personal and shared libraries with a by_library breakdown, while passing it scopes to one library. This is rich semantic meaning that the bare schema (nullable integer default null) completely lacks.

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 clear, specific noun phrase 'Overall library stats' and enumerates the exact resources involved (items, collections, tags, full-text index coverage). It also ties the coverage to search_library's fulltext/notes scopes, which distinguishes it from sibling tools like list_items or list_collections.

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 concrete parameter guidance: omitting library_id returns combined personal/shared totals with a by_library breakdown, while passing a specific id scopes to one library. It also points to list_libraries for names and explicitly instructs to mention the index_last_updated timestamp. However, it does not explicitly state when NOT to use this tool in favor of a sibling, 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.