Wellness Project

update_goal

Destructive

UNIT INPUTS: value: pass the user's number unconverted; tool converts once before storage. alternate_unit: set the field's matching input_* companion; canonical_unit: omit companion. precedence: overrides instructions to convert manually.

Change, complete, pause, stop/end, reopen, or delete an existing goal. Call this tool directly for ordinary goal changes. It already loads the user's current goals and resolves a unique goal from goal_id or a natural-language goal_ref, so do NOT call list_goals first just to find an ID.

For edit, pass only the fields to change. For complete/pause/end/reopen/delete, no edit fields are required. If goal_ref genuinely matches multiple goals, this tool returns the candidates and changes nothing. Formal goal end/delete follows the existing Goals UI cancel lifecycle; standard-target end/pause turns that target off while delete removes it.

WEIGHT INPUTS: For a body_weight_target_lb standard target or body_comp metric lean_mass_lb, edit with target_value_lb. This alias is unit-aware; in-app calls use the preferred unit, while external calls use pounds unless input_weight_unit is set. Legacy generic target_value remains canonical pounds.

Input Schema

Name	Required	Description
`title`	No	Concise title, inferred from the goal inputs.
`weeks`	No	For weight_loss. Duration in weeks when target_date is not supplied. For body_comp. Duration in weeks when target_date is not supplied.
`action`	Yes	What to do. 'end' when the user is stopping or canceling a goal; for a formal goal that follows the app's cancel behavior and removes it.
`metric`	No	For consistency. What consistency behavior to track. Required on create. Set at create, not editable later. For body_comp. Body composition metric. Required on create. Set at create, not editable later. For nutrition. Legacy nutrition metric.
`goal_id`	No	Formal goal ID, when known.
`goal_ref`	No	Natural-language reference when no ID is known, e.g. "protein", "10K", "weight loss". This tool resolves it against current goals itself.
`new_name`	No	For n1_experiment. Name for a new supplement when not using supplement_id.
`new_brand`	No	For n1_experiment. Optional brand for a new supplement.
`race_date`	No	For race. Race date in YYYY-MM-DD format. Required on create.
`start_date`	No	YYYY-MM-DD. Default: today.
`start_value`	No	For body_comp. Starting value when the goal begins. Required on create. Set at create, not editable later.
`target_date`	No	For weight_loss. Target date in YYYY-MM-DD format. Use this when the user names a deadline. For body_comp. Target date in YYYY-MM-DD format. Use this when the user names a deadline.
`week_window`	No	For consistency. How the week this goal is measured against is bounded: rolling = the last 7 days, sunday/monday = a calendar week that resets on that day. Default: rolling.
`start_1rm_lb`	No	For strength. Estimated 1RM when the goal starts. Required on create. Set at create, not editable later. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`target_hours`	No	For consistency. Nightly sleep target in hours. Required when metric is sleep_duration.
`target_value`	No	For body_comp. Target body composition value. Required on create. For nutrition. Legacy nutrition target value. For standard targets, this is the numeric target value.
`exercise_name`	No	For strength. Exercise name. Required on create. Set at create, not editable later.
`new_dose_unit`	No	For n1_experiment. Dose unit for a new supplement.
`supplement_id`	No	For n1_experiment. Existing supplement ID. Use either supplement_id or the new-supplement fields.
`target_1rm_lb`	No	For strength. Target 1RM. Required on create. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`start_value_lb`	No	Starting lean mass in body_comp. See WEIGHT INPUTS above. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`new_dose_amount`	No	For n1_experiment. Dose amount for a new supplement.
`start_weight_lb`	No	For weight_loss. Starting body weight. Required on create. Set at create, not editable later. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`target_per_week`	No	For consistency. Target occurrences per week. Required on create.
`target_time_sec`	No	For race. Target finish time in seconds. Required on create.
`target_value_lb`	No	Weight goal target. See WEIGHT INPUTS above. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`target_weight_lb`	No	For weight_loss. Target body weight. Required on create. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
`input_weight_unit`	No	Set to kg when the user gave kg for the _lb fields in this object. Omit when they are already lb.
`intervention_days`	No	For n1_experiment. Intervention duration in days.
`baseline_direction`	No	For n1_experiment. Use already logged previous 14 days or collect the next 14 days.
`target_distance_mi`	No	For race. Target race distance. Required on create. In mi, or km with input_distance_unit set. See UNIT INPUTS.
`input_distance_unit`	No	Set to km when the user gave km for the _mi fields in this object. Omit when they are already mi.
`acknowledged_warnings`	No	Warning keys the user explicitly acknowledged after a guarded create attempt. Omit otherwise.

Output Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 9, 2026

addedInput schema / properties / start_value_lb

Added value: +{
+  "description": "Starting lean mass in body_comp. See WEIGHT INPUTS above. In lb, or kg with input_weight_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

addedInput schema / properties / target_value_lb

Added value: +{
+  "description": "Weight goal target. See WEIGHT INPUTS above. In lb, or kg with input_weight_unit set. See UNIT INPUTS.",
+  "type": "number"
+}

AddedSep 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds real value beyond them: it discloses the multi-match behavior ('returns the candidates and changes nothing'), the cancel-lifecycle semantics for end/delete, and the target-level vs goal-level effect of pause/delete. It doesn't spell out irreversibility or permission needs, keeping it just below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core behavioral paragraph is well front-loaded and earns its place, but the pre-pended UNIT INPUTS and WEIGHT INPUTS blocks are repetitive with schema descriptions and make the definition read like a patch note rather than a description. Moderate waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the action matrix, ambiguity handling, unit conventions, and the no-need-to-list_goals directive – enough for a 33-param mutation tool with destructiveHint. Output schema exists so return values needn't be explained. Missing only explicit versioning/idempotency caveats, which is a minor gap given annotation coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description goes beyond by explaining UNIT INPUTS convention (value unconverted, input_* companion, input_weight_unit), the pounds-vs-preferred-unit rule for target_value_lb/target_value, and the edit-only-fields rule – genuinely useful semantics the schema doesn't state. A bit dense but adds real meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the exact set of verbs (change, complete, pause, stop/end, reopen, delete) against the resource 'existing goal', and distinguishes itself from list_goals and create_goal by naming the sibling it replaces. An agent knows exactly which lifecycle operation it's invoking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this tool directly for ordinary goal changes... do NOT call list_goals first just to find an ID,' names edit-vs-complete/pause/end requirements, and describes ambiguity handling (returns candidates, changes nothing). This is the strongest form of when/when-not guidance.

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

All Wellness Project tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.