Skip to main content
Glama

update_publication_status

Idempotent

Update a Zotero item when a preprint becomes formally published, adding journal details like DOI and changing item type while preserving existing citations and keys.

Instructions

Update an item in place to reflect that a preprint has been formally published -- e.g. an arXiv preprint that just received a journal DOI. Same key-preserving patch as update_item (Word citations keep working) -- prefer this or update_item over deleting and recreating the item whenever a preprint's status changes.

Unlike update_item, item_type may also be passed to change the item's Zotero type (e.g. "preprint" -> "journalArticle") -- update_item forbids that because it changes which fields are valid; this is the one tool where that's the deliberate point of the call.

fields: same rules as update_item -- bibliographic fields such as DOI, url, date, publicationTitle, volume, issue, pages. May NOT include tags/collections/itemType/key/version -- use the dedicated tools for tags/collections, and item_type (not fields["itemType"]) to change the item type. item_type: new Zotero item type (see list_item_types); omit to leave it unchanged. version: the item's current version (from search_items/get_item) -- refused if stale, same as update_item. idempotency_key: an opaque string you generate once per logical request. If a call with this exact key and these exact arguments already completed -- success OR error -- that same outcome is replayed instead of running anything against Zotero again, so retrying after a lost response (e.g. a timeout) can't turn one edit into two. Reusing a key with DIFFERENT arguments raises an error instead of silently returning the old result -- use a fresh key per distinct request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
fieldsYes
versionYes
item_typeNo
idempotency_keyNo
Behavior5/5

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

Adds idempotency_key replay semantics (same key+args replays outcome; different args raises error), version staleness check, and field restriction list (tags/collections/itemType/key/version not allowed). Annotations only hint idempotent; description gives operational detail beyond the annotations.

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?

While long, every sentence adds value; uses bolded parameter names and clear structure with line breaks. No filler or redundancy, and the purpose is front-loaded.

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?

Covers purpose, alternatives, parameter semantics, restrictions, idempotency, and versioning. No output schema needed; response outcome described via idempotency behavior and version check. Fully complete for a complex 5-parameter tool.

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%, but description details fields (allowed bibliographic fields), item_type (new type from list_item_types), version (current version from search_items/get_item), idempotency_key (opaque per-request string). Key itself is implicit but contextually obvious; the description fully compensates for schema absence.

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?

Description opens with a specific verb+resource: 'Update an item in place to reflect that a preprint has been formally published' and immediately distinguishes from update_item by noting item_type is allowed here but forbidden there. This clearly delineates the tool's unique scope.

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 advises 'prefer this or update_item over deleting and recreating' and contrasts with update_item's item_type restriction. Also directs use of dedicated tools for tags/collections, giving concrete when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/herbertkokholm/cite-caddy'

If you have feedback or need assistance with the MCP directory API, please join our Discord server