Skip to main content
Glama
turnnoblindeye

Wellness Project MCP

create_goal

Sets up a new wellness goal or standard target for weight, strength, consistency, body composition, race, or nutrition, without requiring prior setup.

Instructions

UNIT INPUTS: never convert units yourself. Pass the user's number for a _lb / _mi / _in field exactly as stated, and when they gave kg / km / cm set input_weight_unit / input_distance_unit / input_length_unit in that same object. Omit the companion when the number is already lb / mi / in. The tool converts once before storage, so this overrides any wording that asks you to do the arithmetic.

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
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.
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.
new_nameNoFor n1_experiment. Name for a new supplement when not using supplement_id.
goal_typeYesGoal type to create.
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. Dates show when Glama detected each change.

  1. First observedv1.2.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description aligns with a creating/writing operation. It additionally discloses behavioral details: the tool loads current goals itself, refuses to stack duplicate goals, reports what a standard target changed from, and supports acknowledged warnings. Minor gap: no explicit statement about persistence or side effects beyond creation, but annotations cover the general write nature.

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

Conciseness4/5

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

The description is organized into three focused paragraphs and avoids unnecessary filler. It is slightly repetitive with the 'See UNIT INPUTS' references and the phrase 'Required on create / Set at create, not editable later', but these repetitions serve clarity in a large parameter surface and do not harm usability.

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 the large number of parameters (29) and the existence of an output schema, the description does not need to explain every field individually; the schema handles that. It does provide important contextual guidance on unit conversion, duplicate prevention, and when to omit list_goals. A small gap is that it references 'canonical Goals definitions' without embedding them, but this is acceptable given the schema already enumerates valid goal_type values.

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

Parameters5/5

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

Schema description coverage is 100% and each parameter includes targeted descriptions referencing relevant goal types. The description also gives important cross-cutting semantics for unit fields (input_weight_unit/input_distance_unit) and clarifies required-on-create versus not-editable-later fields. This goes well beyond the raw schema.

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?

The description clearly states the tool's purpose: 'Create a new Wellness Project goal or standard target' and specifies when to call it directly. It names the primary action (create) and the resource (goal), leaving no ambiguity about what the tool does.

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?

The description provides explicit usage guidance: call directly when establishing a goal, no prerequisite schema discovery or list_goals call is needed. It also warns against calling list_goals first and explains the tool's built-in duplicate guard, which is actionable and relevant.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turnnoblindeye/wellness-project-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server