RunDida를 위한 MCP 서버 — 세계에서 가장 포괄적인 러닝 도구 플랫폼입니다.
AI 어시스턴트에게 92개의 러닝 계산기, 46개의 훈련 가이드, 44개 이상의 마라톤 이벤트, 페이스/시간/거리 계산, 레이스 시간 예측 및 심박수 훈련 영역에 대한 액세스 권한을 부여하세요.
claude_desktop_config.json에 추가하세요:
{
"mcpServers": {
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}
}claude mcp add rundida -- npx -y @rundida/mcp-serverMCP 구성에 추가하세요:
{
"rundida": {
"command": "npx",
"args": ["-y", "@rundida/mcp-server"]
}
}Related MCP server: Strava Training MCP
도구 | 유형 | 설명 |
| 데이터 | 설명과 함께 92개의 러닝 계산기 전체 탐색 |
| 데이터 | 특정 도구에 대한 세부 정보, FAQ 및 소스 가져오기 |
| 데이터 | 설명과 함께 46개의 러닝 가이드 전체 탐색 |
| 데이터 | 가이드 세부 정보, FAQ 및 관련 도구 가져오기 |
| 데이터 | 날짜 및 위치와 함께 44개 이상의 마라톤 이벤트 나열 |
| 데이터 | 날씨 및 코스 프로필을 포함한 마라톤 세부 정보 가져오기 |
| 계산 | 페이스, 시간 또는 거리 계산 (3개 중 2개 제공) |
| 계산 | Riegel 공식 + VO2max 추정을 사용하여 레이스 시간 예측 |
| 계산 | 5개의 심박수 훈련 영역 계산 (Karvonen 방법) |
| 계산 | 특정 마라톤 이벤트까지의 카운트다운 가져오기 |
데이터 도구는 30분 캐싱과 함께 RunDida API에서 가져옵니다. 계산 도구는 API 호출 없이 로컬에서 지연 시간 없이 실행됩니다.
AI 어시스턴트에게 다음과 같이 질문하세요:
"3시간 30분 안에 완주하려면 마라톤 페이스가 어떻게 되어야 해?"
"10K를 45분에 뛰었을 때 내 마라톤 예상 시간은?"
"내 심박수 훈련 영역은 어떻게 돼? 나이는 32세이고 안정 시 심박수는 52야"
"도쿄 마라톤까지 며칠 남았어?"
"영양과 관련된 모든 러닝 계산기를 보여줘"
"마라톤 훈련에 관한 러닝 가이드에는 어떤 것들이 있어?"
"'Couch to 5K' 가이드에 대해 알려줘"
RunDida (跑滴答)는 모든 수준의 러너를 위한 무료 러닝 도구 플랫폼입니다:
90개 이상의 대화형 계산기 — 페이스, 심박수 영역, VO2max, 레이스 예측, 영양, 장비 사이즈, 날씨 영향 등
29개의 마라톤 카운트다운 — 레이스 당일 날씨 예보, 코스 프로필 및 훈련 도구가 포함된 실시간 타이머
무료 JSON API — 인증 불필요, CORS 활성화, OpenAPI 3.0 문서화
다국어 지원 — 영어, 중국어 (中文)
임베드 가능한 위젯 — 모든 계산기에 대해 한 줄 iframe 임베드 지원
모든 도구는 무료이며 계정이 필요하지 않습니다. rundida.com에서 사용해 보세요.
계산 도구는 확립된 러닝 과학 공식을 사용합니다:
공식 | 사용처 | 설명 |
Riegel 공식 |
| 거리별 레이스 시간 예측 |
Jack Daniels 방법 |
| 레이스 기록을 통한 VO2max 추정 |
Karvonen 방법 |
| 나이와 안정 시 심박수를 통한 심박수 훈련 영역 계산 |
Node.js >= 18
인터넷 연결 (데이터 도구는 rundida.com에서 가져옴)
리소스 | URL |
RunDida 웹사이트 | |
API 문서 | |
OpenAPI 사양 | |
NPM 패키지 |
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.
