MCP-Server für RunDida — die weltweit umfassendste Plattform für Lauf-Tools.
Geben Sie Ihrem KI-Assistenten Zugriff auf 92 Laufrechner, 46 Trainingsleitfäden, über 44 Marathon-Events, Berechnungen für Pace/Zeit/Distanz, Wettkampfzeit-Prognosen und Herzfrequenz-Trainingszonen.
Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu:
{
"mcpServers": {
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}
}claude mcp add rundida -- npx -y @rundida/mcp-serverFügen Sie dies zu Ihrer MCP-Konfiguration hinzu:
{
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}Related MCP server: Strava Training MCP
Tool | Typ | Beschreibung |
| Daten | Durchsuchen Sie alle 92 Laufrechner mit Beschreibungen |
| Daten | Details, FAQs und Quellen für ein bestimmtes Tool abrufen |
| Daten | Durchsuchen Sie alle 46 Laufleitfäden mit Beschreibungen |
| Daten | Leitfaden-Details, FAQs und zugehörige Tools abrufen |
| Daten | Auflistung von über 44 Marathon-Events mit Datum und Ort |
| Daten | Marathon-Details inklusive Wetter und Streckenprofil abrufen |
| Berechnung | Pace, Zeit oder Distanz berechnen (geben Sie 2 von 3 Werten an) |
| Berechnung | Wettkampfzeiten mittels Riegel-Formel + VO2max-Schätzung vorhersagen |
| Berechnung | 5 HF-Trainingszonen berechnen (Karvonen-Methode) |
| Berechnung | Countdown bis zu einem bestimmten Marathon-Event abrufen |
Daten-Tools rufen Informationen von der RunDida API mit 30-minütigem Caching ab. Berechnungs-Tools laufen lokal ohne Latenz — es sind keine API-Aufrufe erforderlich.
Fragen Sie Ihren KI-Assistenten:
"Wie ist meine Marathon-Pace, wenn ich in 3:30 finishen möchte?"
"Prognostiziere meine Marathonzeit basierend auf meinen 45 Minuten über 10 km"
"Was sind meine Herzfrequenz-Zonen? Ich bin 32 und habe einen Ruhepuls von 52"
"Wie viele Tage sind es noch bis zum Tokio-Marathon?"
"Zeige mir alle Laufrechner zum Thema Ernährung"
"Welche Laufleitfäden hast du zum Thema Marathon-Training?"
"Erzähl mir etwas über den Couch-to-5K-Leitfaden"
RunDida (跑滴答) ist eine kostenlose Plattform für Lauf-Tools für Läufer aller Leistungsstufen:
90+ Interaktive Rechner — Pace, Herzfrequenz-Zonen, VO2max, Wettkampfprognose, Ernährung, Ausrüstungsgrößen, Wettereinfluss und mehr
29 Marathon-Countdowns — Live-Timer mit Wettervorhersagen für den Renntag, Streckenprofilen und Trainings-Tools
Kostenlose JSON API — Keine Authentifizierung erforderlich, CORS aktiviert, OpenAPI 3.0 dokumentiert
Mehrsprachig — Englisch, Chinesisch (中文)
Einbettbare Widgets — Einzeiliges Iframe-Embed für jeden Rechner
Alle Tools sind kostenlos, kein Konto erforderlich. Probieren Sie sie auf rundida.com aus.
Die Berechnungstools verwenden etablierte sportwissenschaftliche Formeln:
Formel | Verwendung in | Beschreibung |
Riegel-Formel |
| Wettkampfzeit-Prognose über verschiedene Distanzen |
Jack Daniels Methode |
| VO2max-Schätzung aus der Wettkampfleistung |
Karvonen-Methode |
| Herzfrequenz-Trainingszonen basierend auf Alter und Ruhepuls |
Node.js >= 18
Internetverbindung (Daten-Tools rufen Informationen von rundida.com ab)
Ressource | URL |
RunDida Website | |
API-Dokumentation | |
OpenAPI Spezifikation | |
NPM Paket |
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.
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.
AI coach for Garmin: builds training plans and structured workouts, synced straight to your watch.
44 calculators for AI agents: US tax, finance, business + an MCP engineering & security suite.
