zotero-library-mcp

Download Pdf

download_pdf

Read-onlyIdempotent

Return a Zotero item's PDF as a remote-safe resource link so you can read books or papers directly when the fulltext index is incomplete or missing.

Instructions

Return a PDF as a remote-safe MCP resource link.

Useful when Zotero's fulltext index is incomplete (e.g. for books) and you need to read the PDF directly with other tools.

Args: item_key: The Zotero item key (the parent item, not the attachment) attachment_key: Optional PDF attachment key when the item has multiple PDFs

Pass both library_id and library_type to target another library; omit both to use the configured default.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`item_key`	Yes
`library_id`	No
`library_type`	No
`attachment_key`	No

Output Schema

TableJSON 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

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful operational context by saying the output is a resource link rather than inline content, but omits failure behavior (e.g. what happens when the item has no PDF attachment or the attachment is not a PDF).

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?

Front-loaded with the one-line behavior, then usage condition, then a compact Args block. Slightly docstring-flavored with the leading 'Args:' formatting, but every sentence carries information and nothing is padded.

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?

An output schema exists, so return-value explanation is not needed, and the description covers purpose, usage trigger, and all four parameters including the default-library rule. Only edge-case behavior (missing/non-PDF attachment) is left unaddressed.

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 description coverage is 0%, so the description carries the full burden, and it does: item_key is clarified as the parent item not the attachment, attachment_key is explained as the selector for multi-PDF items, and library_id/library_type are given a both-or-neither rule with an explicit default. This is meaningfully beyond the bare schema titles.

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?

States a specific verb and resource ('Return a PDF as a remote-safe MCP resource link'), which tells an agent exactly what it gets back. It does not explicitly distinguish itself from siblings like save_pdf or get_item_fulltext, though the phrase 'MCP resource link' versus saving a file does most of that work implicitly.

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?

Gives a concrete when-to-use condition: 'Useful when Zotero's fulltext index is incomplete (e.g. for books) and you need to read the PDF directly with other tools,' which effectively positions it against get_item_fulltext/search_fulltext. No explicit when-not-to-use or hard prerequisites are stated.

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