Skip to main content
Glama

Zotero attachments (files)

zotero_attachment
Destructive

Upload, download, or inspect attachment files. action: "upload" stores a file as a Zotero attachment using the full File Storage protocol (provide url to have Zoteus fetch it, or file_path for a file on the machine running Zoteus…

Instructions

Upload, download, or inspect attachment files. action: "upload" stores a file as a Zotero attachment using the full File Storage protocol (provide url to have Zoteus fetch it, or file_path for a file on the machine running Zoteus; optional parent_item to attach it under an item, title, content_type) and returns the new attachment key; "download" fetches an attachment's file to a local path (provide item_key; optional save_path, default under the Zoteus data dir) and returns the path and byte count; "info" returns an attachment item's metadata. File bytes are written to / read from disk, never streamed through the conversation. Upload and download go through the running Zotero desktop app (Zotero 10+, no cloud key and no storage quota) for your personal library and any group library the app holds, and through the cloud Web API and your file-storage quota otherwise; target (upload) and readFrom (download) say which. When Zoteus runs on a different machine than Zotero, file_path refers to the server's disk, so use url instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "zotero_attachment"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoURL to download and upload instead of `file_path`; works on remote/hosted servers.
titleNoAttachment title (upload), e.g. "Full Text PDF"; the filename is used when omitted.
actionYesWhat to do. "upload" stores a file as an attachment (needs `file_path` or `url`); "download" writes an attachment's file to disk (needs `item_key`); "info" returns the attachment item's metadata.
item_keyNoAttachment item key (download/info).
file_pathNoFile to upload, on the machine running Zoteus.
overwriteNoAllow `save_path` to replace a file that already exists (default false).
save_pathNoWhere to write the downloaded file.
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.
parent_itemNoParent item key to attach under (upload).
content_typeNoMIME type of the uploaded file, e.g. "application/pdf"; inferred from the filename when omitted.
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.

Output Schema

NameRequiredDescriptionDefault
keyNoaction:"upload": key of the attachment item created.
bytesNoBytes uploaded or written.
existsNoTrue when Zotero already held these bytes and only the item was created.
targetNoWhere the write went: "local" (Zotero desktop local API), "desktop" (connector protocol) or "cloud" (Zotero Web API).
filenameNoFile name stored.
readFromNoaction:"download": which copy the bytes came from, "local" (the running Zotero desktop app reading its own storage) or "cloud" (Zotero file storage).
savePathNoaction:"download": where the file was written.
attachmentNoaction:"info": the attachment item's full record.
contentTypeNoMIME type of the downloaded file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.23.0
    • addedOutput schema / properties / readFrom
      Added value: +{
      +  "description": "action:\"download\": which copy the bytes came from, \"local\" (the running Zotero desktop app reading its own storage) or \"cloud\" (Zotero file storage).",
      +  "type": "string"
      +}
    • addedOutput schema / properties / target
      Added value: +{
      +  "description": "Where the write went: \"local\" (Zotero desktop local API), \"desktop\" (connector protocol) or \"cloud\" (Zotero Web API).",
      +  "type": "string"
      +}
  2. Changed1 schema field changedv1.21.0
    • addedInput schema / properties / library_id / exclusiveMinimum
      Added value: +0
  3. Changed2 schema fields changedv1.20.2
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed6 schema fields changedv1.20.0
    • addedInput schema / properties / action / description
      Added value: +"What to do. \"upload\" stores a file as an attachment (needs `file_path` or `url`); \"download\" writes an attachment's file to disk (needs `item_key`); \"info\" returns the attachment item's metadata."
    • addedInput schema / properties / content_type / description
      Added value: +"MIME type of the uploaded file, e.g. \"application/pdf\"; inferred from the filename when omitted."
    • addedInput schema / properties / library_id / description
      Added value: +"Numeric 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."
    • addedInput schema / properties / library_type / description
      Added value: +"Which 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."
    • addedInput schema / properties / title / description
      Added value: +"Attachment title (upload), e.g. \"Full Text PDF\"; the filename is used when omitted."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "attachment": {
      +      "additionalProperties": {},
      +      "description": "action:\"info\": the attachment item's full record.",
      +      "type": "object"
      +    },
      +    "bytes": {
      +      "description": "Bytes uploaded or written.",
      +      "type": "number"
      +    },
      +    "contentType": {
      +      "description": "MIME type of the downloaded file.",
      +      "type": "string"
      +    },
      +    "exists": {
      +      "description": "True when Zotero already held these bytes and only the item was created.",
      +      "type": "boolean"
      +    },
      +    "filename": {
      +      "description": "File name stored.",
      +      "type": "string"
      +    },
      +    "key": {
      +      "description": "action:\"upload\": key of the attachment item created.",
      +      "type": "string"
      +    },
      +    "savePath": {
      +      "description": "action:\"download\": where the file was written.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  5. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / overwrite
      Added value: +{
      +  "description": "Allow `save_path` to replace a file that already exists (default false).",
      +  "type": "boolean"
      +}
  6. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / file_path / description
      Previous value: -"Local file to upload."New value: +"File to upload, on the machine running Zoteus."
    • addedInput schema / properties / url
      Added value: +{
      +  "description": "URL to download and upload instead of `file_path`; works on remote/hosted servers.",
      +  "format": "uri",
      +  "type": "string"
      +}
  7. First observedv1.0.4

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructive/openWorld/not-idempotent, but the description adds real behavioral context beyond them: bytes go to/from disk rather than through the conversation, uploads consume the cloud file-storage quota when not routed through the desktop app, and desktop routing requires Zotero 10+. It does not spell out overwrite/error behavior beyond the schema's `overwrite` flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary is front-loaded and most sentences carry weight, but the body is one dense run-on paragraph that re-explains per-action requirements already fully covered by the schema's `action` description. The reference to non-existent parameters (`target`, `readFrom`) is wasted tokens that can mislead.

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 complex 11-parameter, multi-action, mutating tool with an output schema present, the description covers routing, quota, defaults, and remote-machine caveats well. The main omission is sibling disambiguation against `zotero_attach_file`, and it explains return values despite an output schema making that optional.

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 coverage is 100%, so the baseline is 3, and the description does add some meaning (default `save_path` under the Zoteus data dir, rationale for `url` over `file_path`). But it also references `target` (upload) and `readFrom` (download) as parameters that do not exist in the schema, which is actively misleading given `additionalProperties: false`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line gives a specific verb set and resource ("Upload, download, or inspect attachment files") and the per-action detail makes the three modes unambiguous. However, it never differentiates itself from the very close sibling `zotero_attach_file`, so an agent seeing both cannot tell which to pick from the text alone.

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 gives concrete conditions for the key branch: use `url` when Zoteus runs on a different machine than Zotero, `file_path` when the file is on the server's disk, and it explains the desktop-app vs cloud-API routing. It stops short of naming alternatives (e.g. `zotero_attach_file`, `zotero_import`) or stating when not to use this tool.

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