Zotero Get Item Metadata

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

No annotations are provided, so the description carries the full disclosure burden — and it meets it thoroughly. It surfaces the surprising behavior that trashed items ARE returned, that a 'Status: In Trash' line is shown, and that collection membership is exposed as keys rather than counts, even explaining the API root cause ('the Zotero API does not cascade collection-delete to items, so dangling references can linger'). It also discloses format-specific quirks like include_abstract being ignored in bibtex/json.

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

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

Dense but every sentence earns its place: core purpose first, then alternative routing, then parameter clarifications, then edge cases, closing with a concrete example invocation. The key-format warning and fulltext-cost caution each prevent a distinct real failure mode, and the example ties the format parameter to a realistic call.

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

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

Covers the full decision space for an agent: primary function, when to defer to fulltext vs search tools, param semantics, library scope, trash/collection edge cases, and a worked example. With an output schema present, omitting detailed return-value descriptions is appropriate and keeps the description complete without redundancy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, setting the baseline at 3, but the description adds meaning beyond the schema. The item_key warning ('8-character Zotero item key (NOT a DOI or title)') prevents a common agent error, and format outputs are characterized more richly ('sufficient for .bib files', 'complete raw Zotero item record'). The only reason it is not a 5 is that the schema already documents most parameter behavior well, leaving the description to add clarifications rather than foundational semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Fetch detailed metadata (title, creators, date, DOI, publisher, tags, abstract, URL, etc.) for ONE Zotero item by key.' The emphasis on 'ONE' distinguishes it from list endpoints, and naming zotero_get_item_fulltext as the sibling for reading full text clarifies what this tool is not. No ambiguity remains about what is fetched, for how many items, or by what identifier.

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

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

Gives explicit routing conditions: 'call zotero_get_item_fulltext' when metadata is insufficient, and 'should NEVER be used for searching; use zotero_search_items or zotero_semantic_search instead.' It also announces the active-library-only scope with a pointer to zotero_switch_library, leaving no doubt about when this tool applies versus its alternatives.

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