Skip to main content
Glama

log_run

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.

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
NameRequiredDescriptionDefault
rpeNoRPE 1-10. For a plan this is target RPE.
dateNoYYYY-MM-DD. Completed runs default to today when context allows; planned runs use the intended date when known.
notesNo
avg_hrNoAverage heart rate only when known.
intentYeslog = completed run; plan = future run. Elias uses plan for a workout the runner has not done yet.
splitsNoActual splits/laps only when supplied by the runner/source. Never invent.
surfaceNo
run_typeNoClassify only when the runner or workout structure supports it. Do not turn an unspecified wearable run into easy.
segmentsNoWorkout structure, e.g. warmup, 6x800m threshold, recovery, cooldown. This may describe a plan or what was actually performed.
pain_notesNoPain/discomfort exactly as the runner described it.
start_timeNoLocal HH:MM only when known.
avg_power_wNoAverage running power in watts only when known.
distance_miNoDistance. In mi, or km with input_distance_unit set. See UNIT INPUTS.
elapsed_secNoWall-clock elapsed time including pauses, only when known.
duration_secNoMoving/workout duration in seconds.
avg_cadence_spmNoAverage running cadence in steps/min only when known.
elevation_gain_mNoElevation gain in metres only when known.
perceived_effortNoPost-run check-in only.
input_distance_unitNoSet to km when the user gave km for the _mi fields in this object. Omit when they are already mi.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed21 schema fields changed
    • 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"
      +]
  2. Changed1 schema field changed
    • 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."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuine behavior: the write returns 'a card marker for in-app editing,' the log/plan intent controls whether history is mutated, and 'Never invent sensor data or splits' constrains hallucination. It does not discuss permissions or overwrite semantics, so it falls short of 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 bulk of the opening is a unit-convention block, much of it enumerating companion fields that this tool's schema doesn't have, so the actual purpose ('Create an editable running card') is buried. Every remaining sentence is useful, but the front-loading is misprioritized and the reused template block is wasted text.

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

Completeness5/5

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

With an output schema present, return values need not be described. The description covers the mutation intent, run-type classification, unit handling, and data-fidelity rules, which is everything an agent needs to call this 19-parameter tool correctly. No material gaps remain.

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% (baseline 3), but the description adds real meaning beyond the schema: the schema fields merely point to 'See UNIT INPUTS,' and the description is where the actual rule lives (pass numbers unconverted, set the companion unit field, omit when canonical). It also explains run_type classification and detail-preservation constraints. It loses a point for listing unit families (_lb, _in, _stated_g, _stated_ml) that do not exist in this 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?

States a specific verb+resource ('Create an editable running card') and explicitly scopes it ('completed run OR a future run plan'). It also differentiates itself from the sibling log_workout by excluding non-running sessions, so an agent can route between them without opening either schema.

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?

Explicit when-to-use and when-not-to-use: 'use log_run only for running on foot... A bike/cycling ride, walk, or rowing session is not a run... For those, use log_workout.' It also disambiguates intent (log vs plan) with the rule 'Never put a future run in completed history.'

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.