How do I use TrainingPeaks MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TrainingPeaks MCP Server Show my workouts for this week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

TrainingPeaks MCP Server

by tildecomunicacion

Overview Schema Related Servers Score Discussions

Python

Local

TrainingPeaks MCP Server

Connect TrainingPeaks to Claude and other AI assistants via the Model Context Protocol (MCP). Query workouts, build structured intervals, track fitness trends, and write comments/feedback on your calendar through natural conversation.

No more expired cookies. This server features automatic login using your TrainingPeaks username and password. The credentials remain local on your machine and are only transmitted directly to TrainingPeaks over secure HTTPS.

What You Can Do

Ask your AI assistant things like:

"Build me a 4x8min threshold session for Tuesday with warm-up and cool-down"
"Show my workouts for this week and check if I've completed them"
"Analyze my compliance for yesterday's run and add a feedback comment in TrainingPeaks"
"What's my CTL, ATL, and TSB trend for the last 90 days?"
"Get my profile and account type"

Related MCP server: Strava MCP Server

Tools (8)

Workouts & Intervals

tp_get_workouts: List planned and completed workouts in a date range (max 90 days).
tp_create_workout: Create planned workouts on a calendar date (supports complex nested interval structures, auto-computed TSS/IF, and planned start times).
tp_delete_workout: Delete planned workouts by ID.

Comments & Feedback

tp_get_workout_comments: Fetch the list of comments from a workout.
tp_add_workout_comment: Add a text comment (e.g. analysis, compliance review) to a workout.

Performance & Summary

tp_get_profile: Get athlete profile info (Athlete ID, Name, Email, Premium/Basic account status).
tp_get_weekly_summary: Aggregate view of workouts, total TSS, total duration, and end-of-week fitness.
tp_get_fitness: Fetch CTL (Fitness), ATL (Fatigue), and TSB (Form) performance metrics.

Setup in Claude Desktop

Add the server to your claude_desktop_config.json:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "trainingpeaks": {
      "command": "python",
      "args": [
        "-m",
        "tp_mcp",
        "serve"
      ],
      "env": {
        "TP_USERNAME": "YOUR_TRAININGPEAKS_USERNAME",
        "TP_PASSWORD": "YOUR_TRAININGPEAKS_PASSWORD"
      }
    }
  }
}

NOTE

Ensure you run this inside the virtual environment wheretp-mcp is installed, or point the "command" path directly to the python.exe/python binary of the virtual environment.

Security & Privacy

This server is designed to be completely secure and private:

100% Local: Runs on your local machine. No external databases, no middleware, no credential sharing.
Direct Connection: Authenticates directly with TrainingPeaks official servers using HTTPS.
No exposed ports: Uses standard input/output (stdio) to communicate with Claude Desktop. It does not open any network ports.

Development & Testing

To set up the project locally and run the tests:

# Clone the repository
git clone https://github.com/tildecomunicacion/trainingpeaks_mcp.git
cd trainingpeaks-mcp

# Create a virtual environment and install dependencies
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install -e ".[dev]"

# Run unit tests
pytest

License

MIT

Available Tools

8 tools

tp_add_workout_commentB

Add a new text comment to a specific workout by its workout ID.

ParametersJSON Schema

Name	Required	Description	Default
`workout_id`	Yes	The numeric ID of the workout.
`comment`	Yes	The comment text to add.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description bears full burden. It states 'add' implying mutation, but fails to disclose side effects (e.g., visibility, limits, overwrite behavior). This leaves behavioral gaps for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy. Every word is necessary and front-loaded. Impressively concise for a tool with two parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with two parameters, but lacks return value description (no output schema). Could note that comment is added to the workout's comment list. Differentiates from siblings enough but incomplete for full understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters described). The description adds no extra meaning beyond existing schema descriptions for 'workout_id' and 'comment', meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Add', the resource 'new text comment', and the target 'specific workout by its workout ID'. It effectively distinguishes from sibling tools like tp_get_workout_comments (read) and tp_create_workout (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives, nor any prerequisites (e.g., workout must exist) or conditions. The description lacks context for selecting this tool appropriately among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_create_workoutB

Create a planned TrainingPeaks workout on a specific date (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) with optional planned duration, distance, TSS, and description.

ParametersJSON Schema

Name	Required	Description
`date_str`	Yes	Workout planned date (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS for planned start time)
`sport`	Yes	Sport type
`title`	Yes	Workout title
`duration_minutes`	No	Optional planned duration in minutes
`distance_km`	No	Optional planned distance in kilometers
`tss_planned`	No	Optional planned Training Stress Score (TSS)
`description`	No	Optional planned workout description
`structure`	No	Optional interval structure as a JSON object. Structure format: {'primaryIntensityMetric': 'percentOfThresholdPace'\|'percentOfFtp', 'steps': [{'name': 'Warm Up', 'duration_seconds': 600, 'intensity_min': 50, 'intensity_max': 60, 'intensityClass': 'warmUp'}, {'type': 'repetition', 'reps': 4, 'steps': [{'name': 'Active Block', 'duration_seconds': 300, 'intensity_min': 88, 'intensity_max': 93, 'intensityClass': 'active'}, {'name': 'Recovery', 'duration_seconds': 120, 'intensity_min': 50, 'intensity_max': 60, 'intensityClass': 'rest'}]}]}. For Run (running) workouts, default is 'percentOfThresholdPace' (Pace). For Bike/MtnBike (cycling) workouts, default is 'percentOfFtp' (Power/Watts).

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It only states creation but does not disclose potential side effects (e.g., overwriting existing workouts), error conditions, or required permissions. This is insufficient for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the main action. It is efficient but could be shortened slightly by moving date format details to the parameter description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and no output schema or annotations, the description covers the main action and optional fields but lacks information about expected return values, error handling, or authentication requirements. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds value mainly for the structure parameter (detailed example and defaults) and date format specification. Other parameters are well-covered by schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and resource 'planned TrainingPeaks workout' with specific optional fields. It is distinct from sibling tools (e.g., tp_delete_workout, tp_get_workouts) as the only creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., tp_get_workouts for reading). It does not state any prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_delete_workoutA

