Skip to main content
Glama
JingYangYuan

zotero-local-mcp

by JingYangYuan

zotero_update_item

Update an existing Zotero item's metadata by key. Modify fields, tags, creators, and collections as needed.

Instructions

Update metadata on an existing Zotero item by key. Only what you pass is changed. fields: {name: value} of metadata to set (a JSON object string is accepted). Names may be snake_case (title, date, doi, url, abstract, publication_title, access_date, short_title, book_title, citation_key, item_type, place, extra, volume, issue, pages, publisher, issn, isbn, edition, language) or any raw Zotero API field name. An unknown name fails the call and lists the valid ones; a name that is not valid for this item's type is reported as skipped. item_type migrates the item (overlapping fields kept, type-specific ones dropped). TAG SEMANTICS (easy to get wrong): tags REPLACES the whole tag list; add_tags/remove_tags are incremental and preferred. They are mutually exclusive with tags. collections (keys) and collection_names likewise REPLACE membership — pass collections=[] to clear it; for incremental moves use zotero_set_item_collections. creators: full replacement list of {creatorType, firstName, lastName} objects. Requires a writable library (fails in local-only mode). To edit notes use zotero_manage_note. Example: zotero_update_item(item_key='RTKZQI8E', fields={'doi': '10.1145/3708319'}, add_tags=['reviewed']).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
fieldsNomapping (or JSON object string) of field name -> value. Names may be snake_case aliases (``publication_title``, ``short_title``, ``citation_key``) or raw Zotero API keys (``publicationTitle``). ``place`` is the publication city (e.g. ``"New York"``) and is valid on book, bookSection, thesis, manuscript, report and conferencePaper. ``citation_key`` writes Zotero's native ``data.citationKey`` (the BetterBibTeX citation key); BBT auto-pins from metadata on creation and provides no programmatic refresh path in 9.x, so a direct write here is the only programmatic remediation for malformed pinned keys. ``item_type`` migrates the item across types: overlapping fields are preserved and type-specific fields that do not map are dropped.
add_tagsNo
creatorsNofull replacement creators list (also accepted as ``fields['creators']``).
item_keyYes8-character Zotero item key of the item to update.
collectionsNo
remove_tagsNo
collection_namesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it thoroughly. It discloses failure modes (unknown name fails and lists valid ones, invalid name skipped), the replacement semantics for tags and collections, the mutual exclusivity of tags vs add_tags/remove_tags, the item_type migration behavior, and the writable-library prerequisite. Nothing is hidden; every behavioral quirk is surfaced.

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 long but every sentence carries essential information. It is front-loaded with the core action and scope, then proceeds through the most error-prone semantics (tags, collections, creators) with clear formatting. The example at the end reinforces understanding without redundancy. It earns its length through density.

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 of an 8-parameter mutation tool with a rich output schema, the description is remarkably complete. It covers all replacement vs incremental semantics, failure handling, library requirements, and pointers to sibling tools for related operations. The provided example demonstrates realistic usage. An agent has everything needed to invoke the tool correctly without additional inference.

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 only 38%, but the description compensates extensively. It enumerates the snake_case aliases, explains the tags/add_tags/remove_tags semantics, clarifies collections/collection_names replacement, defines creators as a full replacement list, and details the fields parameter including item_type migration. This goes far beyond the sparse schema descriptions, making parameter usage unambiguous.

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 precise verb+resource statement: 'Update metadata on an existing Zotero item by key.' It immediately clarifies scope ('Only what you pass is changed') and lists supported field names, distinguishing itself from sibling tools by naming zotero_set_item_collections and zotero_manage_note for related tasks. This leaves no ambiguity about what the tool does or how it differs from alternatives.

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: it states that the tool requires a writable library and fails in local-only mode, and it explicitly routes note editing to zotero_manage_note and incremental collection moves to zotero_set_item_collections. However, it does not explicitly state when NOT to use this tool in favor of the broader batch_update sibling, leaving that distinction implicit. It offers strong guidance but stops short of a full when/when-not matrix.

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