Wellness Project

create_goal

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.

Create a new Wellness Project goal or standard target. Call this directly when the user wants to establish a goal; there is no schema-discovery or list_goals prerequisite. Available goal types and inputs come from the canonical Goals definitions.

This tool loads the user's current goals itself before writing, so do not call list_goals first: it reports what a standard target changed from, and refuses to stack a second goal on top of one that already covers the same thing, naming that goal's ID to use with update_goal. Infer the goal_type and canonical inputs from the request. Standard targets use target_value. Formal goal fields are described on the generated inputs.

Input Schema

TableJSON 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.
`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.
`new_name`	No	For n1_experiment. Name for a new supplement when not using supplement_id.
`goal_type`	Yes	Goal type to create.
`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.
`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_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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

changedInput schema / properties / goal_type / enum

Previous value: -[
-  "weight_loss",
-  "strength",
-  "consistency",
-  "body_comp",
-  "race",
-  "n1_experiment",
-  "daily_calories",
-  "daily_protein_g",
-  "daily_fat_g",
-  "daily_carbs_g",
-  "weekly_workouts",
-  "daily_steps",
-  "weekly_azm_target",
-  "sleep_hours_target",
-  "body_weight_target_lb",
-  "body_fat_pct_target"
-]New value: +[
+  "weight_loss",
+  "strength",
+  "consistency",
+  "body_comp",
+  "race",
+  "n1_experiment",
+  "daily_calories",
+  "daily_protein_g",
+  "daily_fat_g",
+  "daily_carbs_g",
+  "weekly_workouts",
+  "daily_steps",
+  "daily_cycling_distance_mi",
+  "weekly_azm_target",
+  "sleep_hours_target",
+  "body_weight_target_lb",
+  "body_fat_pct_target"
+]

AddedSep 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds meaningful non-obvious behavior: it loads existing goals itself, reports what a standard target changed from, and refuses duplicate/stacked goals by naming an ID. It does not mention auth requirements or rate limits, and does not explain what the output contains, but the duplicate-detection and self-loading behavior is genuinely useful context beyond annotations.

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 UNIT INPUTS block is front-loaded but occupies roughly half the description with a repeated per-category list that could be condensed. The core purpose and usage statements come after, and there is some redundancy ('there is no schema-discovery or list_goals prerequisite' overlaps with the later 'do not call list_goals first'). It is information-rich but not tight.

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?

For a 29-parameter creation tool with 100% schema coverage and an output schema, the description covers the key operational behavior (unit handling, duplicate refusal, no list prerequisite) that the schema cannot. It stops short of explaining goal_type inference rules or the full set of canonical inputs, deferring to 'the canonical Goals definitions,' but what is present is sufficient for an agent to invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and every parameter's description already explains its purpose, unit, and when required. The description adds the UNIT INPUTS protocol, which is a real value-add: it tells the agent to pass numbers unconverted and set companion fields for kg/km/cm/oz/fl_oz. However, it omits explanation of many other parameters (goal_type, metric, weeks, etc.) and the unit block is somewhat repetitive with the schema's per-field unit notes.

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

Purpose4/5

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

The description states a specific verb+resource: 'Create a new Wellness Project goal or standard target.' It distinguishes itself from list_goals and update_goal by saying when to call it directly and that there is no list prerequisite. However, it does not define what a 'Wellness Project goal' or 'standard target' is, and the description is cluttered with a long unit-input preamble that dilutes the core statement.

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 when to call it (user wants to establish a goal), which prerequisite tools NOT to call (no schema discovery, no list_goals), and what happens on conflict (refuses to stack and names the existing goal ID to use with update_goal). It also routes the agent to the generated inputs for formal fields. This is strong 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.