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

Annotations already declare this is a non-read-only, non-idempotent, open-world but non-destructive creation call, so the safety profile is covered. The description adds the useful behavioral fact that two creation paths exist – seed from a template or supply name/words directly – and that a shelf is a personal container. It stays silent on what happens on duplicate names, why the visibility name check exists, and what an agent gets back to reference the new shelf.

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?

Three short sentences: what it creates and for which use cases, the two configuration paths, and the routing to add_to_shelf. Every clause carries information and the use-case parenthetical is front-loaded rather than buried.

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?

With 9 optional parameters including nested objects and enums, plus no output schema, the definition leans heavily on the fully documented schema and covers the intent side well. The material gap is the return contract: since there is no output schema, an agent is never told whether it receives an id or slug needed to call add_to_shelf or edit_shelf_entry next.

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 description coverage is 100%, so every one of the 9 parameters is already documented at the field level, making 3 the baseline. The description adds only a light framing of the template-vs-manual tradeoff (a template sets noun, status words, fields, sessions), which the schema already conveys per-field. No extra constraint such as template overriding other params is spelled out.

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?

"Make a shelf of their own for something the library's kinds don't cover" states a concrete verb (make/create) plus resource (shelf) and scopes the resource to items the existing kinds don't handle. It separates itself from add_to_shelf, which it explicitly routes to for entries. It does not distinguish itself from the sibling create_list, so the shelf-vs-list boundary is left implicit.

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?

"Offer one when they want to keep track of such things" plus the parenthetical list of uncovered kinds gives a concrete trigger condition, and "add entries with add_to_shelf" names the correct follow-up tool. The negative condition is implied rather than explicit – it never says to prefer the built-in library kinds (books, movies) when those already fit.

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