Skip to main content
Glama
54yyyu
by 54yyyu

zotero_delete_item

Move any Zotero item (books, articles, attachments, webpages) to the Trash. Items stay recoverable until the Trash is emptied; notes are protected by default and require explicit override.

Instructions

Move a Zotero item to the Trash. Works for any item type (book, journalArticle, webpage, attachment, etc.). For notes, use zotero_manage_note(action='delete') — identical mechanism, constrained to notes for safety. Trashed items are recoverable from Zotero's Trash — empty the Trash in the Zotero UI for permanent deletion. By default refuses to trash notes; set allow_note=True to override.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
item_keyYesZotero item key/ID to trash
allow_noteNoIf True, permits trashing note items. Default False directs callers to zotero_manage_note(action='delete') for notes (same mechanism, explicit about what it affects).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.4
    • changedInput schema / properties / allow_note / description
      Previous value: -"If True, permits trashing note items. Default False\ndirects callers to zotero_delete_note for notes (which has the\nsame mechanism but is explicit about what it affects)."New value: +"If True, permits trashing note items. Default False\ndirects callers to zotero_manage_note(action='delete') for\nnotes (same mechanism, explicit about what it affects)."
  2. Addedv0.4.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains that the action moves to Trash rather than permanently deleting, that items are recoverable, that permanent deletion requires emptying the Trash in the UI, and that note deletion is guarded until allow_note=True. This is strong transparency for a mutation tool.

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

Conciseness5/5

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

The description is three sentences with no filler. The primary action is front-loaded, and each subsequent sentence adds essential operational detail: item type coverage, the safe alternative for notes, and recoverability/permanence behavior.

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?

For a two-parameter tool with a full output schema, the description covers the core behavior, the key edge case (notes), the safety override, and the recovery path. It is sufficiently complete for an agent to select and invoke the tool correctly without needing additional context.

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 schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema by clarifying the default refusal behavior for notes and the intended use of allow_note, thereby enriching the parameter semantics.

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 and resource: 'Move a Zotero item to the Trash.' It states the scope ('any item type') and explicitly distinguishes the note case by routing to zotero_manage_note, making it easy to differentiate from delete-related siblings like zotero_delete_annotation.

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

Usage Guidelines5/5

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

The tool explicitly states when not to use it ('By default refuses to trash notes') and identifies the alternative (zotero_manage_note(action='delete')), including the condition under which the alternative is preferred. This is direct, actionable usage guidance.

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