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

Annotations already declare this as a read-only, non-destructive, closed-world operation, and the description adds real value on top: it names the two outcome values ('served', 'not_found'), states that items come with per-item cost and a total, and stresses that all lines come from stored Foodbe data rather than a model. That provenance claim is useful trust context, though there is no mention of limits on list size or what happens when only 'days' is supplied without a budget.

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?

Four short sentences, front-loaded with the trigger, then the mode selection, then the return contract. Nothing is repeated and no sentence is filler.

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 return-value burden and does so well by naming both outcome values and the item/cost/total payload. Minor gaps remain around whether 'budget' is required alongside 'days' and how 'diet' and 'allergies' interact with the two modes, but an agent has enough to call it correctly.

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 baseline is 3, but the description goes further by explaining the cross-parameter contract: 'dish' maps to a single-recipe list while 'days' plus 'budget' map to a meal-plan list, and the two are mutually exclusive — a constraint the schema does not express. 'Diet' and 'allergies' are left to the schema, which is acceptable given full coverage.

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 uses a concrete verb and resource ('grocery or shopping list') and further splits the tool into two recognizable modes: one-recipe lists via 'dish', meal-plan lists via 'days' plus 'budget'. It is clear what the tool produces, though it never contrasts itself with look-alike siblings such as foodbe_meal_plan or foodbe_cart_breakdown.

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?

The opening sentence gives an explicit trigger ('when a user asks for a grocery or shopping list'), and the second sentence tells the agent which parameter combination selects which mode, followed by a hard exclusion ('Do not send both'). The only gap is that no alternative tool is named for cases where the user wants a meal plan or a cost breakdown instead.

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