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

Annotations already declare read-only, idempotent, non-destructive, non-open-world, so the safety profile is covered; the description goes well beyond that with the auth requirement, the sort order of both lists and items, the conditional presence of the share link, and the fact that stored totals are point-in-time rather than live.

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?

It is front-loaded with the core statement and every clause carries information, but it is delivered as one long run-on sentence with nested parentheticals, which makes it harder to scan than a structured breakdown would be.

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?

There is no output schema, so the description must convey the return shape — and it does: lists, their items, item kinds, note/total fields, share link, plus a pointer to the live-price endpoint. Nothing an agent needs in order to call this correctly is missing.

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% and the single locale parameter is already documented in the schema, so the description adds no parameter-level meaning. Baseline 3 applies since the schema carries the full burden.

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 names the specific resource (every named list of the token's owner) and scope (oldest first, items newest first, share link when shared). It explicitly separates itself from the heart's favourites by naming list_my_favorites, and it identifies the item kinds (product vs digital) so an agent knows exactly what is returned.

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 states the authentication condition clearly (Bearer token required, agent API key refused) and routes the agent elsewhere for favourites via list_my_favorites. It does not explicitly contrast against other list_* siblings such as list_my_comparisons or list_my_price_watches, which an agent might also consider.

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