TrainingPeaks MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.3
Disambiguation5/5
Each tool serves a distinct purpose without overlap. For example, tp_get_fitness returns daily CTL/ATL/TSB, tp_fitness_trend projects future values, and tp_training_load_summary provides weekly/monthly TSS totals. Similarly, tp_get_workout gives raw data while tp_workout_analysis computes derived metrics. Auth tools are separate, and each analytics tool focuses on a unique aspect.
Naming Consistency4/5
All tools follow a tp_ prefix with snake_case naming. The verb usage is mostly consistent, with many using 'get_' (e.g., tp_get_fitness, tp_get_workouts) and others using descriptive verbs like 'fitness_trend' or 'performance_summary'. Some names like tp_auth_status or tp_training_zones_distribution are nouns rather than verbs, but overall the pattern is predictable.
Tool Count5/5
14 tools cover a broad yet focused range of fitness data operations including authentication, profile, workouts (planned and completed), fitness metrics, trends, peaks/PRs, and detailed analysis. Each tool earns its place without redundancy or excessive specialization.
Completeness5/5
The tool set provides comprehensive coverage for a read-only analytics server. It includes auth, profile, workout retrieval (planned and historical), fitness metrics, trends, peaks/PRs, workout analysis, training load summary, and zones distribution. No obvious gaps for the domain.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the return structure but does not state that the operation is read-only, what side effects exist (likely none), or any authentication/authorization requirements.
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 extremely concise (three sentences) with a clear Args/Returns structure. Every sentence adds value without redundancy.
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?
The tool is simple with one parameter and an output schema. The description adequately explains the functionality and return structure, but lacks usage context relative to sibling tools and behavioral disclosures due to missing annotations.
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?
With 0% schema description coverage, the description adds a brief clarification for the sole parameter ('The TrainingPeaks workout ID'), which is helpful but minimal. It does not provide additional context like format constraints or examples.
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 states it retrieves personal records from a specific workout and details the grouping structure. However, it does not explicitly differentiate from similar sibling tools like tp_get_peaks, which may also involve PRs.
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 is given on when to use this tool versus alternatives, nor any context about 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It mentions the return content (weekly/monthly TSS, ramp rate, comparison) but does not disclose that this is a read-only operation, required authentication, or any side effects. The behavior is partially transparent but lacks safety cues.
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 short (three sentences including the arg list) and front-loads the purpose. Each line adds value, though the argument section could be integrated more naturally.
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 the existence of an output schema (not visible), the description covers the key outputs, but without seeing the schema it's unclear if more detail is needed. For a tool analyzing load trends, the description is adequate but does not explain how to interpret the comparison or ramp rate.
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 0%, so the description should compensate. It explains the 'days' parameter as 'Number of days to analyze (default 90)'. This adds clarity beyond the schema, which only provided a default value, but does not elaborate on acceptable range or impact of different values.
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 states the tool analyzes training load trends over time and lists return values (TSS totals, averages, ramp rate, comparison). It is specific about the resource (training load) and verb (analyze trends), but does not explicitly differentiate from similar sibling tools like tp_fitness_trend or tp_performance_summary.
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 alternatives such as tp_fitness_trend or tp_workout_analysis. The description does not state prerequisites, when not to use, or how contexts differ.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes output content, not behavioral traits like side effects, authentication needs, rate limits, or data freshness. For a read-only summary tool, more transparency on data recency or calculation method would be beneficial.
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 concise paragraph with a clear list of returns. It is efficiently structured but could be slightly more front-loaded by leading with the purpose before parameter details.
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?
Given the output schema exists (context signal), the return values are adequately described. The description covers all key aspects of the tool's function with 0 required parameters, though it lacks details on data source or prerequisites.
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 description coverage is 0%, but the description explains the 'sport' parameter (type, default 'Bike', examples) and 'days' (number of days, default 90). This adds meaning beyond the schema, though enum values for sport could be made explicit.
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 tool provides an 'aggregated performance summary for a sport over time' and lists specific outputs (volume, intensity distribution, consistency metrics, PR timeline). It uses specific verbs and resource naming, and the purpose is distinguishable from siblings like tp_fitness_trend or tp_training_load_summary.
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 does not provide guidance on when to use this tool versus alternatives such as tp_training_load_summary or tp_fitness_trend. No context on prerequisites, exclusions, or optimal scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only describes what is returned, lacking information on authentication, rate limits, or side effects, which is a gap for a profile retrieval 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 three sentences, no unnecessary words, and front-loads the core purpose. Every sentence adds value.
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?
Given that an output schema exists (from context signals), the description need not detail return format. It provides key fields and notes the importance of athlete ID, making it largely complete for a simple profile getter.
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?
The tool has zero parameters, and the input schema is empty (100% coverage). The baseline for 0 parameters is 4, and no additional parameter info is needed.
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 tool retrieves the athlete's TrainingPeaks profile, listing specific fields like name, athlete ID, and email. It effectively distinguishes itself from sibling tools that focus on fitness trends, workouts, or auth status.
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 use before other queries by noting the athlete ID is needed for them, but does not explicitly state when to use this tool over alternatives or exclude certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns trend direction, rate of change, and projections, but does not disclose methodology (e.g., exponential moving average) or any behavioral traits like data requirements.
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 concise, with two sentences plus an args line, front-loading the main purpose and using no unnecessary words.
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?
Given the tool has an output schema, the description sufficiently covers input (days) and output (trend direction, rate of change, projected values). It lacks detail on the projection algorithm but remains functional.
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?
With zero schema description coverage, the description adds meaning by explaining the 'days' parameter as the number of days to analyze, including its default value, which the schema alone does not convey.
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 analyzing CTL/ATL/TSB trajectory and projecting future values, distinguishing it from sibling tools like tp_get_fitness that likely return current values.
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 trend analysis and projection but lacks explicit guidance on when to use this tool over alternatives like tp_performance_summary or tp_training_load_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output (derived metrics) but does not explicitly state that the tool is read-only, requires authentication, or has any side effects. Given no annotations, the description partially fulfills the transparency burden but leaves behavioral gaps.
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 concise: one sentence for purpose, then clear args and returns sections. No redundant information, every sentence adds value.
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 single-parameter analysis tool with an output schema, the description adequately explains inputs and outputs. It doesn't mention authentication or error conditions, but those are reasonable defaults given the sibling context; the output schema likely covers return structure.
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?
The only parameter (workout_id) is explained with the phrase 'The TrainingPeaks workout ID,' adding context beyond the schema's title 'Workout Id.' This helps the agent understand what value to provide, though format details (e.g., numeric) are implicit.
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 tool performs 'deep analysis' of a specific workout and explicitly lists derived metrics (efficiency factor, variability index, intensity distribution, comparison context), distinguishing it from raw workout retrieval tools like tp_get_workout.
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 analysis vs. raw data but provides no explicit guidance on when to use this tool over siblings like tp_performance_summary or tp_fitness_trend, nor does it mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that the tool scans workouts that have PRs, aggregates best values, and shows top records per duration/distance. This adds meaningful behavioral context beyond just 'get peaks', though it omits potential performance implications or auth requirements.
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 well-structured with a clear one-line summary followed by an Args section and then an elaboration. It is somewhat verbose but front-loaded with the main purpose. Slight trimming could improve conciseness without losing clarity.
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?
Given the presence of an output schema (making return format documentation unnecessary), the description covers the tool's operation sufficiently: it explains what it scans, how it aggregates, and what it displays. It doesn't miss critical aspects for a data retrieval tool.
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 description coverage is 0%, so the description must compensate. It provides details for all three parameters: sport allowed values (Bike, Run, Swim, Hike), days max (365), and pr_class options (Power, HeartRate, None). This adds value beyond the schema's type and default information.
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 tool gets personal records by scanning recent workouts for a given sport, using specific verbs like 'Get' and 'scanning'. It distinguishes itself by focusing on aggregated peaks over a time range, differentiating from sibling tools like tp_get_workout_prs which likely focus on individual workout PRs.
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 retrieving overall peaks across workouts and days, but it does not explicitly state when to use this tool versus alternatives like tp_get_workout_prs or tp_fitness_trend. No when-not or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly describes a read operation without mentioning side effects, but does not explicitly state it is read-only or safe.
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 concise, covering purpose, parameter, and return details in a few lines. Minor redundancy with the Args line could be streamlined.
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?
Given a single parameter and the presence of an output schema, the description provides sufficient context about inputs and outputs. However, it lacks details on error cases (e.g., invalid ID).
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?
The description adds value beyond the schema by explaining that the integer parameter is a TrainingPeaks workout ID and lists the types of data returned (power, HR, etc.), compensating for 0% schema coverage.
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 tool retrieves detailed information about a specific workout, distinguishing it from sibling tools like tp_get_workouts which likely list multiple workouts.
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 implies usage for a specific workout ID, and the sibling list provides context, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly describes a read-only analytical operation (breaking down workouts by zones) without any mention of side effects or destructive actions. The description adds transparency about what the tool outputs (training time and stress distribution).
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 concise with two clear paragraphs: one for purpose and one for parameter details. Every sentence adds value, and the docstring-style 'Args' section efficiently documents parameters. There is no wasted text.
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?
The description explains what the tool does, its analytical outcomes, and all parameters with defaults. Given that an output schema exists (not shown), the description does not need to detail return values. However, it could briefly mention the output format (e.g., zone breakdowns) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning beyond the schema. It explains defaults for start_date, end_date, and days (e.g., start_date defaults to {days} days ago, days default 30). This adds significant context that the schema alone does not provide.
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 tool analyzes training time and TSS distribution across intensity zones, with a specific verb 'analyze' and resource 'training zones distribution'. It highlights the ability to identify training patterns (polarized, pyramidal, threshold-heavy), distinguishing it from siblings like tp_training_load_summary or tp_performance_summary.
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 analyzing zone distribution over a date range but lacks explicit guidance on when to use this tool versus alternatives (e.g., tp_fitness_trend, tp_workout_analysis). No exclusion criteria or context for when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the API fetches extra history for exponential decay calculation, which is a notable hidden behavior. It also describes return values (daily load data, current status).
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 structured with a main purpose sentence, an Args section, and a Returns note. It is concise (7 sentences) with no fluff, front-loading the core function.
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 3 optional parameters, no enums, and an output schema, the description fully covers parameter interactions, return type, and the extra fetch behavior. It provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds critical meaning: explains days default 90, that start_date overrides days, and the expected date format (YYYY-MM-DD). This goes beyond the schema's minimal info.
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 it retrieves CTL, ATL, and TSB performance data, specifying the resource (fitness data) and action (get). It distinguishes from siblings by mentioning daily training load with computed values and extra history fetch.
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 explains parameter behavior (days vs start_date) but does not provide explicit guidance on when to use this tool over alternatives like tp_fitness_trend or tp_training_load_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses returned data fields (date, type, duration, etc.), defaults, and the 90-day API limit. It doesn't mention whether only completed workouts are returned or auth requirements, but overall transparency is strong.
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 well-structured with Args section, returns statement, and a note on API limit. It is concise with no fluff, each sentence earns its place.
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 annotations, the description covers parameters, return fields, and a key constraint. It is complete for a list tool; the presence of an output schema further reduces the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully. It explains each parameter with defaults, example values for workout_type, and limit default. This adds significant meaning beyond the bare 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 'Get a list of workouts from TrainingPeaks,' specifying the verb (get) and resource (list of workouts). This distinguishes it from siblings like 'tp_get_workout' which retrieves a single workout.
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 provides sensible defaults and example filter values, implying typical usage. However, it lacks explicit guidance on when to use this tool versus alternatives like 'tp_get_planned_workouts' or 'tp_workout_analysis'. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it 'clears the cached token and obtains a fresh one from the auth cookie', revealing the behavioral effect and a dependency (auth cookie). Missing details on failure modes, but sufficient for a 0-param 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?
Extremely concise: two sentences plus a lead-in line. Front-loaded with purpose, no wasted words, and every sentence adds value.
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 parameters and an output schema, the description fully covers when to use, what it does, and the behavioral effect. No missing information for an agent to correctly invoke it.
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?
No parameters exist, and schema coverage is 100%. Description adds nothing about parameters because there are none. Baseline score of 4 is appropriate for 0-param tools.
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 states 'Force refresh the TrainingPeaks bearer token' – a specific verb and resource. It clearly distinguishes from sibling tools like tp_auth_status which checks status, not refreshes.
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 says 'Use this if you're getting authentication errors', providing a clear condition for use. It implies it's a fix for stale tokens, though doesn't explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that it returns whether auth is valid and provides setup instructions if not. No side effects are expected for a read-only status check, and the output schema covers format details.
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 two sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence earns its place.
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?
For a simple auth-check tool with no parameters and an output schema, the description is complete. It covers what the tool does and what to expect.
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?
The tool has zero parameters, and schema coverage is 100% trivially. The description adds no parameter info, but baseline for 0 parameters is 4. No additional meaning needed.
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 tool checks TrainingPeaks authentication status, using a specific verb 'Check' and a clear resource. It inherently distinguishes from sibling tools which handle fitness data, workouts, etc.
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 implies usage before other TrainingPeaks tools by stating it returns auth validity and instructions if not authenticated. However, it does not explicitly state when to use or when not to use, though context is clear for an auth check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: returns specific fields (date, type, duration/distance/TSS, instructions, comments), chronological sorting, and a 90-day API limit.
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 concise, using a clear structure with an Args block and Returns list, every sentence adds value without 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 4 parameters, no required/ enums, and an output schema present, the description is complete: it explains parameters, return fields, sorting, and limitation, sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining each parameter: start_date/end_date as date strings, workout_type with examples, and limit with default value, adding meaning beyond bare 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 verb 'Get' and the resource 'upcoming planned workouts from TrainingPeaks', distinguishing it from siblings like tp_get_workouts (completed workouts) and tp_get_workout (single workout).
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 explains default dates, sorting, and API limits, providing clear usage context but does not explicitly exclude alternatives like tp_get_workouts for completed workouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tp-mcp-server MCP server](https://glama.ai/mcp/servers/banananovej-chuan/tp-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/banananovej-chuan/tp-mcp-server)

Score Badge

Copy to your README.md:

[![tp-mcp-server MCP server](https://glama.ai/mcp/servers/banananovej-chuan/tp-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/banananovej-chuan/tp-mcp-server)

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/banananovej-chuan/tp-mcp-server'

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