Skip to main content
Glama
JingYangYuan

zotero-local-mcp

by JingYangYuan

zotero_export_bibliography

Generate formatted bibliographies, in-text citations, or BibTeX from Zotero items using CSL styles, with optional filtering by item keys or collection.

Instructions

Render a formatted bibliography or in-text citations for a set of Zotero items using Zotero's own CSL citation engine, so you can drop references straight into a manuscript. item_keys: optional list of 8-character item keys (also accepts a JSON list string); takes precedence over collection_key. collection_key: optional collection to export instead; if neither is given, the active library is exported (capped). style: CSL style short name (default 'apa'); e.g. 'modern-language-association', 'chicago-note-bibliography', 'ieee'. Ignored for bibtex. export_format: 'bib' (formatted reference-list entries, default), 'citation' (in-text citation strings), or 'bibtex' (raw BibTeX for .bib files). Output: markdown naming the style/format, then the rendered entries (a fenced block for bibtex, a numbered list otherwise). Rendering uses Zotero's own CSL engine and works in local mode with no API credentials, as well as over the web API. Capped at 100 items per call; scope with item_keys or collection_key for anything larger. Example: zotero_export_bibliography(item_keys=['RTKZQI8E'], style='apa', export_format='bib').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
styleNoCSL style short name (default "apa").apa
item_keysNoOptional list of item keys (or JSON/comma string).
export_formatNo"bib", "citation", or "bibtex".bib
collection_keyNoOptional collection to export.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that rendering works in local mode with no API credentials and over the web API, mentions the 100-item cap, describes the output structure (markdown naming the style/format, then a fenced block for bibtex or a numbered list otherwise), and notes that style is ignored for bibtex. It does not mention error handling or side effects, but the tool is clearly read-only and non-destructive, so this is adequate.

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 dense but well-structured: a purpose sentence, then parameter explanations, output details, mode/cap constraints, and an example. Every sentence adds useful information, and the structure is logical, though it could be broken into paragraphs for readability. It is not bloated given the complexity of the tool.

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 covers everything an agent needs to invoke the tool correctly: purpose, parameter semantics with precedence, defaults, output format, mode of operation, cap, and a concrete example. Even though an output schema is mentioned in context, the description itself fully specifies the return format, making it self-contained.

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 input schema already has 100% description coverage, so the baseline is 3. The description adds substantial extra value: item_keys accepts a JSON list string, precedence over collection_key, style examples, export_format details, and specifics about the output format. This goes well beyond the schema's terse descriptions, helping the agent understand usage nuances.

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 a specific verb+resource: 'Render a formatted bibliography or in-text citations for a set of Zotero items using Zotero's own CSL citation engine.' It clearly states the tool's function and its use case (dropping references into a manuscript). It is distinct from sibling tools, which are all search/retrieval or annotation tools, making this the only export/rendering tool.

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 provides explicit guidance on parameter selection: item_keys takes precedence over collection_key, and if neither is given, the active library is exported (capped). It also notes the 100-item cap and advises scoping with item_keys or collection_key for larger sets. It doesn't explicitly state when not to use this tool versus alternatives, but no sibling offers this capability, so the guidance is sufficient.

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