Wellness Project

log_run

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.

RUNNING ONLY: use log_run only for running on foot. A bike/cycling ride, walk, or rowing session is not a run even when it has distance and duration. For those, use log_workout with focus_type Cycling, Walking, or Rowing plus the user's native distance field and duration_sec.

Create an editable running card. Use for a completed run OR a future run plan.

intent:

log (default): the run happened. date, distance_mi and duration_sec are required. This writes the completed run and returns a card marker for in-app editing.
plan: the run has NOT happened yet. Create a planned run card. Never put a future run in completed history.

RUN TYPE: distinguish easy, long, tempo, interval, recovery, race, fartlek, threshold, progression and hills when the runner or workout structure supports it. If a wearable run is unspecified, do NOT call it easy merely because it was a run.

DETAIL: preserve elapsed time, HR, cadence, power, elevation, RPE, splits and structured segments only when supplied by the user/source. Never invent sensor data or splits.

Input Schema

TableJSON Schema

Name	Required	Description
`rpe`	No	RPE 1-10. For a plan this is target RPE.
`date`	No	YYYY-MM-DD. Completed runs default to today when context allows; planned runs use the intended date when known.
`notes`	No
`avg_hr`	No	Average heart rate only when known.
`intent`	Yes	log = completed run; plan = future run. Elias uses plan for a workout the runner has not done yet.
`splits`	No	Actual splits/laps only when supplied by the runner/source. Never invent.
`surface`	No
`run_type`	No	Classify only when the runner or workout structure supports it. Do not turn an unspecified wearable run into easy.
`segments`	No	Workout structure, e.g. warmup, 6x800m threshold, recovery, cooldown. This may describe a plan or what was actually performed.
`pain_notes`	No	Pain/discomfort exactly as the runner described it.
`start_time`	No	Local HH:MM only when known.
`avg_power_w`	No	Average running power in watts only when known.
`distance_mi`	No	Distance. In mi, or km with input_distance_unit set. See UNIT INPUTS.
`elapsed_sec`	No	Wall-clock elapsed time including pauses, only when known.
`duration_sec`	No	Moving/workout duration in seconds.
`avg_cadence_spm`	No	Average running cadence in steps/min only when known.
`elevation_gain_m`	No	Elevation gain in metres only when known.
`perceived_effort`	No	Post-run check-in only.
`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.

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.

Changed21 schema fields changedSep 7, 2026

addedInput schema / properties / avg_cadence_spm

Added value: +{
+  "description": "Average running cadence in steps/min only when known.",
+  "type": "number"
+}

changedInput schema / properties / avg_hr / description

Previous value: -"Average heart rate. Optional — include if the user mentions it."New value: +"Average heart rate only when known."

addedInput schema / properties / avg_power_w

Added value: +{
+  "description": "Average running power in watts only when known.",
+  "type": "number"
+}

changedInput schema / properties / date / description

Previous value: -"Date of the run. Format: YYYY-MM-DD. Required — default to today."New value: +"YYYY-MM-DD. Completed runs default to today when context allows; planned runs use the intended date when known."

changedInput schema / properties / distance_mi / description

Previous value: -"Distance in MILES, always — regardless of the user’s display unit. Convert from km if needed (km ÷ 1.609344). Required."New value: +"Distance. In mi, or km with input_distance_unit set. See UNIT INPUTS."

changedInput schema / properties / duration_sec / description

Previous value: -"Duration in seconds. Required — convert from whatever format the user provides (minutes, h:mm:ss, etc)."New value: +"Moving/workout duration in seconds."

addedInput schema / properties / elapsed_sec

Added value: +{
+  "description": "Wall-clock elapsed time including pauses, only when known.",
+  "type": "integer"
+}

addedInput schema / properties / elevation_gain_m

Added value: +{
+  "description": "Elevation gain in metres only when known.",
+  "type": "number"
+}

addedInput schema / properties / input_distance_unit

Added value: +{
+  "description": "Set to km when the user gave km for the _mi fields in this object. Omit when they are already mi.",
+  "enum": [
+    "mi",
+    "km"
+  ],
+  "type": "string"
+}

addedInput schema / properties / intent

Added value: +{
+  "description": "log = completed run; plan = future run. Elias uses plan for a workout the runner has not done yet.",
+  "enum": [
+    "log",
+    "plan"
+  ],
+  "type": "string"
+}

removedInput schema / properties / notes / description
```
Removed value: -"Free-text notes. Optional."
```

addedInput schema / properties / pain_notes

Added value: +{
+  "description": "Pain/discomfort exactly as the runner described it.",
+  "type": "string"
+}

addedInput schema / properties / perceived_effort

Added value: +{
+  "description": "Post-run check-in only.",
+  "enum": [
+    "too_easy",
+    "about_right",
+    "too_hard"
+  ],
+  "type": "string"
+}

addedInput schema / properties / rpe

Added value: +{
+  "description": "RPE 1-10. For a plan this is target RPE.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "number"
+}

changedInput schema / properties / run_type / description

Previous value: -"Type of run. Optional — infer from context if obvious."New value: +"Classify only when the runner or workout structure supports it. Do not turn an unspecified wearable run into easy."

changedInput schema / properties / run_type / enum

Previous value: -[
-  "easy",
-  "long",
-  "tempo",
-  "interval",
-  "recovery",
-  "race"
-]New value: +[
+  "easy",
+  "long",
+  "tempo",
+  "interval",
+  "recovery",
+  "race",
+  "fartlek",
+  "threshold",
+  "progression",
+  "hills",
+  "other"
+]

addedInput schema / properties / segments

Added value: +{
+  "description": "Workout structure, e.g. warmup, 6x800m threshold, recovery, cooldown. This may describe a plan or what was actually performed.",
+  "items": {
+    "properties": {
+      "distance_mi": {
+        "description": "In mi, or km with input_distance_unit set. See UNIT INPUTS.",
+        "type": "number"
+      },
+      "duration_sec": {
+        "type": "integer"
+      },
+      "input_distance_unit": {
+        "description": "Set to km when the user gave km for the _mi fields in this object. Omit when they are already mi.",
+        "enum": [
+          "mi",
+          "km"
+        ],
+        "type": "string"
+      },
+      "kind": {
+        "enum": [
+          "warmup",
+          "easy",
+          "steady",
+          "tempo",
+          "threshold",
+          "interval",
+          "recovery",
+          "hill",
+          "cooldown",
+          "other"
+        ],
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "notes": {
+        "type": "string"
+      },
+      "repeats": {
+        "type": "integer"
+      },
+      "target_hr_max": {
+        "type": "integer"
+      },
+      "target_hr_min": {
+        "type": "integer"
+      },
+      "target_pace_sec_per_mi": {
+        "description": "In mi, or km with input_distance_unit set. See UNIT INPUTS.",
+        "type": "number"
+      }
+    },
+    "required": [
+      "name",
+      "kind"
+    ],
+    "type": "object"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

addedInput schema / properties / splits

Added value: +{
+  "description": "Actual splits/laps only when supplied by the runner/source. Never invent.",
+  "items": {
+    "properties": {
+      "avg_cadence_spm": {
+        "type": "number"
+      },
+      "avg_hr": {
+        "type": "integer"
+      },
+      "avg_power_w": {
+        "type": "number"
+      },
+      "distance_mi": {
+        "description": "In mi, or km with input_distance_unit set. See UNIT INPUTS.",
+        "type": "number"
+      },
+      "duration_sec": {
+        "type": "integer"
+      },
+      "elevation_change_m": {
+        "type": "number"
+      },
+      "index": {
+        "type": "integer"
+      },
+      "input_distance_unit": {
+        "description": "Set to km when the user gave km for the _mi fields in this object. Omit when they are already mi.",
+        "enum": [
+          "mi",
+          "km"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "index"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "type": "array"
+}

addedInput schema / properties / start_time

Added value: +{
+  "description": "Local HH:MM only when known.",
+  "type": "string"
+}

removedInput schema / properties / surface / description

Removed value: -"Running surface. Optional — infer only if stated. Use \"other\" for indoor, airport, mall, etc."

changedInput schema / required

Previous value: -[
-  "date",
-  "distance_mi",
-  "duration_sec"
-]New value: +[
+  "intent"
+]

Changed1 schema field changedAug 4, 2026

changedInput schema / properties / distance_mi / description

Previous value: -"Distance in miles. Required."New value: +"Distance in MILES, always — regardless of the user’s display unit. Convert from km if needed (km ÷ 1.609344). Required."

First observedAug 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the description doesn't need to restate that this is a write operation. It adds behavioral context by explaining what the tool does with the value field (converts once before storage), how intent affects the outcome (writes completed run vs creates planned card), and explicitly says never to invent sensor data or splits. The description goes beyond the annotations by disclosing the conversion convention and the no-invention rule.

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

Conciseness5/5

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

The description is compact relative to the 19-parameter schema. It front-loads the critical UNIT INPUTS and RUNNING ONLY rules, then intent, then run_type, then detail. Every sentence earns its place – the RUNNING ONLY and UNIT INPUTS sections are high-value disambiguation that prevents wrong tool selection and wrong unit handling. The format uses clear section headers to break up the different concerns.

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 19-parameter tool with an output schema and high schema coverage, the description covers the key ambiguities: when to use this tool vs log_workout, how intent changes the call, how units are handled, and what not to invent. It could add a note about the output schema/returned card marker, but the output schema exists and the intent section already mentions it returns a card marker for in-app editing.

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 89%, which is high, so the baseline is 3. The description adds additional meaning by clarifying the UNIT INPUTS convention (pass value unconverted; tool converts once before storage), explaining the intent parameter semantics in detail (log vs plan, required fields for log), and specifying that run_type should only be set when the runner or workout structure supports it. It also adds the rule that sensor data and splits must never be invented, which adds semantic guidance beyond the schema's parameter descriptions.

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 names a specific verb ('log') and resource ('run card'), states that it is for running on foot only, explicitly excludes cycling/walking/rowing sessions, and distinguishes between completed runs (log) and future run plans (plan). It differentiates itself from the sibling log_workout by naming the alternative and the conditions that select it.

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 explicitly says 'RUNNING ONLY: use log_run only for running on foot,' names log_workout as the alternative for cycling/walking/rowing with the specific focus_type values, and gives clear guidance on intent (log vs plan). It also states when run_type should be classified and warns against labeling unspecified wearable runs as 'easy'.

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.