Delete a planned workout from TrainingPeaks calendar by its workout ID.

ParametersJSON Schema

Name	Required	Description	Default
`workout_id`	Yes	The numeric ID of the workout to delete.

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey all behavioral traits. While it indicates the destructive nature of the operation, it lacks details on permanent effects, required permissions, or potential side effects. This is insufficient for a deletion tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately conveys the tool's purpose. Every word is meaningful, and there is no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation with one parameter and no output schema, the description provides the essential information. It could mention prerequisites (e.g., the workout must exist) or post-conditions, but the low complexity makes the current level acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the single parameter 'workout_id' as 'The numeric ID of the workout to delete.' The tool description adds minimal extra context by specifying 'by its workout ID.' Since schema coverage is 100%, the description adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete), the resource (a planned workout from TrainingPeaks calendar), and the method (by workout ID). It effectively distinguishes from sibling tools like tp_create_workout or tp_get_workouts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to delete a planned workout) but does not provide explicit guidance on when not to use it or mention alternative tools. It leaves the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_get_fitnessB

Get historical and current TrainingPeaks fitness, fatigue, and form metrics (CTL, ATL, TSB).

ParametersJSON Schema

Name	Required	Description
`days`	No	Days of history to fetch (default 90). Ignored if start_date/end_date are provided.
`start_date`	No	Optional start date (YYYY-MM-DD) for historical queries
`end_date`	No	Optional end date (YYYY-MM-DD) for historical queries

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only indicates a read operation with no disclosure of authentication, rate limits, error handling, or what happens with invalid dates or missing data. Lacks detail on response format or aggregation logic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, to the point. Could be improved by explaining acronyms or front-loading key details, but no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately describes purpose and parameters, but lacks behavioral information and output format details. Given no output schema, describing return structure would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all params documented in schema). The description adds context about what the data represents (CTL, ATL, TSB) but does not add new meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), the resource ('TrainingPeaks fitness, fatigue, and form metrics'), and specifies the acronyms (CTL, ATL, TSB). It distinguishes from sibling tools (e.g., workout, profile, weekly summary tools) by focusing on fitness metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 versus siblings, no exclusion criteria, and no alternative tool mentioned. The description implies it is for fetching fitness metrics but does not explain when it should be preferred over other tools like tp_get_weekly_summary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_get_profileA

Get athlete profile information from TrainingPeaks (athlete ID, name, email, account type).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly mentions the return fields, providing transparency. However, it does not disclose whether authentication is required, rate limits, or idempotency, which are typical for API tools. Still, for a read-only profile fetch, it is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource, provides specific details, and contains no filler words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists the fields returned. With no parameters or nested objects, it covers all necessary information for a simple profile fetch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the description does not need to add parameter info. Baseline for 0 params is 4, and the description does not detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 'athlete profile information', listing specific fields (ID, name, email, account type). It distinguishes itself from sibling tools which are all workout/comment related.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear when to use: to retrieve athlete profile. It does not provide explicit when-not-to-use or alternatives, but given the tool's simplicity, the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_get_weekly_summaryB

Get an aggregated weekly view of TrainingPeaks workouts and fitness metrics (CTL, ATL, TSB) for a specific week.

ParametersJSON Schema

