Skip to main content
Glama

Save a paper's or collection's annotations as a note

zotero_save_annotation_digest

Save Zotero annotations as a formatted note with linked highlights, citations, comments, and tags, attached to a paper or filed in a collection for quick review.

Instructions

Gather the annotations zotero_annotation_digest lists and save them as a Zotero note, laid out the way Zotero's own "Add Note from Annotations" lays one out: a paragraph per annotation with the highlighted passage, a citation with its page, the comment and tags. Each highlight stays linked to its spot in the PDF and each citation to its paper, so both open from the note in Zotero. For item_key the note is attached to that paper; for collection_key it is a standalone note filed in that collection, with a heading per paper (up to 200 items; the note says so if the collection holds more). Takes the same types, colors and tags filters. Nothing is written when no annotation matches. Writes go to the running Zotero desktop app (Zotero 10+) for every library it holds, otherwise to the cloud Web API.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "zotero_save_annotation_digest"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoOnly annotations carrying at least one of these tags (case-insensitive). Default: all.
titleNoThe note's heading and title. Default "Annotations (<date>)", or "Annotations: <collection> (<date>)".
typesNoOnly these annotation types, e.g. ["highlight", "note"]. Default: all.
colorsNoOnly these colours: Zotero's names (yellow, red, green, blue, purple, magenta, orange, gray) or hex values like "#ffd400". Default: all.
item_keyNoA paper (or a standalone PDF/EPUB attachment) whose annotations to gather. Give this or `collection_key`, not both.
note_tagsNoTags to put on the note itself, e.g. ["annotation-digest"].
library_idNoNumeric id of the library to address, e.g. 5234875 for a group (zotero_groups lists the ids you can reach). Omit to use the configured default library; an id given without library_type is read as a group id.
library_typeNoWhich library to address: "user" (a personal library) or "group" (a shared group library). Omit to use the library this server is configured for. "group" on its own is refused: pass library_id with it.
collection_keyNoA collection whose top-level items' annotations to gather (from zotero_list_collections; subcollections are not included).

Output Schema

NameRequiredDescriptionDefault
keyNoKey of the note created.
itemsYesPapers the note covers.
failedNoOne entry per object the write could not land; absent or empty when all of them did.
targetNoWhere the write went: "local" (Zotero desktop local API), "desktop" (connector protocol) or "cloud" (Zotero Web API).
versionNoIts version after the write.
truncatedNoTrue when the collection held more than 200 items and the note covers the first 200 by title.
parentItemNoThe paper the note was attached to, for item_key.
annotationsYesAnnotations the note holds.
collectionsNoCollections the standalone note was filed in.
libraryVersionNoThe library's Last-Modified-Version after this write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.23.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint false, destructiveHint false, openWorldHint true), and the description adds substantial context on top: the write target depends on whether a Zotero desktop app (10+) is running, otherwise the cloud Web API. It also discloses preserved deep links from note back to PDF and paper, and the silent no-match behaviour.

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?

A single dense paragraph with no filler sentences and the core action front-loaded in the first clause. It could be broken into mode-specific bullets for faster scanning given its length, but every sentence carries information.

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 mutating, zero-required-parameter tool with nine optional params and an output schema, the description covers everything an agent needs: what is produced, where it is filed per mode, which filters apply, limits, and the no-write edge case. Return-value formatting is correctly left to the output schema.

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 100%, so the schema already documents all nine parameters, including defaults for title and colour syntax. The description only adds the mapping that the filter parameters behave identically to zotero_annotation_digest's; that is useful but marginal, so the baseline of 3 applies.

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 and resource ('Gather the annotations ... and save them as a Zotero note') and pins the exact output format by reference to Zotero's own 'Add Note from Annotations'. It clearly separates the two operating modes (item_key -> attached note, collection_key -> standalone note) so an agent can distinguish it from zotero_annotation_digest and zotero_create_note.

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 routes agents from the read-only sibling: it consumes what 'zotero_annotation_digest lists' and inherits its `types`, `colors` and `tags` filters. It also states the selection rule for the two key parameters, the 200-item ceiling with its in-note disclosure, and the no-op case ('Nothing is written when no annotation matches'), leaving little to inference.

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