Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Running Formulas MCP Server predict my marathon time based on a 5k in 25 minutes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server with comprehensive tools for running calculations including VDOT, training paces, race time predictions, velocity markers, heart rate zones, and pace conversions. Supports multiple methodologies including Jack Daniels, Greg McMillan, and Riegel's formula.
VDOT Calculation: Calculate VDOT from race performance using Jack Daniels' formula
Training Paces: Get recommended training paces (Easy, Marathon, Threshold, Interval, Repetition) for a given VDOT
Race Time Predictions: Predict race times using Jack Daniels' equivalent performance methodology
Velocity Markers: Calculate vLT (Lactate Threshold), CV (Critical Velocity), and vVO2 (VO2max velocity)
Training Paces: Comprehensive training pace zones (Endurance, Stamina, Speed, Sprint) with sub-categories
Race Time Predictions: Predict race times for all standard distances using McMillan's methodology
Heart Rate Zones: Calculate training heart rate zones using multiple estimation formulas
Riegel's Formula: Race time predictions using Riegel's power law
Pace Conversions: Convert between different pace and speed formats (min/km, min/mile, km/h, mph)
Related MCP server: rundida-mcp
daniels_calculate_vdot: Calculate VDOT from race performance using Jack Daniels' formula.
Input:
distance (float): Distance in meters
time (float): Time in seconds
Output:
vdot (float): The calculated VDOT value
daniels_calculate_training_paces: Get recommended training paces for a given VDOT.
Input:
vdot (float): VDOT value
Output:
easy (object): Easy pace range with lower and upper bounds
marathon (object): Marathon pace
threshold (object): Threshold pace
interval (object): Interval pace
repetition (object): Repetition pace
All paces formatted as "MM:SS/km"
daniels_predict_race_time: Predict race time using Jack Daniels' equivalent performance methodology.
Input:
current_distance (float): Distance of known performance in meters
current_time (float): Time of known performance in seconds
target_distance (float): Distance for race time prediction in meters
Output:
value (string): Predicted time in "HH:MM:SS" format
format (string): "HH:MM:SS"
time_seconds (float): Time in seconds
mcmillan_calculate_velocity_markers: Calculate velocity markers (vLT, CV, vVO2) from race performance.
Input:
distance (float): Race distance in meters
time (float): Race time in seconds
Output:
velocity_markers (object): Contains vLT, CV, and vVO2 with pace and description
mcmillan_predict_race_times: Predict race times for standard distances using McMillan methodology.
Input:
distance (float): Race distance in meters
time (float): Race time in seconds
Output:
Dictionary with predicted times for all standard race distances
mcmillan_calculate_training_paces: Calculate comprehensive training paces using McMillan methodology.
Input:
distance (float): Race distance in meters
time (float): Race time in seconds
Output:
Training paces organized by zones (endurance, stamina, speed, sprint)
mcmillan_heart_rate_zones: Calculate heart rate training zones.
Input:
age (int): Runner's age in years
resting_heart_rate (int): Resting heart rate in BPM
max_heart_rate (int, optional): Maximum heart rate in BPM
Output:
Heart rate zones with both HRMAX and HRRESERVE calculations
riegel_predict_race_time: Predict race time using Riegel's formula.
Input:
current_distance (float): Distance of known performance in meters
current_time (float): Time of known performance in seconds
target_distance (float): Distance for race time prediction in meters
Output:
value (string): Predicted time in "HH:MM:SS" format
format (string): "HH:MM:SS"
time_seconds (float): Time in seconds
convert_pace: Convert between different pace and speed units.
Input:
value (float): The numeric value to convert
from_unit (string): Source unit ("min_km", "min_mile", "kmh", "mph")
to_unit (string): Target unit ("min_km", "min_mile", "kmh", "mph")
Output:
value (float): Converted numeric value
formatted (string): Human-readable formatted result
unit (string): Target unit descriptor
This server is designed to be used as an MCP stdio server. It does not expose HTTP endpoints directly.
Call the daniels_calculate_vdot tool with:
{
"name": "daniels_calculate_vdot",
"arguments": { "distance": 5000, "time": 1500 }
}Returns:
{
"vdot": 38.4
}Call the daniels_calculate_training_paces tool with:
{
"name": "daniels_calculate_training_paces",
"arguments": { "vdot": 38.4 }
}Returns structured pace data like:
{
"easy": {
"lower": {"value": "5:42", "format": "MM:SS/km"},
"upper": {"value": "6:29", "format": "MM:SS/km"}
},
"marathon": {"value": "5:07", "format": "MM:SS/km"},
"threshold": {"value": "4:50", "format": "MM:SS/km"},
"interval": {"value": "4:32", "format": "MM:SS/km"},
"repetition": {"value": "4:26", "format": "MM:SS/km"}
}Call the mcmillan_calculate_velocity_markers tool with:
{
"name": "mcmillan_calculate_velocity_markers",
"arguments": { "distance": 5000, "time": 1500 }
}Returns velocity markers:
{
"velocity_markers": {
"vLT": {
"pace": "4:50",
"description": "Velocity at Lactate Threshold (vLT) - sustainable pace for ~1 hour"
},
"CV": {
"pace": "4:32",
"description": "Critical Velocity (CV) - theoretical maximum sustainable pace"
},
"vVO2": {
"pace": "4:15",
"description": "Velocity at VO2max (vVO2) - pace at maximum oxygen uptake"
}
}
}Call the daniels_predict_race_time tool with:
{
"name": "daniels_predict_race_time",
"arguments": { "current_distance": 5000, "current_time": 1500, "target_distance": 10000 }
}Returns:
{
"value": "00:52:07",
"format": "HH:MM:SS",
"time_seconds": 3127.4
}Call the mcmillan_heart_rate_zones tool with:
{
"name": "mcmillan_heart_rate_zones",
"arguments": { "age": 30, "resting_heart_rate": 60, "max_heart_rate": 190 }
}Call the convert_pace tool with:
{
"name": "convert_pace",
"arguments": { "value": 5.0, "from_unit": "min_km", "to_unit": "min_mile" }
}Returns:
{
"value": 8.047,
"formatted": "8:02",
"unit": "min_mile"
}This server is designed to be used with Claude Desktop or other MCP-compatible clients. See the installation sections below for configuration details.
{
"mcpServers": {
"running-formulas-mcp": {
"command": "uvx",
"args": ["running-formulas-mcp"]
}
}
}This project is licensed under the MIT License - see the LICENSE file for details.
Convert between different pace and speed units.
Args: value: The numeric value to convert. from_unit: Source unit ("min_km", "min_mile", "kmh", "mph"). to_unit: Target unit ("min_km", "min_mile", "kmh", "mph").
Returns: dict: value (float): Converted numeric value. formatted (str): Human-readable formatted result. unit (str): Target unit descriptor.
Raises: ValueError: If from_unit or to_unit are not valid, or if conversion is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| from_unit | Yes | ||
| to_unit | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal the return format (dict with value, formatted, unit) and error conditions (ValueError for invalid units or unsupported conversions), which is valuable. However, it doesn't mention performance characteristics, rate limits, or whether this is a pure calculation tool versus one that stores data.
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 well-structured with clear sections (Args, Returns, Raises) and every sentence earns its place. The opening statement establishes purpose, followed by comprehensive parameter documentation, return value specification, and error conditions - all without unnecessary elaboration.
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 mathematical nature (unit conversion), no annotations, and the presence of an output schema (implied by the Returns section), the description is reasonably complete. It explains what the tool does, documents all parameters, specifies the return format, and mentions error conditions. The main gap is lack of differentiation from sibling tools.
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?
With 0% schema description coverage, the description fully compensates by clearly documenting all three parameters: 'value' as the numeric value to convert, 'from_unit' as the source unit with valid options enumerated, and 'to_unit' as the target unit with the same valid options. This provides complete semantic understanding beyond the bare 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 the tool's purpose as converting between pace and speed units, using the specific verb 'convert' and specifying the resource as 'different pace and speed units'. However, it doesn't explicitly differentiate from sibling tools like 'daniels_calculate_training_paces' or 'mcmillan_calculate_training_paces', which might involve similar unit conversions but in different contexts.
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 no guidance on when to use this tool versus the many sibling tools available. With multiple Daniels and McMillan calculation tools that likely involve pace/speed conversions, there's no indication of when this general conversion tool is preferred over those more specialized tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recommended training paces for a given VDOT, based on Jack Daniels' formulas.
Args: vdot: VDOT value.
Returns: dict: easy (dict): Recommended easy pace range with lower and upper bounds. marathon (dict): Recommended marathon pace with value and format. threshold (dict): Recommended threshold pace with value and format. interval (dict): Recommended interval pace with value and format. repetition (dict): Recommended repetition pace with value and format.
| Name | Required | Description | Default |
|---|---|---|---|
| vdot | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'Get recommended training paces,' which implies a read-only operation, but doesn't disclose behavioral traits such as error handling for invalid VDOT values, performance characteristics, or any limitations. The description is minimal beyond the basic function.
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 front-loaded with the core purpose, followed by structured sections for Args and Returns. Every sentence earns its place by clearly defining inputs and outputs without unnecessary details, making it efficient and well-organized.
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 low complexity (one parameter) and the presence of an output schema (detailed in the Returns section), the description is complete enough. It explains the purpose, parameter, and return structure, covering all necessary context without redundancy, as the output schema handles return values explicitly.
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 0% description coverage, but the description compensates by explaining the 'vdot' parameter as 'VDOT value,' adding context about its role in Jack Daniels' formulas. With only one parameter, this provides sufficient meaning beyond the schema's type definition, though it could detail valid ranges or units.
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 specific action ('Get recommended training paces') and resource ('for a given VDOT'), and distinguishes it from siblings by specifying it's based on Jack Daniels' formulas, unlike the McMillan tools. It uses a precise verb and identifies the exact calculation method.
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 by mentioning 'based on Jack Daniels' formulas,' which suggests it should be used for VDOT-based pace calculations rather than alternatives like McMillan tools. However, it lacks explicit when-not-to-use guidance or direct comparisons to siblings like 'daniels_calculate_vdot' or 'mcmillan_calculate_training_paces,' leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate VDOT according to Jack Daniels.
Args: distance: Distance in meters. time: Time in seconds.
Returns: dict: vdot (float): The calculated VDOT value, representing the runner's aerobic capacity based on the input distance and time.
| Name | Required | Description | Default |
|---|---|---|---|
| distance | Yes | ||
| time | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calculates VDOT based on distance and time, which implies a read-only, non-destructive operation, but doesn't explicitly confirm this. It also lacks details on error handling, rate limits, or authentication needs. The description adds basic context but misses key behavioral traits, resulting in a mediocre score.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured sections for args and returns. Each sentence earns its place by providing essential information without redundancy. However, the 'Returns' section could be more concise by integrating with the purpose statement, slightly affecting efficiency.
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 low complexity (2 parameters, no nested objects) and the presence of an output schema that documents the return value, the description is reasonably complete. It covers the purpose, parameter units, and return type, which suffices for a simple calculation tool. However, it lacks usage guidelines and deeper behavioral context, preventing a perfect score.
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 description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies units beyond the schema's generic number types. However, it doesn't explain valid ranges (e.g., positive values), constraints, or examples, leaving gaps in parameter understanding. This partial compensation aligns with a baseline score.
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 purpose: 'Calculate VDOT according to Jack Daniels.' It specifies the verb ('calculate'), the resource ('VDOT'), and the methodology ('according to Jack Daniels'), making it distinct from sibling tools like 'convert_pace' or 'mcmillan_calculate_training_paces'. However, it doesn't explicitly differentiate VDOT from other metrics like 'velocity_markers' or 'heart_rate_zones' among siblings, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when VDOT calculation is appropriate compared to other tools like 'daniels_predict_race_time' or 'mcmillan_predict_race_times', nor does it specify prerequisites or exclusions. The only implied usage is for calculating aerobic capacity, but this is too vague for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict race time for a target distance based on a current race performance. Uses Jack Daniels' equivalent performance methodology.
Args: current_distance: Distance of known performance in meters. current_time: Time of known performance in seconds. target_distance: Distance for race time prediction in meters.
Returns: dict: Daniels' VDOT method prediction with value, format, and time_seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| current_distance | Yes | ||
| current_time | Yes | ||
| target_distance | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the methodology ('Jack Daniels' equivalent performance methodology') and return format ('dict: Daniels' VDOT method prediction with value, format, and time_seconds'), but doesn't mention potential limitations, accuracy, or edge cases. It adds some behavioral context but could be more comprehensive for a prediction tool.
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 front-loaded with the core purpose, followed by structured sections for Args and Returns. Every sentence adds value: the first explains what it does, the second the methodology, and the bullet points detail inputs/outputs without 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 the tool's moderate complexity (3 parameters, prediction logic), no annotations, and an output schema present, the description is fairly complete. It covers purpose, methodology, parameters, and return structure, but could benefit from more behavioral details like error handling or assumptions, though the output schema reduces the need to explain return values.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's role ('current_distance: Distance of known performance in meters', etc.), which clarifies beyond the bare schema types. However, it doesn't specify units beyond meters/seconds or validate ranges, leaving some gaps.
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 purpose: 'Predict race time for a target distance based on a current race performance.' It specifies the verb ('predict'), resource ('race time'), and methodology ('Jack Daniels' equivalent performance methodology'), distinguishing it from sibling tools like 'riegel_predict_race_time' and 'mcmillan_predict_race_times' by naming the specific method.
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 by stating it's for predicting race times based on current performance, but it doesn't explicitly guide when to use this tool versus alternatives like 'mcmillan_predict_race_times' or 'riegel_predict_race_time'. It provides clear input requirements but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate training paces for all zones based on a race performance using McMillan methodology.
Args: distance: Race distance in meters time: Race time in seconds
Returns: Dictionary containing training paces organized by zones (endurance, stamina, speed, sprint)
| Name | Required | Description | Default |
|---|---|---|---|
| distance | Yes | ||
| time | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's purpose and output structure but lacks behavioral details such as error handling for invalid inputs, computational complexity, or any rate limits. It does not contradict annotations, but could benefit from more operational 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 front-loaded with the core purpose in the first sentence, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 moderate complexity (2 parameters, no annotations, but has an output schema), the description is mostly complete. It explains the purpose, parameters, and output structure. However, it could improve by addressing potential errors or linking to sibling tools for context, though the output schema reduces the need to detail return values.
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 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies units beyond the schema's basic number types. However, it does not provide validation rules or examples, leaving some gaps in parameter understanding.
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 specific action ('Calculate training paces for all zones'), methodology ('using McMillan methodology'), and input basis ('based on a race performance'). It distinguishes from siblings like 'daniels_calculate_training_paces' by specifying the McMillan methodology and from 'convert_pace' by focusing on comprehensive zone calculations rather than simple conversions.
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 by stating 'based on a race performance,' which suggests when to use this tool (after a race result is available). However, it does not explicitly state when not to use it or name alternatives like 'daniels_calculate_training_paces' for different methodologies, missing full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate velocity markers (vLT, CV, vVO2) from a race performance using McMillan methodology.
Args: distance: Race distance in meters time: Race time in seconds
Returns: Dictionary containing velocity markers with paces in MM:SS/km format
| Name | Required | Description | Default |
|---|---|---|---|
| distance | Yes | ||
| time | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains what the tool does (calculates velocity markers) and the output format, but doesn't disclose behavioral traits like error handling, validation rules for inputs, or performance characteristics. The description adds basic context but lacks depth on operational behavior.
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 front-loaded with the core purpose in the first sentence, followed by a structured 'Args' and 'Returns' section. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and easy to parse.
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 moderate complexity (2 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains the purpose, input semantics, and output format. The output schema likely covers return values, so the description doesn't need to detail them further. However, it could improve by adding more behavioral context or usage caveats.
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 0%, so the description must compensate. It adds meaning by specifying that 'distance' is in meters and 'time' is in seconds, which clarifies the units beyond the schema's numeric types. However, it doesn't explain valid ranges or constraints (e.g., positive values, realistic race distances).
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 specific action ('calculate velocity markers'), identifies the methodology ('McMillan'), and specifies the exact markers produced (vLT, CV, vVO2). It distinguishes this tool from siblings like 'mcmillan_calculate_training_paces' by focusing on velocity markers rather than training paces.
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 clear context ('from a race performance using McMillan methodology'), which implicitly suggests when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like 'daniels_calculate_vdot' or 'mcmillan_predict_race_times', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate heart rate training zones based on age, resting heart rate, and optional max heart rate. Uses McMillan methodology with multiple max HR estimation formulas and both HRMAX and HRRESERVE methods.
Args: age: Runner's age in years resting_heart_rate: Resting heart rate in BPM max_heart_rate: Optional maximum heart rate in BPM (if None, will be estimated)
Returns: Dictionary containing estimated max HR, effective max HR, and training zones with both HRMAX and HRRESERVE calculations
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | ||
| resting_heart_rate | Yes | ||
| max_heart_rate | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it performs calculations (not destructive), uses estimation formulas when max_heart_rate is not provided, and returns a dictionary with specific outputs. However, it lacks details on error handling, performance characteristics, or rate limits.
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 efficiently structured: a clear purpose statement, methodology details, parameter explanations, and return value description—all in four concise sentences with zero wasted words. It's front-loaded with the core functionality.
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 moderate complexity (3 parameters, calculations with multiple methods), no annotations, but with an output schema (implied by 'Returns' section), the description is largely complete. It covers purpose, parameters, methodology, and outputs. Minor gaps include lack of error cases or example usage.
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 0%, so the description must compensate. It clearly explains the meaning of all three parameters (age, resting_heart_rate, max_heart_rate), including units (years, BPM) and the optional nature of max_heart_rate with its estimation behavior. This adds significant value beyond the bare 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 the specific action ('Calculate heart rate training zones'), the methodology ('McMillan methodology'), and the required inputs ('based on age, resting heart rate, and optional max heart rate'). It distinguishes itself from sibling tools by focusing specifically on heart rate zones rather than pace, velocity, or race time predictions.
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 when heart rate zones are needed, mentioning the McMillan methodology and alternative calculation methods (HRMAX and HRRESERVE). However, it doesn't explicitly state when to use this tool versus its siblings (like mcmillan_calculate_training_paces) or provide clear exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict race times for standard distances based on a single race performance using McMillan methodology.
Args: distance: Race distance in meters time: Race time in seconds
Returns: Dictionary containing predicted race times in HH:MM:SS format
| Name | Required | Description | Default |
|---|---|---|---|
| distance | Yes | ||
| time | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the methodology ('McMillan') and output format ('HH:MM:SS'), which adds useful context beyond basic functionality. However, it lacks details on behavioral traits such as error handling, assumptions (e.g., standard distances), or limitations (e.g., accuracy range).
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured 'Args' and 'Returns' sections. Every sentence earns its place by adding essential information without 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 the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, inputs, and output format. The output schema exists, so explaining return values is unnecessary. However, it could benefit from more behavioral context (e.g., methodology details or limitations).
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 0%, so the description must compensate. It adds meaning by specifying units ('meters' for distance, 'seconds' for time) and clarifying that inputs are based on a 'single race performance,' which is not evident from the schema alone. However, it does not detail what 'standard distances' entail or provide examples.
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 purpose: 'Predict race times for standard distances based on a single race performance using McMillan methodology.' It specifies the verb ('predict'), resource ('race times'), scope ('standard distances'), and methodology ('McMillan'), distinguishing it from sibling tools like 'riegel_predict_race_time' or 'daniels_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 provides clear context for when to use this tool: when predicting race times based on a single performance using the McMillan method. It implicitly distinguishes it from other prediction methods (e.g., Riegel, Daniels) by naming the methodology, but it does not explicitly state when not to use it or list specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict race time for a target distance based on a current race performance. Uses Riegel's formula.
Args: current_distance: Distance of known performance in meters. current_time: Time of known performance in seconds. target_distance: Distance for race time prediction in meters.
Returns: dict: Riegel's formula prediction with value, format, and time_seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| current_distance | Yes | ||
| current_time | Yes | ||
| target_distance | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the formula used, it doesn't describe important behavioral aspects: whether this is a read-only calculation (implied but not stated), what assumptions Riegel's formula makes, accuracy limitations, or error handling. For a prediction tool with zero annotation coverage, this is inadequate.
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 perfectly structured and concise. It opens with the core purpose, mentions the method, provides clear parameter documentation, and describes the return format. Every sentence earns its place with no wasted words, and information is logically organized from general to specific.
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 moderate complexity (mathematical prediction), 0% schema coverage, no annotations, but presence of an output schema, the description does well. It explains parameters thoroughly and mentions the return format. The main gap is lack of formula limitations/assumptions context. With an output schema handling return values, the description focuses appropriately on inputs and purpose.
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 description provides clear parameter documentation in the Args section, explaining what each parameter represents (current_distance in meters, current_time in seconds, target_distance in meters). With 0% schema description coverage, this documentation fully compensates by adding essential semantic meaning beyond the bare schema types. The only minor gap is not explaining unit expectations beyond 'meters' and 'seconds'.
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 purpose: 'Predict race time for a target distance based on a current race performance.' It specifies the verb ('predict'), resource ('race time'), and method ('Uses Riegel's formula'). However, it doesn't explicitly differentiate from sibling tools like 'daniels_predict_race_time' or 'mcmillan_predict_race_times', which would require a 5.
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 no guidance on when to use this tool versus alternatives. With multiple prediction tools available (Riegel, Daniels, McMillan), there's no indication of when Riegel's formula is preferred, what its limitations are, or when other methods might be more appropriate. This leaves the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are mostly distinct, with clear separation between pace conversion, Daniels formulas, McMillan formulas, and Riegel prediction. However, there is some overlap between 'daniels_predict_race_time' and 'riegel_predict_race_time', which both predict race times from a known performance, potentially causing confusion. The other tools have well-defined, non-overlapping purposes.
All tool names follow a consistent snake_case pattern with a clear verb_noun structure (e.g., convert_pace, calculate_training_paces, predict_race_time). The naming is uniform across all tools, making them easily readable and predictable, with no deviations in style or convention.
With 9 tools, the server is well-scoped for its purpose of running formulas, covering pace conversion, training pace calculations, race time predictions, and heart rate zones from multiple methodologies. Each tool serves a distinct function, and the count is neither too sparse nor overwhelming, fitting typical expectations for such a domain.
The tool set provides comprehensive coverage for running-related calculations, including conversions, training paces, race predictions, and heart rate zones from Daniels, McMillan, and Riegel methodologies. A minor gap is the lack of tools for other common running formulas (e.g., Karvonen method for heart rate), but the core workflows are well-covered, allowing agents to perform most essential tasks without significant dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Marathon fueling, pace, hydration, heat, carb-loading, and gel-comparison calculators.
Manage your endurance training data and race preparation
AI running coach. Reads Strava, Suunto, Polar, Apple Health or Health Connect. Adapts to your feel.
Deterministic fitness calculators — TDEE, adaptive TDEE, body fat, 1RM, macros — with consensus.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/st3v/running-formulas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