Name	Required	Description	Default
`week_of`	No	Optional date within the week (YYYY-MM-DD). Defaults to today's week.

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but fails to mention important traits such as whether it is read-only, requires authentication, or any side effects. It only lists what metrics are returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence efficiently stating the tool's purpose. However, given the lack of annotations and output schema, a slightly more detailed description could fit without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description is adequate but incomplete; it does not explain the return format, data freshness, or whether the metric computations are standard. More context would improve agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'week_of' has 100% schema coverage with a clear description. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get' and the resource 'aggregated weekly view of TrainingPeaks workouts and fitness metrics (CTL, ATL, TSB)'. It distinguishes from sibling tools like tp_get_fitness (current metrics) and tp_get_workouts (individual workouts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for weekly summaries but provides no explicit guidance on when to use this tool versus alternatives like tp_get_fitness or tp_get_workouts, nor any conditions when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_get_workout_commentsB

Get comments associated with a specific workout by its workout ID.

ParametersJSON Schema

Name	Required	Description	Default
`workout_id`	Yes	The numeric ID of the workout.

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description implies a safe read operation but does not disclose potential error conditions, authorization needs, or response structure. It is adequate for a simple get but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler words. It is perfectly concise for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is incomplete: it does not specify the return format (e.g., list of comments) or any constraints like required authentication. Given no output schema, more detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of the parameter. The description adds no new meaning beyond confirming the parameter role, so baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the verb 'Get' and the resource 'comments associated with a specific workout', distinguishing it from sibling tools like tp_add_workout_comment. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor does it mention any prerequisites or exclusions. It only states the basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tp_get_workoutsA

List planned and completed workouts from TrainingPeaks in a date range (ISO format YYYY-MM-DD). Maximum range is 90 days.

ParametersJSON Schema

Name	Required	Description	Default
`start_date`	Yes	Start date (YYYY-MM-DD)
`end_date`	Yes	End date (YYYY-MM-DD)
`workout_filter`	No	Filter by status: all, planned, or completed	all

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description implies read-only operation but doesn't explicitly state safety. Mentions max range constraint but lacks details on quotas, authentication, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action verb, no wasted words. Clearly communicates key constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description does not mention what fields are returned (e.g., workout ID, type). Adequate for a list operation but could be more complete with return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 3 parameters with descriptions; description adds value by specifying ISO format for dates and the 90-day range constraint, which are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'List' and resource 'workouts', distinguishes from siblings like tp_get_fitness and tp_get_weekly_summary. Clearly states scope (planned and completed) and date range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: listing workouts in a date range with a 90-day limit. Does not mention when not to use or suggest alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv2.0.0Jun 23, 2026
- First observedtp_add_workout_comment
- First observedtp_create_workout
- First observedtp_delete_workout
- First observedtp_get_fitness
- First observedtp_get_profile
- First observedtp_get_weekly_summary
- First observedtp_get_workout_comments
- First observedtp_get_workouts

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: workout CRUD, comments, fitness metrics, profile, and weekly summary. No overlap in purpose.

Naming Consistency5/5

All tools follow the tp_verb_noun pattern in snake_case, with verbs like add, create, delete, get, and clear nouns. Consistent and predictable.

Tool Count5/5

8 tools is well-scoped for a training data server, covering workouts, comments, metrics, and profile without bloat or deficiency.

Completeness4/5

Covers core workflows: workout create/delete/get, comments add/get, fitness metrics, profile. Slight gaps like update workout and delete comment, but not critical for basic use.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

STAS Running Coach for Claude A
run.stas
Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.
Fitness Tracking Health & Wellness Education & Learning Tools
212
Fitness AI ConnectorOAuth
io.github.fmp-projects
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
Health & Wellness Fitness Tracking
22
Tally WorkoutOAuth
io.github.westvegh
First strength app Claude can write to: plan training in chat, it lands in the app ready to log.
Fitness Tracking Health & Wellness
2
gym-plusOAuth
plus.gym
Connect ChatGPT or Claude to your Gym Plus account to log and review workouts with AI coaching.
Fitness Tracking Health & Wellness
2

Related MCP Servers

Strava MCP Server
Health & Wellness Fitness Tracking
SkyBlob12
A
license
A
quality
D
maintenance
Connects Claude to your Strava account for analyzing training, predicting race times, and generating periodized training plans via natural language.
Updated 4 months ago (2026-04-27 13:27 UTC)
13
61
ISC
Strava MCP Server
Fitness Tracking Health & Wellness Sports
ArjanLig
A
license
A
quality
D
maintenance
Connects Strava training data to Claude, enabling personalized coaching through analysis of training load, workout planning, gear maintenance, and power metrics.
Updated 5 months ago (2026-03-26 18:45 UTC)
10
MIT
TrainingPeaks MCP Server
Fitness Tracking Health & Wellness
nagelflorian
F
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with TrainingPeaks accounts to analyze training data, manage workouts, update zones, and more using plain English.
Updated 5 months ago (2026-03-25 21:36 UTC)
3
-
TrainingPeaks MCP
Health & Wellness Fitness Tracking
lsantome
A
license
B
quality
C
maintenance
Connect TrainingPeaks to Claude and other AI assistants via the Model Context Protocol to query workouts, build structured intervals, manage calendar, track fitness trends, and control training through natural conversation.
Updated 2 months ago (2026-07-05 16:59 UTC)
65
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tildecomunicacion/trainingpeaks_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server