The rundida-mcp server gives AI assistants access to RunDida's running tools platform, enabling calculations, predictions, and data retrieval for runners.
Data & Information Tools (fetched from RunDida API with 30-minute caching):
List/explore running calculators — Browse 92+ running tools with descriptions, FAQs, and related tools
List/explore running guides — Access 46 training guides with FAQs and related tools
List/explore marathon events — Browse 44+ marathons with dates, locations, course profiles, and countdown timers
Computation Tools (run locally, zero latency):
Calculate pace/time/distance — Provide any two of pace, finish time, or distance to compute the third
Predict race times — Use the Riegel formula to estimate finish times across distances (5K, 10K, half, full marathon) based on a known result, including VO2max estimation
Calculate heart rate zones — Compute 5 training zones using the Karvonen method given age, and optionally resting/max HR
Other details: No authentication required, supports English and Chinese, and works with Claude Desktop, Claude Code, Cursor, and Windsurf.
MCP server for RunDida — running expertise for AI agents.
Ten tools that let Claude, Cursor or any MCP client compute paces, heart-rate zones, race predictions and marathon countdowns live, and query RunDida's full library: 99 running calculators, 56 training guides and 300+ marathon events (course, weather and registration data) — in English, Chinese and Japanese. Free, zero-config, no API key.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}
}claude mcp add rundida -- npx -y @rundida/mcp-serverAdd to your MCP configuration:
{
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}Related MCP server: Strava Training MCP
Tool | Type | Description |
| Data | Browse all 99 running calculators with descriptions |
| Data | Get details, FAQs, and sources for a specific tool |
| Data | Browse all 46 running guides with descriptions |
| Data | Get guide details, FAQs, and related tools |
| Data | List 300+ marathon events with dates and locations |
| Data | Get marathon details including weather and course profile |
| Compute | Calculate pace, time, or distance (provide any 2 of 3) |
| Compute | Predict race times using Riegel formula + VO2max estimation |
| Compute | Calculate 5 HR training zones (Karvonen method) |
| Compute | Get countdown to a specific marathon event |
Data tools fetch from the RunDida API with 30-minute caching. Compute tools run locally with zero latency — no API calls needed.
Ask your AI assistant:
"What's my marathon pace if I want to finish in 3:30?"
"Predict my marathon time based on my 10K of 45 minutes"
"What are my heart rate zones? I'm 32 with a resting HR of 52"
"How many days until the Tokyo Marathon?"
"Show me all running calculators related to nutrition"
"What running guides do you have about marathon training?"
"Tell me about the couch to 5K guide"
RunDida (跑滴答) is a free running tools platform for runners of all levels:
90+ Interactive Calculators — Pace, heart rate zones, VO2max, race prediction, nutrition, gear sizing, weather impact, and more
29 Marathon Countdowns — Live timers with race-day weather forecasts, course profiles, and training tools
Free JSON API — No authentication required, CORS enabled, OpenAPI 3.0 documented
Multi-language — English, Chinese (中文)
Embeddable Widgets — One-line iframe embed for any calculator
All tools are free, no account required. Try them at rundida.com.
The computation tools use established running science formulas:
Formula | Used In | Description |
Riegel formula |
| Race time prediction across distances |
Jack Daniels method |
| VO2max estimation from race performance |
Karvonen method |
| Heart rate training zones from age and resting HR |
Node.js >= 18
Internet connection (data tools fetch from rundida.com)
Resource | URL |
RunDida Website | |
API Documentation | |
OpenAPI Spec | |
NPM Package |
MIT
Calculate running pace, finish time, or distance. Provide any two of: distance, time, pace.
| Name | Required | Description | Default |
|---|---|---|---|
| distance | No | Distance: "5k", "10k", "half", "marathon", or km value like "15" | |
| time | No | Finish time in H:MM:SS or MM:SS format, e.g. "3:30:00" or "25:00" | |
| pace | No | Pace per km in M:SS format, e.g. "5:00" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description must carry the burden. It describes the core behavior (calculating one from two) but does not disclose error handling, return format, or limitations beyond the input 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?
Two sentences with no wasted words. Front-loaded with purpose and immediately followed by usage rule. Exemplary conciseness.
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 no output schema, the description does not specify what is returned, but for a calculator it's natural to return the computed value. Sibling tools are clearly different. Could mention output format but still sufficient.
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 format descriptions. The description adds the key semantics that exactly two parameters must be provided and which one is inferred. This adds value beyond the individual 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?
Description clearly states it calculates pace, finish time, or distance from any two inputs. Verb 'calculate' and resource 'running pace, finish time, or distance' are specific and distinguishable from sibling tools like get_guide or heart_rate_zones.
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?
Explicitly instructs to provide any two of the three parameters, which is clear usage guidance. However, no when-not-to-use or alternative tool references are provided, but given the tool's simplicity this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific running guide including FAQs and related tools
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Guide slug, e.g. "first-marathon-training", "couch-to-5k-complete-guide" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions output includes FAQs and related tools, but lacks details about error handling or other behaviors.
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?
Single sentence, no wasted words, conveys the main purpose efficiently.
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 simple lookup tool with one parameter and no output schema, the description is mostly complete. It explains what the tool returns. Minor omission: no mention of return format.
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 example values. Description adds no extra meaning beyond what the schema provides for the slug parameter.
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 verb 'Get' and the resource 'detailed information about a specific running guide', and distinguishes itself from siblings like `list_guides` which lists guides without details.
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?
Usage is implied but no explicit when-to-use or alternatives given. The description doesn't mention not to use it for browsing or for getting tool info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific marathon including countdown and Schema.org data
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Marathon ID or slug, e.g. "tokyo", "boston", "berlin2026", "kobe2026" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions output includes countdown and Schema.org data, which is helpful, but it does not disclose if the operation is read-only, any side effects, authentication needs, or rate limits. For a simple data retrieval tool, this is minimal but adequate.
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 sentence of 12 words, front-loading the purpose and including key output details. No redundancy or unnecessary 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 tool's simplicity (1 param, no output schema), the description adequately conveys the return content ('detailed information, countdown, Schema.org data'). It could be improved by noting the return format or error conditions, but it is largely sufficient.
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% coverage with a clear description of the 'id' parameter (Marathon ID or slug with examples). The description does not add extra meaning beyond what the schema 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 clearly states the action ('Get') and resource ('detailed information about a specific marathon'), and it adds distinguishing features like 'including countdown and Schema.org data', which differentiates it from sibling tools like list_marathons or marathon_countdown.
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 retrieving details of a specific marathon via the required 'id' parameter, but it does not explicitly state when to use this tool over alternatives like list_marathons (for all) or marathon_countdown (for countdown only). No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific running tool including FAQs and related tools
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug, e.g. "pace-calculator", "heart-rate-zones" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'detailed information' but does not specify what is included beyond FAQs and related tools. No mention of side effects, authentication, or data freshness.
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?
Single sentence that front-loads the key action and resource. No extraneous words. Efficiently communicates the essential 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?
Given the simple parameter set and no output schema, the description provides adequate context for basic usage. However, it omits details about the return structure or potential errors, which would be helpful.
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 has 100% coverage for the single parameter 'slug' with a clear description and example. The tool description does not add extra semantic value beyond the schema, so baseline 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?
Description clearly states it retrieves detailed information about a specific running tool, including FAQs and related tools. The verb 'Get' and resource are explicit, but it does not explicitly differentiate from sibling tools like get_guide or list_tools.
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?
No guidance on when to use this tool versus alternatives. Implies it is for obtaining detailed info, but does not mention when list_tools or other get tools are more appropriate.
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 using the Karvonen method
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Your age in years | |
| resting_hr | No | Resting heart rate in bpm (default: 60) | |
| max_hr | No | Known max heart rate in bpm (auto-calculated if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full weight. It only states 'calculate' with no mention of side effects, authorization needs, or output format, leaving assumptions about 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?
Single sentence, front-loaded with key information, no unnecessary words. Very 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 3 parameters, no output schema, and no annotations, the description is adequate for a simple calculation tool but lacks detail on output format and usage constraints.
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% with each parameter having a clear description. The tool description adds no extra semantics beyond 'Karvonen method', so 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 explicitly states the verb 'calculate', the resource 'heart rate training zones', and the method 'Karvonen method', which clearly distinguishes it from sibling tools like calculate_pace.
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?
No explicit guidance on when to use this tool vs alternatives. The context of siblings provides implicit differentiation, but the description lacks direct usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all running guides and educational articles on RunDida
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the basic function without mentioning aspects like read-only nature, pagination, rate limits, or output structure. This is insufficient for a tool with no 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 a single sentence that is direct and free of filler, achieving maximum conciseness while conveying the essential 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?
Given the tool has no parameters and no output schema, the description is fairly complete for a simple list operation. However, it could be improved by mentioning the read-only nature or the format of returned items, but it is not critically lacking.
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 zero parameters, so schema description coverage is 100% by default. The description does not add parameter meaning, but that is acceptable since there are no parameters. Baseline for zero parameters is 4.
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 verb 'list' and the resource 'all running guides and educational articles on RunDida', making the tool's purpose unambiguous. It distinguishes from sibling tools like get_guide, which focuses on a single guide.
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 such as get_guide or calculate_pace. It lacks any mention of context, preconditions, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all marathon events tracked by RunDida with dates and locations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes a read operation and specifies returned fields (dates, locations), but lacks details on potential pagination, limits, or performance considerations. Adequate for a simple 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?
Single sentence of 10 words, front-loaded with action and resource. 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?
Given no parameters and no output schema, the description is mostly complete. It states what the tool returns (dates and locations). However, it could mention if the list is unfiltered or if there are any default limits, but for a tool with no params, this is sufficient.
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?
No parameters defined; schema coverage is 100% trivially. According to rules, 0 parameters baseline is 4. The description does not need to add parameter info.
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?
Description clearly states verb 'List', resource 'marathon events', scope 'all', and output includes 'dates and locations'. Distinguishes from siblings like get_marathon (single event) and list_guides (different resource).
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?
No explicit guidance on when to use vs alternatives. The name and description imply listing all events, but no mention of when to prefer get_marathon for details or calculate_pace for pace calculations. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available running calculators and tools on RunDida
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It implies a read-only listing operation but gives no details on permissions, caching, or response structure.
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?
A single, front-loaded sentence with no wasted words. Efficiently communicates the core action.
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?
Adequate for a parameterless tool, but lacks details on what the list contains (e.g., names only or full descriptions). Minimum viable.
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?
No parameters exist, so baseline is 4. Description adds no parameter info, which is acceptable as schema coverage is 100%.
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 lists all available calculators and tools on RunDida. It distinguishes from sibling tools like list_guides and list_marathons which are specific subsets.
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?
No guidance on when to use this tool versus alternatives like list_guides or get_tool. No when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a countdown to a specific marathon event
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Marathon ID or slug, e.g. "tokyo", "boston", "kobe2026" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only says 'Get a countdown', lacks details on behavior like whether it returns time until start, format, or error handling.
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?
Single sentence, concise and front-loaded. However, it is very brief and could benefit from a bit more detail to enhance usefulness.
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 is simple with one parameter and no output schema, the description is minimally adequate but doesn't explain the output format or behavior, which would be helpful for completeness.
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% with clear examples for the id parameter. The description adds no extra parameter info, baseline 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?
Clearly states it gets a countdown to a marathon event. Distinguishes from siblings like get_marathon (details) and predict_race (prediction).
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?
Does not provide any context on when to use this tool versus alternatives. No exclusions or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict race finish times using the Riegel formula based on a known race result
| Name | Required | Description | Default |
|---|---|---|---|
| known_distance | Yes | Known race distance: "5k", "10k", "half", "marathon", or km value | |
| known_time | Yes | Known race time in H:MM:SS or MM:SS format | |
| target_distance | No | Target distance to predict (defaults to showing all standard distances) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the Riegel formula but does not disclose behavioral details such as handling of invalid inputs, precision of results, or edge cases. The default behavior for target_distance is described in the schema, not the description.
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, concise sentence that front-loads the main purpose. Every word is informative and there is no unnecessary 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 three parameters, no output schema, and no annotations, the description is adequate but lacks details on output format, edge cases, or relation to sibling tools like 'calculate_pace'. It is minimally complete but leaves gaps.
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 no extra meaning beyond the schema. Known distance and time formats are already documented in the schema, and the target_distance description in the schema explains default behavior.
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 finish times using the Riegel formula based on a known race result. It is a specific verb-resource combination, but does not explicitly distinguish from the sibling 'calculate_pace' tool.
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 a known race result is available and one wants to predict finish times for other distances. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'calculate_pace'.
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.
v1.0.2get_guideget_marathon1 field changedInput schema / properties / id / descriptionPrevious value: -"Marathon ID, e.g. \"tokyo2026\", \"boston2026\", \"berlin2026\""New value: +"Marathon ID or slug, e.g. \"tokyo\", \"boston\", \"berlin2026\", \"kobe2026\""list_guidesmarathon_countdown1 field changedInput schema / properties / id / descriptionPrevious value: -"Marathon ID, e.g. \"tokyo2026\", \"boston2026\""New value: +"Marathon ID or slug, e.g. \"tokyo\", \"boston\", \"kobe2026\""v0.1.0calculate_paceget_marathonget_toolheart_rate_zoneslist_marathonslist_toolsmarathon_countdownpredict_raceScored across 10 tools
Each tool has a clearly distinct purpose: calculations (pace, HR zones, prediction) and information retrieval (guides, marathons, tools) are separated, with no overlap.
All tools use snake_case with a consistent verb_noun pattern (e.g., calculate_pace, heart_rate_zones, list_marathons), making the set predictable.
With 10 tools, the server covers a reasonable scope for a running resource: calculators, info queries, and listings. Not too sparse or overloaded.
The tool set covers major running needs (pace, HR zones, race prediction, event info). A minor gap is the lack of a calorie calculator, but the domain is well served.
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.
AI running coach. Reads Strava, Suunto, Polar, Apple Health or Health Connect. Adapts to your feel.
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
140+ calculators and data tools — finance, health, science, global comparisons and more.
