Marathon physiology MCP server — 12 tools for race prediction, pacing strategy, fueling plans, running economy, caffeine protocols, heat acclimation, and Strava-connected training load. Citation-backed models from peer-reviewed exercise physiology literature.
Scored across 13 tools
Each tool targets a distinct aspect of endurance performance: caffeine modeling, fueling, pacing, training plans, single workouts, athlete data, activities, training load, heat acclimation, marathon pacing strategy, periodization comparison, race prediction, and running economy. There is no meaningful overlap; even similar-sounding tools like gap_pace and pacing_strategy address different problems (course splitting vs. HR/fluid simulation).
Names are uniformly snake_case but mix verb-first (generate_, get_, predict_) with noun-first (caffeine_protocol, fueling_plan, gap_pace, heat_acclimation_plan, pacing_strategy, periodization_compare, running_economy). While readable and predictable in style, the lack of a single verb_noun convention makes it less consistent than ideal.
With 13 tools, the server is well-scoped for a specialized endurance-performance domain. Each tool addresses a concrete need without redundancy, and the count fits comfortably in the recommended 3-15 range.
The surface covers the full lifecycle of a coaching interaction: profile retrieval (get_my_athlete), activity history (get_recent_activities), load tracking (get_training_load), planning (generate_training_plan, generate_workout, periodization_compare), race prediction (predict_race_time), and performance factor modeling (caffeine, fueling, pacing, heat, economy). No obvious gaps prevent core coaching workflows.
Model caffeine (and optional nicotine) blood concentration, performance gain, and side-effect curves over a race using a 1-compartment oral PK model. Source: ham.run ergogenic module. Pass useMyData:true to overlay body weight from the connected athlete profile.
| Name | Required | Description | Default |
|---|---|---|---|
| nicOn | Yes | Enable nicotine co-administration model. | |
| nicForm | Yes | Nicotine delivery form. | gum |
| finishMin | Yes | Expected race duration in minutes. | |
| nicDoseMg | Yes | Nicotine dose in mg. | |
| useMyData | No | Overlay body weight from the connected athlete profile. | |
| bodyWeightKg | No | Body weight in kilograms. | |
| cafTimingMin | Yes | Minutes BEFORE race start that caffeine is taken. | |
| nicTimingMin | Yes | Minutes before race start for nicotine. | |
| extraCafDoses | Yes | In-race top-up doses, e.g. with gels. | |
| cafDoseMgPerKg | Yes | Pre-race caffeine dose, mg/kg. 3–6 mg/kg is the evidence-based range. |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| giRisk | Yes | GI distress risk level. |
| timeSavedMin | Yes | Estimated time saved, minutes. |
| hrElevationBpm | Yes | Expected HR elevation from caffeine, bpm. |
| perfCheckpoints | Yes | Performance checkpoints at ~10 min intervals. |
| totalCaffeineMg | Yes | Total caffeine consumed, mg. |
| peakRpeReduction | Yes | Peak RPE reduction from ergogenic effect. |
| caffeineDoseEvents | Yes | Timestamped dose events. |
| avgPerformanceGainPct | Yes | Average performance gain over race duration, %. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description adds the model type (1-compartment oral PK), source (ham.run ergogenic module), and a usage tip for useMyData. It also discloses that it outputs concentration, performance, and side-effect curves, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and each sentence adds meaningful context: the model purpose, the source, and a parameter hint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with an output schema, the description covers the core purpose, the optionality of nicotine, and the data overlay option. It doesn't explain all parameters, but the schema and output schema fill those gaps, making this sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining the useMyData parameter and noting that nicotine is optional, which helps clarify the boolean nicOn and the related dosing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool models caffeine and optional nicotine blood concentration, performance gain, and side-effect curves using a 1-compartment oral PK model. This is a specific verb-resource pairing that distinguishes it from siblings like fueling_plan or pacing_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for simulating ergogenic effects over a race and mentions the useMyData option to pull body weight from an athlete profile. It does not explicitly exclude alternatives or state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute substrate partitioning (CHO/fat oxidation), required carb intake rate, and predicted time-to-glycogen-depletion for an endurance effort. Source: ham.run substrate module. Pass useMyData:true to overlay weight and VO₂max from the connected athlete profile.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Athlete sex — affects substrate partitioning. | |
| vo2max | No | Estimated VO₂max in mL O₂ · kg⁻¹ · min⁻¹. | |
| weightKg | No | Body weight in kilograms. | |
| pctVO2max | Yes | Race intensity as % VO₂max. | |
| useMyData | No | Overlay weight and VO₂max from the connected athlete profile. | |
| glycogenPoolG | Yes | Starting muscle+liver glycogen, grams. Typical 400–700. | |
| transportType | Yes | "sglt1" caps absorption at 1.0 g/min; "dual" (glucose+fructose) at 1.5 g/min. | dual |
| choIntakeGPerHr | Yes | Planned CHO intake during race, g/hr. |
| Name | Required | Description |
|---|---|---|
| rer | Yes | Respiratory exchange ratio at given intensity. |
| input | Yes | Echo of resolved input parameters. |
| notes | Yes | Warning if intake exceeds absorption ceiling. |
| vo2LPerMin | Yes | Absolute VO₂ at race intensity, L/min. |
| choEnergyPct | Yes | Percentage of energy from carbohydrate. |
| energyKJPerMin | Yes | Total energy expenditure, kJ/min. |
| timeToExhaustion | Yes | Formatted time to exhaustion. |
| choOxidationGPerMin | Yes | Carbohydrate oxidation rate, g/min. |
| fatOxidationGPerMin | Yes | Fat oxidation rate, g/min. |
| timeToExhaustionMin | Yes | Minutes until glycogen depletion. |
| effectiveIntakeGPerMin | Yes | Effective CHO intake after absorption cap, g/min. |
| recommendedIntakeGPerHr | Yes | Recommended CHO intake, g/hr. |
| absorptionCeilingGPerMin | Yes | Max gut absorption rate, g/min. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond this: it mentions the source module ('ham.run substrate module') and explains the overlay behavior with useMyData. This provides useful information without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core outputs, the second adds a source reference and a key parameter tip. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters with full schema descriptions and an output schema, the description effectively conveys the tool's purpose and the one special behavior (useMyData). It could mention limitations or assumptions of the model, but it is not incomplete for an AI agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by connecting parameters to the computation's purpose and specifically explaining the useMyData overlay behavior, reinforcing and contextualizing the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Compute') and resource ('substrate partitioning', 'required carb intake rate', 'predicted time-to-glycogen-depletion') for an 'endurance effort'. This clearly distinguishes it from sibling tools like pacing_strategy or predict_race_time, which focus on other performance aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the context ('for an endurance effort') and gives a specific tip for using useMyData. It does not explicitly mention alternatives or when not to use, but the purpose is clear enough to infer appropriate usage relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Distribute a goal time across a course profile in proportion to each segment's Minetti gradient cost. Returns per-mile or per-km splits with pace, elevation gain/loss, and average grade. Source: ham.run GAP module.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | Course profile: parallel arrays of cumulative distance and elevation. | |
| goalTime | Yes | Race time, "HH:MM:SS" or "MM:SS". | |
| splitUnit | Yes | Unit for split intervals. | km |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| splits | Yes | Per-split breakdown. |
| totalTime | Yes | Goal time formatted as HH:MM:SS. |
| totalDistanceM | Yes | Total course distance, metres. |
| flatEquivalentPacePerKm | Yes | Flat-equivalent pace per km. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond those, including the computational method (Minetti gradient cost) and the returned metrics (pace, elevation gain/loss, average grade), which helps the agent understand what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by output details and a source reference. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It covers the purpose, method, split units, and source, making it complete for tool selection and invocation in the context of a course profile and goal time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% description coverage for all three parameters. The description does not add syntax or format details beyond what the schema already offers, but it does tie the parameters together (goal time, profile, split unit) in the overall purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: distribute a goal time across a course profile using Minetti gradient cost. It specifies the action, resource, and output (per-mile or per-km splits with pace, elevation, and grade), and distinguishes it from siblings like pacing_strategy and predict_race_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when a goal time and course profile are available, use this to compute splits. It does not explicitly mention when not to use it or compare to alternatives, but the specific nature of the tool makes the context clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a concrete marathon training schedule from a periodization model: per-week sessions (long run, intervals, tempo, easy runs) with distances and prescribed paces derived from current fitness via the Riegel power law. Optionally anchored to a race date for calendar dates. Source: ham.run training plan module.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Age in years. | |
| sex | No | Athlete sex — affects VO₂max ceiling and adaptation curves. | |
| model | Yes | Training intensity distribution model. | pyramidal |
| raceDate | No | Race date (YYYY-MM-DD). When set, sessions get calendar dates and the race lands in the final week. | |
| longRunDay | Yes | Day of the week for the long run. | Sun |
| totalWeeks | Yes | Plan length in weeks. If raceDate is set, the race lands in the final week — choose totalWeeks ≈ weeks until the race. | |
| daysPerWeek | Yes | Run days per week. | |
| weeklyVolumeKm | Yes | Peak training volume, km/week. | |
| startingMarathonTime | Yes | Current marathon PR / fitness baseline. |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| model | Yes | Periodization model name. |
| weeks | Yes | Week-by-week schedule. |
| summary | Yes | |
| citation | Yes | Academic citation for the TID model. |
| goalPace | Yes | Goal marathon pace, min/km. |
| goalTime | Yes | Predicted finish time after the plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, and non-destructive. The description adds value by detailing the methodology (Riegel power law, periodization) and optional race date anchoring, which are behavioral aspects beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load key information: what it builds, method, and optional feature. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 7 required, and an output schema, the description covers the output (weekly sessions with distances/paces), methodology, and optional race date. It could mention prerequisites or expected user context, but is adequate for a plan generator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description provides high-level context but does not significantly extend the semantics of individual parameters beyond what the schema already offers. For example, 'model' schema says 'Training intensity distribution model' and description doesn't elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a marathon training schedule from a periodization model, specifying key components like sessions, distances, and paces. It uses a specific verb ('Build') and resource ('training schedule'), and given the sibling tools (e.g., pacing_strategy, periodization_compare), it uniquely describes full plan generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (generate a concrete training plan) but does not explicitly provide when-not-to-use or compare with alternatives like periodization_compare or pacing_strategy. The optional race date anchoring is mentioned but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce one concrete running session from the desired stimulus (recovery, endurance, marathon pace, threshold, VO2max, speed, or mixed) and training phase, scaled to fitness anchored by any recent race time via the Riegel power law. Prescriptions follow Daniels-style time-domain quality windows converted to track-friendly distances at the athlete’s own paces. Deterministic for a given seed — vary the seed for a different workout of the same type. Source: ham.run workout generator module.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | Random seed. Same inputs + same seed reproduce the identical workout; change it to regenerate. | |
| phase | Yes | Training phase — shapes eligible workouts, doses, and the reference copy. | build |
| raceTime | Yes | Recent race time for that distance (current fitness, not a goal). | |
| stimulus | Yes | What the session should train: recovery | endurance | marathon | threshold | vo2max | speed | mixed. | |
| raceDistance | Yes | Distance of the anchor race used to derive paces. | marathon |
| timeBudgetMin | No | Total session cap in minutes (including warm-up/cool-down). Omit for no cap. | |
| speedAdjustPct | Yes | Shift all paces together; positive = faster (feeling sharp), negative = slower. |
| Name | Required | Description |
|---|---|---|
| why | Yes | Physiological purpose of the session. |
| text | Yes | The full workout as shareable plain text. |
| input | Yes | Echo of resolved input parameters. |
| paces | Yes | Resolved target paces by name (min/km), after any speed adjustment. |
| phase | Yes | Training phase. |
| title | Yes | Workout title. |
| totals | Yes | |
| citation | Yes | Literature anchor for the session type. |
| shareUrl | Yes | ham.run link that reproduces this exact workout (seed included) with a Garmin .fit download. |
| stimulus | Yes | Stimulus trained. |
| template | Yes | Template id (stable across regenerations of the same workout type). |
| hamFactor | Yes | How much of a day this session is. |
| reference | Yes | Ability-anchored framing, e.g. which marathoner runs this and when. |
| structure | Yes | The workout, section by section. |
| marathonEquivalent | Yes | Marathon-equivalent time implied by the anchor race (Riegel). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful methodological context (Riegel power law, Daniels-style quality windows) and confirms deterministic behavior via the seed, going beyond annotation-provided information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that front-load the purpose and each contribute meaning. The source line ('Source: ham.run...') is slightly extraneous, but overall it is well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a rich output schema and comprehensive annotations, the description effectively covers the tool's purpose, scaling method, and determinism. No major gaps for a generation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds some relational context (e.g., race time scaling via Riegel, stimulus/phase interplay), but parameter-level specifics remain primarily in the schema. Modest added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces one concrete running session from a specified stimulus and training phase, with a list of stimulus options. The phrase 'one concrete running session' distinguishes it from the sibling tool generate_training_plan, which presumably generates a full plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating a single session but does not explicitly mention when to prefer this over alternatives such as generate_training_plan or pacing_strategy. The 'one concrete running session' provides clear context, but no explicit alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the signed-in athlete's profile (age, sex, weight, VO₂max, marathon PR, biomechanics) plus derived HR zones. Use this once at the start of a coaching conversation so subsequent calculations can be personalised. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| source | No | Data source identifier. |
| message | No | Guidance message if no profile exists. |
| profile | Yes | Athlete profile (age, sex, weight, VO₂max, marathon PR, biomechanics) or null. |
| derivedZones | No | HR training zones derived from profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds the behavioral detail that authentication is required, which is beyond the annotations. It also implies that the profile is personal to the signed-in athlete, adding context. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core function and the data fields; the second gives usage timing and an authentication note. Every sentence adds value, with no filler. The most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, and an output schema exists to describe the return structure. The description covers purpose, when to use it, required authentication, and the scope of data. No additional context is needed for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100% and the baseline is 4. The description does not need to explain parameters; instead, it usefully lists the data fields returned, which helps the agent understand what the tool provides without needing the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and clearly states the resource: the signed-in athlete's profile, including specific data fields like age, sex, weight, VO₂max, marathon PR, biomechanics, and derived HR zones. This unambiguously distinguishes it from sibling tools which focus on planning or pacing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this once at the start of a coaching conversation so subsequent calculations can be personalised.' It also notes the authentication requirement, which is a key prerequisite. No alternative tool is mentioned because none exists among the siblings for this purpose, making the guidance complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signed-in athlete's recent activities with date, distance, duration, pace, average HR, and HR-zone classification. Use to ground training-status questions ("how was my last week?", "did I overdo it?"). Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum number of activities to return. | |
| sport | No | Filter by sport type, e.g. "Run", "Ride". | |
| sinceDays | No | Only return activities from the last N days. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of activities returned. |
| window | Yes | Description of the query window. |
| activities | Yes | Activity list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by specifying authentication needs and the specific data fields returned, which are not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then usage context. Every sentence is informative and there is zero fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and strong annotations, the description covers the essential operational context: what it lists, when to use it, and auth. It could mention sorting or pagination, but those are not required given the output schema and simple read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions (limit, sport, sinceDays). The tool description does not add additional parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('signed-in athlete's recent activities') with the exact fields returned (date, distance, duration, pace, avg HR, HR zones). It clearly distinguishes from sibling tools like get_training_load or get_my_athlete, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance via example questions ('how was my last week?', 'did I overdo it?') and states the authentication requirement. It doesn't explicitly call out alternatives or exclusions, but the use case is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return per-week distance, time-in-zone, and rolling chronic/acute training load (CTL, ATL, TSB) for the signed-in athlete. TSS is estimated from HR (avg_hr / threshold_hr clamped), so values are useful for trends but not directly comparable to power-based TSS. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | Yes | Number of weeks of history to analyse. |
| Name | Required | Description |
|---|---|---|
| weeks | Yes | Per-week volume and zone distribution. |
| caveats | Yes | Warning if threshold HR was not available. |
| fitness | Yes | Fitness/fatigue model output. |
| windowWeeks | Yes | Weeks of data returned. |
| thresholdHrUsed | Yes | Threshold HR used for TSS estimation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by disclosing the HR-based TSS estimation method and the authentication requirement, which are behavioral traits not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, the second adds a critical methodological caveat. Every sentence is informative, and the structure front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, one well-documented parameter, and annotations, the description covers the essential aspects: purpose, metrics, methodology, and authentication. It lacks details on edge cases like insufficient data, but that is not essential for this straightforward read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'weeks' parameter, including type, default, min/max, and a clear description. The tool description does not need to add parameter details; the baseline of 3 applies since the schema carries the explanatory burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns per-week distance, time-in-zone, and CTL/ATL/TSB for the signed-in athlete. This specific verb-resource-scope combination distinguishes it from sibling tools like get_recent_activities, which likely returns raw activities rather than aggregated load metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting TSS is estimated from HR and not directly comparable to power-based TSS, implying caution for power-specific analyses. It does not name alternative tools explicitly, but the caveat offers meaningful usage guidance about when the results are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict plasma volume expansion, VO₂max gain, race-time improvement, growth-hormone response, and overtraining risk for a sauna heat-acclimation protocol. Source: ham.run sauna module (Scoon 2007, Kirby 2021).
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Athlete sex — affects thermoregulation and adaptation rate. | |
| tempC | Yes | Sauna temperature in °C. | |
| weeks | Yes | Total weeks of the protocol. | |
| coldPlunge | Yes | Cold plunge after each sauna session. | |
| durationMin | Yes | Session duration in minutes. | |
| sessionsPerWeek | Yes | Sauna sessions per week. |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| hormones | Yes | Hormonal responses. |
| adaptations | Yes | Performance adaptations from heat acclimation. |
| thermalDose | Yes | Cumulative thermal dose metric. |
| overtrainingRiskPct | Yes | Overtraining risk, %. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific physiological predictions and source citation, but does not disclose additional behavioral traits such as assumptions, limitations, or data requirements beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main verb and result list, and includes a source attribution. It is concise with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description adequately conveys the tool's purpose and expected outputs. It could benefit from usage guidance, but for a focused prediction tool with well-documented parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as each parameter has its own description (e.g., 'Sauna temperature in °C', 'Cold plunge after each sauna session'). The tool description itself provides no parameter-specific detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Predict') and resource ('sauna heat-acclimation protocol'), and enumerates the precise outputs (plasma volume expansion, VO₂max gain, etc.). This distinguishes it from sibling tools like caffeine_protocol or pacing_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sauna heat-acclimation planning but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools. An agent can infer the use case from the content, but exclusions and comparisons are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate marathon HR drift and fluid/sodium balance under given heat, sweat, and aid-station conditions. Returns total drift split by cause, decoupling %, kilometre at LT₂ breach, the kilometre where holding pace would demand more than HRmax, plasma sodium, and body-weight loss. Pace at the target %HRR is derived from the athlete's own VO₂max and cost of running, so supply marathonPr or vo2max for a pace specific to them. Source: ham.run HR pacing module. Pass useMyData:true to overlay age + restingHr + weight + VO₂max + PR from the connected athlete profile.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years. | |
| sex | No | Athlete sex — affects sweat rate and thermoregulation. | |
| maxHr | No | Measured maximum heart rate, bpm. Falls back to age-predicted if omitted. | |
| tempC | Yes | Air temperature, °C. | |
| hrRest | No | Resting heart rate, bpm. | |
| vo2max | No | Used to derive pace at the target %HRR when no marathon PR is given. | |
| useMyData | No | Overlay age, resting HR, and weight from the connected athlete profile. | |
| marathonPr | No | Marathon PR. Preferred over vo2max for deriving pace: the athlete's cost of running is back-solved from it, so their marathon-effort intensity reproduces this time exactly. | |
| bodyWeightKg | No | Body weight in kilograms. | |
| intensityPct | Yes | Target effort as % of HRR. | |
| fluidPerStationMl | Yes | Fluid intake per aid station, mL. | |
| sodiumPerStationMg | Yes | Sodium intake per aid station, mg. | |
| sweatSodiumMmolPerL | Yes | Sweat sodium concentration in mmol/L (typical 30–60). | |
| baselineSweatRateLPerHr | Yes | Baseline sweat rate, L/hr. |
| Name | Required | Description |
|---|---|---|
| lt1 | Yes | LT1 heart rate, bpm. |
| lt2 | Yes | LT2 heart rate, bpm. |
| hrMax | Yes | Age-predicted or measured max HR, bpm. |
| input | Yes | Echo of resolved input parameters. |
| hrStart | Yes | Starting HR at target intensity, bpm. |
| pacingKmh | Yes | Average pacing speed, km/h. |
| finishTime | Yes | Predicted finish time. |
| paceSource | Yes | What the pace was derived from. "assumed" means neither marathonPr nor vo2max was supplied and a recreational reference VO₂max was used — say so when reporting the finish time. |
| vo2maxUsed | Yes | VO₂max the pace was derived from, mL·kg⁻¹·min⁻¹. |
| checkpoints | Yes | 5-km checkpoint data. |
| hrCeilingKm | Yes | Kilometre from which holding this pace would demand a heart rate above HRmax, or null. Non-null means the pace is not sustainable: the athlete slows instead. |
| lt2BreachKm | Yes | Kilometre where HR breaches LT2, or null. |
| decouplingPct | Yes | Cardiac decoupling, %. |
| finalPlasmaNa | Yes | Final plasma sodium, mmol/L. |
| totalDriftBpm | Yes | Total cardiac drift over the marathon, bpm. |
| driftBpmByCause | Yes | Total drift split by cause. Decoupling % alone conflates pacing strain with dehydration, and the two move in opposite directions with intensity. |
| pctBodyWeightLost | Yes | Body weight lost, %. |
| dominantDriftCause | Yes | Which cause contributes the most drift. |
| totalFluidDeficitL | Yes | Total fluid deficit at finish, L. |
| marathonEffortPctHrr | Yes | The %HRR that reproduces this athlete's marathon-effort oxygen uptake — their marathon race intensity. |
| totalSodiumDeficitMg | Yes | Total sodium deficit at finish, mg. |
| actualSweatRateLPerHr | Yes | Temperature-adjusted sweat rate, L/hr. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive tool. The description adds meaningful behavioral context beyond that: it specifies the computation is a simulation, lists the exact outputs, and reveals that pace is derived from VO₂max/cost of running or marathon PR. It also documents the useMyData overlay behavior, which isn't apparent from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the primary purpose, then lists outputs, then explains key derivation logic, then provides source and overlay instruction. Every sentence contributes: no filler or repetition of schema field descriptions. It is longer than two sentences but warranted given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, 6 required) and the presence of an output schema and annotations, the description covers the essential context: what the tool simulates, what it returns, and the critical input relationships. It could go deeper on precedence rules (e.g., if both marathonPr and vo2max are supplied) or interaction with useMyData, but those are edge cases not needed for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description enhances this by clarifying the relationship between marathonPr and vo2max ('Pace ... is derived ... so supply marathonPr or vo2max'), and by explaining the effect of useMyData in overlaying multiple linked parameters. This goes beyond individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Simulate' with a clear resource: marathon HR drift and fluid/sodium balance. It lists concrete return values (drift split, decoupling %, LT2 breach, plasma sodium, body-weight loss), which distinguishes it from sibling tools like fueling_plan or heat_acclimation_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states its context: 'Simulate marathon HR drift and fluid/sodium balance under given heat, sweat, and aid-station conditions,' which tells an agent when to use it. It also explains how to get a personalized pace ('supply marathonPr or vo2max') and how to overlay athlete data via 'useMyData:true.' However, it does not explicitly name alternatives or exclusion criteria, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forecast race-time progression across pyramidal, polarized, and threshold periodization models for a given weekly volume and starting marathon time. Returns weekly evolution of VO₂max, running economy, LT₂, and predicted finish. Source: ham.run periodization module.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Age in years. | |
| sex | No | Athlete sex — affects VO₂max ceiling and adaptation curves. | |
| models | Yes | Subset of models to compare. Default: all three. | |
| baseWeeks | Yes | Base phase duration, weeks. | |
| buildWeeks | Yes | Optional ramp weeks before base. | |
| totalWeeks | Yes | Total training block length, weeks. | |
| weeklyVolumeKm | Yes | Average peak training volume, km/week. | |
| startingMarathonTime | Yes | Current marathon PR / fitness baseline. |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| models | Yes | Results keyed by model name. |
| startingTime | Yes | Starting marathon time formatted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavior: it returns weekly evolution of VO₂max, running economy, LT₂, and predicted finish, plus cites the source module. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core function and inputs, the second lists outputs and source. No wasted words, front-loaded with action, and every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, the description doesn't need to detail return structure, but it still summarizes outputs. It adequately covers the tool's purpose and main inputs. However, it doesn't mention how baseWeeks/buildWeeks interact or that totalWeeks defaults to 16, though those are in the schema. Given the complexity and rich schema, this is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions weekly volume and starting marathon time, but these are already fully described in the schema. It doesn't add extra semantic meaning to parameters beyond what's provided, so it doesn't exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Forecast') and clearly states the resource: race-time progression across pyramidal, polarized, and threshold models. It distinguishes itself from siblings like predict_race_time (single prediction) and generate_training_plan (plan creation) by focusing on model comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when comparing periodization models for a given volume and starting time. It doesn't explicitly state exclusions or name alternatives, but the context is clear enough from the content and sibling tool names. The lack of explicit 'use this instead of X' prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict times across 5K / 10K / Half / Marathon from a known race result, using a distance-varying Riegel exponent (1.06 up to 10K, 1.07 to the half, 1.08 to the marathon) and age-graded performance scores against world records. Predictions are point estimates with no confidence interval — treat a marathon predicted from a short race as an optimistic ceiling. Source: ham.run race predictor. Pass useMyData:true to overlay age + sex from the connected athlete profile.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years. | |
| sex | No | Athlete sex — used for age-graded scoring against world records. | |
| knownTime | Yes | Race time, "HH:MM:SS" or "MM:SS". | |
| useMyData | No | Overlay age + sex from the connected athlete profile. | |
| knownDistanceMeters | Yes | Distance in metres. |
| Name | Required | Description |
|---|---|---|
| input | Yes | Echo of resolved input parameters. |
| method | Yes | Description of the prediction methodology. |
| predictions | Yes | Predictions for each standard race distance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description discloses that predictions are point estimates without confidence intervals and flags the optimistic ceiling for marathon-from-short-race predictions. It also reveals the underlying algorithm and the effect of useMyData, adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core function, then adds algorithm details, limitations, source, and usage tip in a logical sequence. Every sentence adds unique value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description adequately covers the algorithm, limitations, and optional profile overlay. It lacks an explicit statement of when not to use the tool, but overall it is sufficiently complete for a read-only prediction utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, so the description does not need to repeat definitions. It adds a helpful hint about useMyData overlaying profile data and clarifies the distance scope, but the schema carries the primary semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts race times across 5K/10K/Half/Marathon from a known race result using a specific algorithm. This specific verb+resource combination distinguishes it from siblings like pacing_strategy or generate_training_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the core use case: input a known race result to get predictions. It also provides a caution about interpreting marathon predictions from short races, implying when to be careful. However, it does not explicitly name alternative tools or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute oxygen cost of running (Cr in mL O₂·kg⁻¹·m⁻¹) given pace, gradient, surface, shoe type, and athlete characteristics. Returns full multiplicative breakdown. Source: ham.run running-economy module (Barnes & Kilding 2015 + Minetti 2002).
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Athlete sex — affects economy baseline. | |
| shoes | Yes | Shoe type — "super" = carbon-plated race shoes. | standard |
| vo2max | No | Estimated VO₂max in mL O₂ · kg⁻¹ · min⁻¹. | |
| surface | Yes | Running surface. | road |
| gradient | Yes | Slope as a decimal (0.05 = 5% uphill). | |
| heightCm | No | Height in centimetres. | |
| weightKg | No | Body weight in kilograms. | |
| useMyData | No | Overlay athlete profile data. | |
| marathonPr | No | Marathon PR for caliber estimation. | |
| paceMperMin | Yes | Running pace in metres per minute. 267 = 16 km/h reference. |
| Name | Required | Description |
|---|---|---|
| Cr | Yes | Running economy cost, mL O₂·kg⁻¹·m⁻¹. |
| input | Yes | Echo of resolved input parameters. |
| caliber | Yes | Runner caliber classification. |
| kJperKm | Yes | Energy cost per km, kJ (requires weight). |
| breakdown | Yes | Multiplicative factor breakdown. |
| vo2at16kmh | Yes | Estimated VO₂ at 16 km/h reference pace, mL/kg/min. |
| classification | Yes | Economy tier (e.g. "elite", "good", "average"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is handled. The description adds value by stating that it returns a 'full multiplicative breakdown' and citing the underlying model sources, giving insight into the calculation and output structure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes a source citation that adds credibility without redundancy. Every sentence contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for selection and invocation: it states purpose, key inputs, and output behavior. With a comprehensive schema and output schema, it doesn't need to explain return values in detail. It could mention scientific limitations or that it's a reference implementation, but that's not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with each parameter having a clear description. The tool description only lists broad parameter categories (pace, gradient, surface, shoe type, athlete characteristics) without adding new meanings or relationships, so it adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Compute' and clearly identifies the resource (running economy/Cr) and what it returns ('full multiplicative breakdown'). It is distinctly different from sibling tools like pacing_strategy or predict_race_time, which address entirely different running metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is clear: calculate oxygen cost of running given pace, gradient, surface, shoe type, and athlete characteristics. It doesn't explicitly name alternatives or exclusions, but no sibling tool covers this specific calculation, making the implied usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_workoutpacing_strategy9 fields changedInput schema / properties / marathonPrAdded value: +{
+ "description": "Marathon PR. Preferred over vo2max for deriving pace: the athlete's cost of running is back-solved from it, so their marathon-effort intensity reproduces this time exactly.",
+ "pattern": "^\\d{1,2}(:\\d{2}){1,2}$",
+ "type": "string"
+}Input schema / properties / vo2maxAdded value: +{
+ "description": "Used to derive pace at the target %HRR when no marathon PR is given.",
+ "maximum": 95,
+ "minimum": 20,
+ "type": "number"
+}Output schema / properties / dominantDriftCauseAdded value: +{
+ "description": "Which cause contributes the most drift.",
+ "enum": [
+ "pacing",
+ "heat",
+ "fluid",
+ "none"
+ ],
+ "type": "string"
+}Output schema / properties / driftBpmByCauseAdded value: +{
+ "additionalProperties": false,
+ "description": "Total drift split by cause. Decoupling % alone conflates pacing strain with dehydration, and the two move in opposite directions with intensity.",
+ "properties": {
+ "fluidBpm": {
+ "description": "Drift from fluid deficit, bpm — rises with race DURATION, so it grows as intensity falls.",
+ "type": "number"
+ },
+ "pacingBpm": {
+ "description": "Drift from the intensity held, bpm — rises with effort.",
+ "type": "number"
+ },
+ "thermalBpm": {
+ "description": "Drift from ambient heat, bpm.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "pacingBpm",
+ "thermalBpm",
+ "fluidBpm"
+ ],
+ "type": "object"
+}Output schema / properties / hrCeilingKmAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Kilometre from which holding this pace would demand a heart rate above HRmax, or null. Non-null means the pace is not sustainable: the athlete slows instead."
+}Output schema / properties / marathonEffortPctHrrAdded value: +{
+ "description": "The %HRR that reproduces this athlete's marathon-effort oxygen uptake — their marathon race intensity.",
+ "type": "number"
+}Output schema / properties / paceSourceAdded value: +{
+ "description": "What the pace was derived from. \"assumed\" means neither marathonPr nor vo2max was supplied and a recreational reference VO₂max was used — say so when reporting the finish time.",
+ "enum": [
+ "pr",
+ "vo2max",
+ "assumed"
+ ],
+ "type": "string"
+}Output schema / properties / vo2maxUsedAdded value: +{
+ "description": "VO₂max the pace was derived from, mL·kg⁻¹·min⁻¹.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "input",
- "finishTime",
- "pacingKmh",
- "hrMax",
- "hrStart",
- "lt1",
- "lt2",
- "lt2BreachKm",
- "totalDriftBpm",
- "decouplingPct",
- "actualSweatRateLPerHr",
- "totalFluidDeficitL",
- "totalSodiumDeficitMg",
- "finalPlasmaNa",
- "pctBodyWeightLost",
- "checkpoints"
-]New value: +[
+ "input",
+ "finishTime",
+ "pacingKmh",
+ "hrMax",
+ "hrStart",
+ "lt1",
+ "lt2",
+ "lt2BreachKm",
+ "hrCeilingKm",
+ "totalDriftBpm",
+ "decouplingPct",
+ "driftBpmByCause",
+ "dominantDriftCause",
+ "paceSource",
+ "vo2maxUsed",
+ "marathonEffortPctHrr",
+ "actualSweatRateLPerHr",
+ "totalFluidDeficitL",
+ "totalSodiumDeficitMg",
+ "finalPlasmaNa",
+ "pctBodyWeightLost",
+ "checkpoints"
+]generate_training_plancaffeine_protocolfueling_plangap_paceget_my_athleteget_recent_activitiesget_training_loadheat_acclimation_planpacing_strategyperiodization_comparepredict_race_timerunning_economy
Add one secure layer between your agents and this server.