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

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered; the description adds genuinely new behavior: pickups are scheduled a few days ahead, the customer can skip or pause any time, and it produces real recurring orders. What's missing is any statement about billing/recurring charges despite the card requirement, which matters for a destructive recurring commitment.

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 prerequisite before the action, with zero redundant restatement of the schema. The closing 'This creates real recurring orders' is slightly redundant with 'standing pickup' but functions as a deliberate warning, so it earns most of its place.

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?

For a 3-parameter tool with no output schema and annotations covering the safety profile, the description covers prerequisite, action, scope (default address), lead time, and post-creation control. Gaps remain around what the tool returns and whether setup triggers an immediate charge, but nothing essential for invoking it correctly is absent.

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%, including enum defaults for service and frequency, so the schema carries the parameter burden and a 3 is the baseline. The description adds only 'e.g. every Tuesday', which lightly illustrates daysOfWeek but gives no guidance on combining multiple days with frequency.

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?

States a specific verb and resource: 'Creates a standing pickup ... at the customer's default address', with the recurring nature made explicit via 'standing' and 'real recurring orders'. This implicitly separates it from one-off siblings like book_my_pickup and from update_recurring_pickup, but neither sibling is named, so the differentiation is left to inference.

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?

Gives a concrete precondition — the connected Fold account must have a saved address and card — which is exactly the kind of gate an agent needs before calling. It also implies the use case ('every Tuesday', standing arrangement) but never explicitly says when to prefer this over book_my_pickup or update_recurring_pickup, so no exclusions are provided.

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