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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), yet the description still adds substantive behavior: the Subscriber gate, the fact that pantry staples are only counted once a human marks them `active`, and how `contributions` attribute amounts to recipe entries vs. hand entry. Nothing here contradicts the annotations, and the business rules about counting are things no schema could convey.

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?

The entitlement requirement is front-loaded before the return-value breakdown, and every bullet carries information an agent needs to interpret the response (`id`, `category`, `active`, `contributions`, `unit_price` math). It is dense but not padded; the only cost is that the return-shape detail crowds out any explicit usage sentence.

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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly – field-by-field semantics for items, contributions, recipes, and the price formula including the price_by_weight case. Combined with the Subscriber prerequisite, an agent has everything needed to call it and interpret the result.

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?

This is a single-parameter tool with 100% schema description coverage, and the schema already explains that session_token comes from check_agent_connection and can instead travel as a Bearer header. The description adds nothing about that parameter, so the baseline of 3 applies – the schema does all the work.

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 opening phrase names the exact resource and scope ("The connected account's whole grocery list"), which implicitly distinguishes it from any filtered or partial view, and the body enumerates precisely what is returned (`items`, `recipes`, `total_cost`). It even routes the reader to the sibling mutators (remove_grocery_list_item, remove_recipe_from_grocery_list) that consume the returned ids, so an agent can place it in the sibling landscape without opening any schema.

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?

"requires Subscriber" states the entitlement precondition up front, and the body makes clear this is the unfiltered whole-list read whose ids feed the remove_* tools. There is no explicit when-not-to-use or named alternative (e.g. vs. get_meal_plan_details), so it falls just short of full routing guidance.

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