Zotero Get Collections

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

With no annotations provided, the description carries full behavioral disclosure. It covers the hierarchical output, the 8-character key format, the lack of truncation for deep trees (with the consequence that output may be long), the limit behavior (default 100, up to 5000), and the include_trashed behavior (annotated as [trashed], default matching the desktop view). No contradictions with annotations were found.

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?

Every sentence serves a purpose: purpose, usage guidance, scope caveat, output length warning, parameter explanations, and a concrete example. The front-loaded purpose sentence immediately tells an agent what this tool is for. The example output makes the return format tangible with no wasted words.

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?

The description covers the essential context for both selection and invocation: what the tool returns, its scope, how to change scope, parameter behavior, and a representative example. An output schema exists, so return-value documentation is not needed. No significant gaps remain for the agent to resolve through trial and error.

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%, so the schema already documents both parameters. The description adds practical context: passing None for limit uses 100, and raising to 5000 is suggested for large libraries. For include_trashed, it restates the default but reinforces the desktop-matching semantics already present in the schema. This goes slightly beyond the baseline without adding non-essential detail.

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?

The description opens with a specific verb ('List all collections') and a precise resource scope (the currently active Zotero library, as a hierarchical tree with 8-character keys). It also explicitly distinguishes itself from zotero_search_collections, which finds single matches by name, leaving no ambiguity about what this tool does.

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?

It tells the agent when to use this tool ('when the user wants to see the full library structure') and when to prefer an alternative ('If you already know a name and just need the key, prefer zotero_search_collections'). It also instructs the agent to switch libraries with zotero_switch_library if the active library is not the desired scope.

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