Save Nutrition Plan

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

No annotations are provided, so the description carries the full burden. It explicitly reveals the destructive replacement behavior — 'REPLACES whatever plan currently exists (deleting it and its days/meals)' — and the exactly-one-active-plan invariant. It doesn't mention return values or error conditions, but the critical mutation semantics are transparent.

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 description is two sentences with the most critical fact — replacement/deletion — front-loaded in the first sentence. The second sentence is dense but every clause earns its place: usage distinction, alternatives, and prerequisite checks. No filler or redundancy.

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?

The description covers the destructive behavior, when to use it, and prerequisite data to gather. It does not explicitly warn that sending a partial days array could replace a full existing plan with an incomplete one, even though the schema says 'The full week' — a meaningful edge case for correct invocation. Overall strong, with one notable gap.

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%, so the baseline of 3 applies. The description doesn't add parameter-level syntax or field details beyond the schema, though it does add contextual meaning about the plan reflecting the user's training and goals. This is useful but doesn't go beyond what schema descriptions already provide.

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 specific verb and resource: 'Creates the week's nutrition plan.' It also clearly differentiates from siblings by explicitly noting that this tool REPLACES the existing plan rather than creating a second one, and names the update_nutrition_* tools for tweaks. An agent can immediately tell when this tool is the right choice.

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 gives explicit when-to-use guidance: use this to generate/regenerate the whole week; for smaller tweaks, prefer update_nutrition_meal / update_nutrition_day / update_nutrition_plan so the rest of the week isn't thrown away. It also instructs checking get_training_preferences and ideally get_workout_history/get_recovery_status before calling, covering prerequisite context.

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