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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond those flags: the plan is deterministic, computed from the basket's scheduling metadata, and returns unplaceable items with reasons. It also reinforces that the tool does not mutate the basket, which matches and augments the annotations.

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 sentences carry a lot of information: the core output, the computation source, the return payload, the scope restriction, and the pipeline order. There is a slight stylistic flourish in 'The moment the package becomes a year,' but it is not wasted. The description is front-loaded with the result and does not repeat annotations.

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?

Despite having no output schema, the description tells the agent what the tool returns: placed months, the recurring-every-month layer, and unplaceable items with reasons. It also states the scope constraint and pipeline position. It could say more about how start_month or anchors influence output, but the essentials for correct invocation are covered.

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?

The schema already documents all four parameters, and context description is unusually detailed. The description adds the concept of the 'basket' mapping to item_ids and mentions scheduling metadata as the computation basis, but it does not provide deeper per-parameter guidance. With schema coverage at 75%, the description is adequate but does not go beyond what the schema supplies.

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 states a precise verb and resource: it produces a deterministic month-by-month plan of what lands when for a basket. It clearly distinguishes itself from siblings by explicitly saying the plan contains ONLY items in the basket and never adds or moves an event, which is different from customize_package and request_offer.

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 description gives explicit pipeline positioning: 'Call after customize_package, before request_offer.' It also implies when not to use the tool by warning against adding or moving events. It does not list every sibling alternative, but the sequencing is unambiguous and actionable.

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