Skip to main content
Glama
oscardvs

Zoteus

by oscardvs
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Update a Zotero item

zotero_update_item
DestructiveIdempotent

Partially update a Zotero item, preserving omitted fields. Preview the exact before→after diff with dry_run before writing.

Instructions

Partially update one item (HTTP PATCH — only the fields you supply change; omitted fields are preserved). Provide item_key and a patch object of the fields to change (e.g. {"title":"New","extra":"note"} or {"tags":[{"tag":"reviewed"}]}). All field values are plain JSON strings/numbers/booleans/arrays — never wrapped in nested objects (e.g. "title": "New", NOT "title": {"title": "New"}). Optimistic concurrency is handled for you: if you pass the item's version it is used; otherwise the current version is fetched first. If the item changed on the server in the meantime (412), the update is automatically re-fetched and retried once. Writes go to the cloud Web API. Set dry_run:true to preview the field-level before→after diff without writing (arrays like tags/collections are replaced wholesale by PATCH, not merged; a dry_run call performs no write).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patchYesObject of fields to change (PATCH semantics), e.g. {"title": "New title", "date": "2024-02-01", "tags": [{"tag": "reviewed"}], "collections": ["ABCD1234"]}. Structured fields (creators, tags, collections, relations) must be real JSON arrays/objects, not JSON-encoded strings. Values are plain, never wrapped in nested objects.
dry_runNoPreview the field-level before→after diff without writing.
versionNoKnown current version; fetched automatically if omitted.
item_keyYesThe 8-character item key.
library_idNo
library_typeNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv1.3.1
    • changedInput schema / properties / patch / description
      Previous value: -"Object of fields to change (PATCH semantics). Structured fields (creators, tags, collections, relations) must be real JSON arrays/objects, not JSON-encoded strings."New value: +"Object of fields to change (PATCH semantics), e.g. {\"title\": \"New title\", \"date\": \"2024-02-01\", \"tags\": [{\"tag\": \"reviewed\"}], \"collections\": [\"ABCD1234\"]}. Structured fields (creators, tags, collections, relations) must be real JSON arrays/objects, not JSON-encoded strings. Values are plain, never wrapped in nested objects."
    • addedInput schema / properties / patch / properties / itemType
      Added value: +{
+  "description": "The Zotero item type as a plain string, e.g. \"journalArticle\", \"book\", \"preprint\", \"report\", \"thesis\".",
+  "type": "string"
+}
  2. First observedv1.0.4

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses PATCH merge semantics, plain-value formatting, optimistic concurrency with automatic retry, cloud Web API writes, dry_run behavior, and wholesale replacement of arrays. These are exactly the behavioral surprises an agent would otherwise discover at runtime.

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 text is long but information-dense and front-loaded with the central PATCH semantics. Each sentence adds operational value, though a bit of restructuring (separating dry_run and concurrency) could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and a complex patch object, the description covers invocation, concurrency, and dry_run well. It leaves return-value shape and optional library parameters (library_id/library_type) implicit, but these are not required to make a correct call.

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 description adds crucial meaning beyond the schema: patch values must not be wrapped in nested objects, tags/collections are replaced rather than merged, and version/dry_run behavior is explained. It does not clarify library_id/library_type, but the core required parameters are thoroughly documented.

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 'Partially update one item (HTTP PATCH — only the fields you supply change; omitted fields are preserved)', which names a precise verb, a specific resource, and the operation's scope. This clearly distinguishes it from sibling create/delete/trash 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 clearly implies use for modifying an existing item and explains when dry_run is appropriate, and the PATCH semantics tell the agent not to send full objects. It does not explicitly name alternatives like zotero_create_items or zotero_delete_items, so no explicit exclusion is given.

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/oscardvs/zoteus'

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