Skip to main content
Glama

Import items by identifier or URL

zotero_import

Resolve bibliographic identifiers or web pages to Zotero items and optionally save them to your Zotero library, using a running desktop app or cloud API.

Instructions

Resolve bibliographic metadata to Zotero item-data and optionally save it to your library. action: "by_identifier" resolves a DOI, ISBN, PMID, arXiv id, or ADS bibcode (set identifier); action: "by_url" scrapes a web page (set url) and may return multiple choices to pick from. Set save_to_library:true (and optionally collection_key) to persist the resolved items — saved into the running Zotero desktop app when available, otherwise via the cloud Web API (requires ZOTERO_API_KEY); otherwise the resolved metadata is returned without saving. When a Zotero translation-server is reachable (ZOTEUS_TRANSLATION_SERVER_URL, default http://127.0.0.1:1969) it is the primary path; if none is running, DOI and arXiv ids fall back to built-in resolution (OpenAlex/Crossref and the arXiv API respectively) — the result then carries a source field ("scholar" or "arxiv"). ISBN/PMID/bibcode and web URLs require a translation-server.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoWeb page URL to scrape (needs a translation-server).
actionYes
attach_urlNoFile URL (e.g. an arXiv PDF) to download and attach as a stored attachment to the (single) imported item when saving to the desktop app.
identifierNoDOI (10.…), arXiv id (YYMM.NNNNN), ISBN, PMID, or ADS bibcode.
library_idNo
attach_titleNoTitle for the attached file, e.g. "Full Text PDF".
library_typeNo
collection_keyNoCollection to add saved items to: an 8-char collection key or a Zotero treeViewID like "C20".
save_to_libraryNoPersist the resolved items — into the running Zotero desktop app when available, otherwise the cloud Web API (needs a cloud key).
Behavior5/5

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

The description provides extensive behavioral details beyond annotations: it explains the save-to-library flow, desktop vs cloud handling, fallback to OpenAlex/Crossref and arXiv API, and the 'source' field in the result. It fully discloses the mutation and optional saving behavior, complementing the readOnlyHint:false annotation.

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 description is a single, well-structured paragraph that front-loads the core purpose and then flows into action specifics, saving behavior, and fallback logic. Every sentence adds useful detail without unnecessary fluff.

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?

The description is exceptionally complete for a tool of this complexity: it covers all main usage scenarios, environmental dependencies, and output characteristics. With no output schema, it clearly explains the source field and fallback behavior, leaving minimal ambiguity.

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 significant meaning for key parameters (action, identifier, url, save_to_library, collection_key, attach_url) beyond the schema. With 67% schema description coverage, the description compensates well for the gaps, though library_id and library_type remain under-specified.

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 clearly states the tool's purpose: resolving bibliographic metadata to Zotero item-data with optional saving. It distinguishes between 'by_identifier' and 'by_url' actions, making it distinct from sibling tools like zotero_create_items.

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?

The description explains when to use each action and the conditions for different fallback paths. It clearly specifies when a translation-server is required and mentions the API key for cloud fallback. However, it doesn't explicitly contrast with sibling tools like zotero_create_items, though the purpose is clear.

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