Skip to main content
Glama

update_goal

Destructive

UNIT INPUTS: never convert units yourself. For each canonical field below, pass the user's number exactly as stated when it is already in the canonical unit; when they gave the alternate unit instead, pass the same number unconverted and set the matching companion field so the tool converts once before storage. Omit the companion when the number is already canonical. This overrides any wording that asks you to do the arithmetic.

  • _lb fields: lb, or kg with input_weight_unit set.

  • _mi fields: mi, or km with input_distance_unit set.

  • _in fields: in, or cm with input_length_unit set.

  • _stated_g fields: g, or oz with input_mass_unit set.

  • _stated_ml fields: ml, or fl_oz with input_volume_unit set.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoConcise title, inferred from the goal inputs.
weeksNoFor weight_loss. Duration in weeks when target_date is not supplied. For body_comp. Duration in weeks when target_date is not supplied.
actionYesWhat 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.
metricNoFor 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_idNoFormal goal ID, when known.
goal_refNoNatural-language reference when no ID is known, e.g. "protein", "10K", "weight loss". This tool resolves it against current goals itself.
new_nameNoFor n1_experiment. Name for a new supplement when not using supplement_id.
new_brandNoFor n1_experiment. Optional brand for a new supplement.
race_dateNoFor race. Race date in YYYY-MM-DD format. Required on create.
start_dateNoYYYY-MM-DD. Default: today.
start_valueNoFor body_comp. Starting value when the goal begins. Required on create. Set at create, not editable later.
target_dateNoFor 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_windowNoFor 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_lbNoFor 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_hoursNoFor consistency. Nightly sleep target in hours. Required when metric is sleep_duration.
target_valueNoFor 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_nameNoFor strength. Exercise name. Required on create. Set at create, not editable later.
new_dose_unitNoFor n1_experiment. Dose unit for a new supplement.
supplement_idNoFor n1_experiment. Existing supplement ID. Use either supplement_id or the new-supplement fields.
target_1rm_lbNoFor strength. Target 1RM. Required on create. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
new_dose_amountNoFor n1_experiment. Dose amount for a new supplement.
start_weight_lbNoFor 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_weekNoFor consistency. Target occurrences per week. Required on create.
target_time_secNoFor race. Target finish time in seconds. Required on create.
target_weight_lbNoFor weight_loss. Target body weight. Required on create. In lb, or kg with input_weight_unit set. See UNIT INPUTS.
input_weight_unitNoSet to kg when the user gave kg for the _lb fields in this object. Omit when they are already lb.
intervention_daysNoFor n1_experiment. Intervention duration in days.
baseline_directionNoFor n1_experiment. Use already logged previous 14 days or collect the next 14 days.
target_distance_miNoFor race. Target race distance. Required on create. In mi, or km with input_distance_unit set. See UNIT INPUTS.
input_distance_unitNoSet to km when the user gave km for the _mi fields in this object. Omit when they are already mi.
acknowledged_warningsNoWarning keys the user explicitly acknowledged after a guarded create attempt. Omit otherwise.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesHuman-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (destructiveHint=true, idempotentHint=false). The description adds valuable behavior beyond that: it resolves goal_ref against current goals itself, returns candidates and changes nothing on ambiguous matches, follows the existing cancel lifecycle, and explains that standard-target end/pause turns a target off while delete removes it. It also discloses the unit-conversion override behavior. Only minor gaps (e.g. auth needs) remain.

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 purpose sentence and the list_goals exclusion are front-loaded and efficient. However, the lengthy UNIT INPUTS block consumes roughly half the description and largely restates the per-parameter schema text and companion-field descriptions, reducing signal density for the primary use case.

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?

Given 31 parameters, an output schema present, and rich annotations, the description covers the essential orchestration behavior (direct call, internal resolution, ambiguous-match handling, action semantics) that the agent cannot get from structured fields alone. It is adequately complete; the return-value explanation is rightly delegated to the output schema.

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 the baseline is 3. The description nonetheless adds meaning beyond the schema by defining the cross-cutting UNIT INPUTS contract and the companion-field convention across the whole _lb/_mi/_in family, which the schema only references per-field. It also clarifies that goal_ref resolves internally and multi-matches produce candidates.

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 a specific set of verbs (change, complete, pause, stop/end, reopen, delete) on a specific resource (an existing goal). Clearly distinguishes itself from sibling create_goal and list_goals by naming the latter outright as unnecessary. An agent can tell exactly what this tool is for.

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 to call this directly for ordinary changes and NOT to call list_goals first. It states which actions need edit fields (edit) and which don't (complete/pause/end/reopen/delete), and describes the multi-match resolution behavior. This is direct when/when-not/alternative guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.