zotero-library-mcp

Attach File

attach_file

Attach a ChatGPT-provided file or an authorized local file to a Zotero item using its item key, so the file is stored alongside the reference.

Instructions

Attach a ChatGPT file input or an authorized local file to an item.

Args: item_key: The Zotero item key to attach the file to file: File object supplied by ChatGPT through openai/fileParams file_path: Local server path; stdio only unless HTTP roots are explicitly enabled

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": {
      "item_key": "<item_key>"
    },
    "name": "attach_file"
  }
}

Input Schema

Name	Required	Description	Default
`file`	No
`item_key`	Yes
`file_path`	No
`library_id`	No
`library_type`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.10.0Sep 14, 2026

addedInput schema / properties / library_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Library Id"
+}

addedInput schema / properties / library_type

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "user",
+        "group"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Library Type"
+}

First observedv0.9.0Aug 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so safety profile is partly covered. The description adds a genuinely useful constraint (file_path is stdio only unless HTTP roots are enabled), but says nothing about what happens on collision, overwrite, or failure. Baseline 3 with partial added value.

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?

Purpose is front-loaded in one sentence, and the Args block is compact. Slight redundancy since the arg list restates schema field names, but each line adds semantic detail rather than pure repetition.

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

Completeness3/5

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

Has an output schema, so return values need not be explained. For a mutation tool with 5 params, however, the omission of library_id/library_type semantics and the file/file_path selection rule leaves meaningful gaps an agent must guess at.

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 0% for top-level params, so the description carries the burden. It documents item_key, file, and file_path but leaves library_id and library_type completely unexplained, and gives no rule for mutual exclusivity of file vs file_path. Partial compensation.

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?

Specific verb+resource+target: 'Attach a ChatGPT file input or an authorized local file to an item.' An agent can distinguish this from list_attachments/download_pdf/save_pdf without opening schemas, though it never names a sibling explicitly for routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance. It says the tool attaches a file, but doesn't explain when to choose it over save_pdf, download_pdf, or how it relates to list_attachments. It also doesn't resolve the file-vs-file_path choice beyond a constraint note.

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