Skip to main content
Glama
dengxuhui

igpsport-mcp

by dengxuhui
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

igpsport-mcp

English | 简体中文

A local MCP server that connects your iGPSport cycling data to LLM clients like Claude. Analyze your training in natural language: "How's my training load this week?" "Compare my two long rides from last week and this week." "What's my ranking on that climb I starred?" "How many kilometers did I ride this year, and what are my personal bests?" — and even have Claude prescribe workouts for you: "Build me a 2×20 SST session based on my FTP and push it to my head unit."

Key differentiator: Derived training metrics — NP / IF / TSS / CTL / ATL / TSB — are computed server-side in the MCP layer before being returned. The LLM receives story-ready numbers, not raw stream data.

You:   What's my training load trend over the last 90 days? Should I back off?
Claude (via analyze_training_load):
       Current CTL (Fitness) 72, ATL (Fatigue) 91, TSB (Form) -19 — you're in a significant fatigue hole.
       TSS has been above CTL for the past two weeks. Consider a 3–5 day recovery block to get TSB back above -5…

Demo

igpsport-mcp demo

⚠️ Unofficial project. This tool works by simulating iGPSport web client requests. iGPSport may change their API at any time, which could break functionality. Please evaluate account risk yourself — use at your own risk. Runs entirely locally over stdio — your data never touches any third-party server.

Related MCP server: trainingpeaks-mcp

Quick Start (Recommended)

This tool is an MCP server and requires an MCP-capable client (e.g. Claude Desktop / Claude Code / Cursor). Once you have a client ready, three steps:

1. Install uv (a standalone tool — you do not need Python pre-installed, uv handles the runtime automatically):

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows (PowerShell)
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

2. Install globally and run the setup wizard (interactively enter your phone/email and password — credentials stay local). The commands are the same on both systems; run them in Terminal on macOS or PowerShell on Windows:

uv tool install igpsport-mcp
igpsport-mcp --setup

If igpsport-mcp is not found after installation, open a new terminal/PowerShell window so PATH updates take effect (uv places executables in ~/.local/bin on macOS, %USERPROFILE%\.local\bin on Windows).

The wizard saves credentials to a config file (owner-readable only) and prints a copy-paste ready MCP configuration block. Config file locations:

  • macOS: ~/.igpsport-mcp/config.json

  • Windows: C:\Users\YourName\.igpsport-mcp\config.json

3. Paste the printed config into your client, then restart the client (see "Connect to Claude" below).

Want to verify your credentials before pasting? Run igpsport-mcp --check — it performs a real login and prints ✅ success or ❌ the reason for failure, so you don't add it to your client only to find it broken.

Need to print the config snippet again later? igpsport-mcp --mcp-config anytime.

Developers / users with an existing Python environment: use uvx igpsport-mcp for one-shot runs, or configure via environment variables below instead of the wizard.

CLI Usage

Running with no arguments starts the MCP server in stdio mode (this is what your MCP client invokes — you normally don't run it manually). Other subcommands:

Command

Purpose

igpsport-mcp --setup

Interactive setup wizard: enter phone/email + password, saved to local config.json

igpsport-mcp --mcp-config

Print a copy-paste ready MCP client configuration block

igpsport-mcp --check

Perform a real login to verify credentials (account is shown masked)

igpsport-mcp --lang en|zh

Set output language (also settable via IGPSPORT_LANG env var; default zh)

igpsport-mcp --version

Print version number

igpsport-mcp --help

Show help

Configuration (Environment Variables)

Users who ran the --setup wizard can skip this section — credentials are already stored. The section below is for users who prefer environment variables, or need to manage credentials across CI / multiple environments. Env vars take priority over config.json.

Variable

Required

Description

IGPSPORT_USERNAME

✅

iGPSport account (phone number for CN / email for international)

IGPSPORT_PASSWORD

✅

Password

IGPSPORT_REGION

Optional

Region, default cn (China server app.igpsport.cn); international users set intl (app.igpsport.com)

IGPSPORT_FTP

Optional

Functional Threshold Power in watts. Leave blank to auto-read from your iGPSport profile; set to override

IGPSPORT_LTHR

Optional

Lactate Threshold Heart Rate in bpm, used for HR zones and hrTSS fallback. Also auto-read from iGPSport; set to override

IGPSPORT_LANG

Optional

Output language, zh (default) or en

IGPSPORT_CACHE_DIR

Optional

Cache directory; defaults to ~/.cache/igpsport-mcp (macOS) / C:\Users\You\.cache\igpsport-mcp (Windows)

IGPSPORT_LOG_LEVEL

Optional

Default INFO

FTP / LTHR are now auto-read from your iGPSport athlete profile by default (along with body weight and max HR), so you normally don't need to set them manually. Only set the env vars when you want to use thresholds different from what's in the app. If your iGPSport profile also has no FTP set, IF / TSS / CTL / ATL / TSB cannot be computed — either add FTP in iGPSport or set IGPSPORT_FTP.

International Edition Support

Switch to the international edition (app.igpsport.com) by setting IGPSPORT_REGION=intl. The international and China servers use separate accounts — you must register separately at app.igpsport.com.

Differences from the China server:

  • No WASM signing — authentication uses pure JWT, a simpler design

  • Segment features are unavailable (international segments are in beta, listing is empty)

  • Training parameter endpoint uses v2 path; yearly statistics path differs (auto-adapted internally)

  • Workout course format is cross-region compatible — zero changes in the IR compilation layer

Example configuration:

# via env vars
export IGPSPORT_REGION=intl
export IGPSPORT_USERNAME=your_email@example.com
export IGPSPORT_PASSWORD=your_password

Or select "2. International" in the first step of the --setup wizard.

International edition FIT files are stored on OSS in the US (oss-us-west-1). Downloads may be slightly slower for users in China.

Connect to Claude

Claude Desktop

Open the config file claude_desktop_config.json (create it if it doesn't exist), paste the content below, then fully quit and reopen Claude Desktop. File locations:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json (i.e. C:\Users\You\AppData\Roaming\Claude\claude_desktop_config.json)

You can also open this file directly from Claude Desktop via Settings → Developer → Edit Config.

After running --setup (credentials in config.json, leave env empty — this is what --mcp-config prints):

{
  "mcpServers": {
    "igpsport": {
      "command": "igpsport-mcp",
      "args": [],
      "env": {}
    }
  }
}

Or skip the wizard and use uvx with environment variables:

{
  "mcpServers": {
    "igpsport": {
      "command": "uvx",
      "args": ["igpsport-mcp"],
      "env": {
        "IGPSPORT_USERNAME": "your_phone_or_email",
        "IGPSPORT_PASSWORD": "your_password"
      }
    }
  }
}

FTP / LTHR are auto-read from your iGPSport profile by default — no need to set them. Only add "IGPSPORT_FTP": "250" or "IGPSPORT_LTHR": "160" in env if you want to override what's in the app.

Claude Code

After the wizard (credentials stored):

claude mcp add igpsport --scope user -- igpsport-mcp

Or with uvx + env vars:

claude mcp add igpsport --scope user \
  --env IGPSPORT_USERNAME=your_phone_or_email \
  --env IGPSPORT_PASSWORD=your_password \
  -- uvx igpsport-mcp

Verify with /mcp or claude mcp list — status should be connected.

OpenClaw

OpenClaw uses stdio for MCP, the same protocol as Claude Desktop / Claude Code, so the configuration above works directly.

Method 1: Ask OpenClaw in natural language (recommended)

First install with uv tool install igpsport-mcp and run igpsport-mcp --setup. Then, in your connected chat channel, simply tell OpenClaw:

I installed igpsport-mcp. Help me configure it in OpenClaw.

It will locate the binary path, verify credentials with igpsport-mcp --check, write the config via openclaw mcp add, and probe it — all without you touching a command line or JSON.

Method 2: One-liner

# After the wizard (credentials stored)
openclaw mcp add igpsport --command igpsport-mcp

# Or with uvx + env vars
openclaw mcp add igpsport --command uvx --args igpsport-mcp \
  --env IGPSPORT_USERNAME=your_phone_or_email \
  --env IGPSPORT_PASSWORD=your_password

This writes to ~/.openclaw/openclaw.json under mcp.servers.igpsport. You can also edit the file manually:

{
  mcp: {
    servers: {
      igpsport: {
        command: "igpsport-mcp",
        args: [],
        env: {}
      }
    }
  }
}

Verification:

openclaw mcp list      # should show igpsport
openclaw mcp status    # igpsport: stdio
openclaw mcp probe     # igpsport: 17 tools, resources, prompts

The mcp field is hot-reloaded — no gateway restart needed; it takes effect in the next conversation turn. Use openclaw mcp reload to force-refresh the runtime cache if needed. Then ask questions in natural language from any connected channel (Discord, Telegram, Slack, etc.).

Not connecting? Run igpsport-mcp --check in a terminal first to isolate the problem:

  • ❌ Login failed → credential issue; re-run igpsport-mcp --setup.

  • ✅ Success but the client still can't connect → likely igpsport-mcp / uvx isn't in the client's PATH (Claude Desktop in particular often can't see the login shell's PATH). Replace command in the config with the absolute path:

  • macOS: run which igpsport-mcp (or which uvx) in Terminal, e.g. /Users/You/.local/bin/igpsport-mcp.

  • Windows: run where.exe igpsport-mcp (or where.exe uvx) in PowerShell, e.g. C:\Users\You\.local\bin\igpsport-mcp.exe. In JSON, backslashes must be doubled, e.g. "command": "C:\\Users\\You\\.local\\bin\\igpsport-mcp.exe".

Updates

For uv tool install installations (both systems), upgrade to the latest:

uv tool upgrade igpsport-mcp

Restart your client after upgrading (fully quit and reopen Claude Desktop; reconnect for Claude Code). Check current version: igpsport-mcp --version.

For uvx igpsport-mcp one-shot users, no manual upgrade is needed — uvx uses the latest version by default. If a stale version is cached locally, use uvx igpsport-mcp@latest or clear the cache with uv cache clean first.

Uninstall

1. Remove the program (same for both systems):

uv tool uninstall igpsport-mcp

2. Remove local credentials and cache (optional, for a complete cleanup):

# macOS / Linux (Terminal)
rm -rf ~/.igpsport-mcp        # credentials (config.json)
rm -rf ~/.cache/igpsport-mcp  # tokens, SQLite, FIT file cache
# Windows (PowerShell)
Remove-Item -Recurse -Force "$env:USERPROFILE\.igpsport-mcp"
Remove-Item -Recurse -Force "$env:USERPROFILE\.cache\igpsport-mcp"

3. Remove igpsport from your client config: Claude Desktop — delete the igpsport block under mcpServers in claude_desktop_config.json; Claude Code — claude mcp remove igpsport; OpenClaw — openclaw mcp unset igpsport (or delete the igpsport block under mcp.servers in ~/.openclaw/openclaw.json).

For uvx igpsport-mcp one-shot users, there is no "program" to uninstall — just do steps 2 and 3.

17 Tools Provided

Activities & Training (9)

Tool

Purpose

list_activities

List activities (supports date range, pagination)

get_activity_summary

Single-activity derived metrics: NP / IF / TSS / work, HR & power zone time-in-zone

get_activity_streams

Time-series data (enforced downsampling + channel selection, token-friendly)

get_activity_laps

Lap / segment data (per-lap NP)

get_athlete_profile

Training parameters: FTP / LTHR (auto-read from iGPSport or overridden via env vars); body weight and max HR always from iGPSport; includes zone boundaries

get_athlete_stats

Period-aggregated statistics (computed locally from activity list)

estimate_thresholds

Estimate FTP / LTHR from recent rides' mean-max curves for riders who haven't done a formal test (Coggan 20-min, critical-power cross-check, Friel HR field test); each value carries a confidence level + evidence + a "confirm with a formal test" caveat. Read-only — never writes back, the rider applies it manually

compare_activities

Compare multiple activities (2–5)

analyze_training_load

CTL / ATL / TSB trend + form interpretation (the killer query)

Segments (3)

Tool

Purpose

list_segments_collected

List starred segments with your best time

get_segment_detail

Segment details: distance / gradient / elevation gain + KOM + fastest leaderboard + your PR

get_segment_rank

Segment leaderboard (query_type 1=overall, 2=yearly, etc.), includes your rank

Statistics & Achievements (1)

Tool

Purpose

get_member_statistics

Official yearly statistics & personal bests: total distance / duration / calories / TSS, monthly distance, distance milestones, various PRs (longest / longest duration / fastest / max power / max elevation)

Training Courses (4) — the only "write" capability

Tool

Purpose

create_workout

Describe a structured training session in natural language (warmup / main set / intervals / cooldown), compile it to iGPSport's native format, and push it to your head unit app; supports dry_run=true to preview without sending; with_calendar=true additionally returns a standard iCalendar (VEVENT) artifact for downstream tools like Apple Calendar, Reminders, or Notion

list_workouts

Pull all custom workouts from the server in real time (reflects deletions made in the app)

get_workout_detail

Fetch the full structure of a specific workout

delete_workout

Delete a workout. Destructive and irreversible: defaults to a confirmation preview; requires explicit confirm=true to actually delete

Power targets support absolute watts, %FTP (auto-converted using your FTP), and power zones; heart rate, cadence, and speed targets are also supported. Duration can be set by time / distance / calories / manual lap button. Created workouts appear in the iGPSport app under "Training Courses" and can be synced to your head unit for execution.

Derived Metrics Reference

  • NP (Normalized Power): ((30 s rolling average power)^4 mean)^0.25; stream is resampled to 1 Hz before computation.

  • IF = NP / FTP; TSS = duration_s × NP × IF / (FTP × 3600) × 100.

  • CTL / ATL / TSB: exponential weighted moving averages of daily TSS (α = 1/42, 1/7); TSB = CTL − ATL.

  • No-power-meter fallback: hrTSS = (duration_s / 3600) × (avg HR / LTHR)² × 100, annotated estimated from HR.

  • Zone models: HR uses Friel (LTHR-based); Power uses Coggan 7-zone (FTP-based).

FAQ

Q: Do I need a power meter? A: No. Without a power meter, heart-rate-based metrics work normally and TSS falls back to hrTSS (lower accuracy, annotated as such). However, setting FTP is recommended to unlock power-based metrics.

Q: Is my data uploaded anywhere? A: Not to any third party. Other than reading/writing your own iGPSport account data (reading activities/stats, and create_workout/delete_workout for your own training courses), everything happens locally. FIT files and derived metrics are cached locally.

Q: Can create_workout / delete_workout mess up my data? A: create_workout only adds new training courses — you can use dry_run=true to preview the compiled result before deciding to send. delete_workout is irreversible and defaults to a confirmation preview; it requires explicit confirm=true to actually delete — so an LLM cannot delete a course without your confirmation.

Q: Does with_calendar automatically write to my calendar? A: No. This server only produces a standard iCalendar (VEVENT) text artifact — it never touches any calendar API or sends data externally. Whether the event is actually written to a calendar is up to your LLM client to hand off to another calendar/reminder tool (e.g. Apple Calendar, Reminders, or a Notion MCP). Since a workout is a template with no execution date, the DTSTART is the placeholder {{SCHEDULED_DATE}} — the downstream consumer fills in the actual date.

Q: What if the API breaks? A: iGPSport may change their API, which could cause breakage — the tool will throw a clear error. Please report issues at Issues.

Q: Does it support running / other head units? A: No. This project focuses exclusively on iGPSport cycling data.

Q: What's different about the international edition? A: International and China server accounts are separate. The international edition lacks segment features (beta, listing is empty) and uses a simpler authentication mechanism (no WASM signing). Activities, training courses, and statistics work the same. See the "International Edition Support" section for details.

Development

uv sync --extra dev
uv run pytest            # tests
uv run pytest -m integration   # online integration tests
ruff check . && ruff format .  # lint / format

License

MIT. This project is not affiliated with iGPSport in any way.

Available Tools

8 tools
analyze_training_loadB

CTL/ATL/TSB daily trend + current form interpretation over the last N days.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo
end_dateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool returns daily trends and form interpretation, implying read-only behavior. However, it lacks details on authentication requirements, rate limits, or any potential side effects. The behavioral intent is clear but not fully transparent.

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 efficient sentence that conveys the core functionality. It is front-loaded with key acronyms and purpose. However, it could be slightly more structured (e.g., listing what the tool returns) without losing 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?

Given that an output schema exists (though not visible), the description is adequate for a tool that calculates training load metrics. It mentions the trend and interpretation over N days. However, it does not explain the output structure or how the tool relates to the athlete's data, which might be needed for full contextual understanding.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the parameters. It references 'over the last N days,' which loosely describes the 'days' parameter, but 'end_date' is not mentioned at all. The description fails to add meaning beyond the schema structure.

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's purpose: analyzing CTL/ATL/TSB daily trends and providing current form interpretation over N days. It distinguishes from sibling tools like list_activities or get_activity_summary by focusing on training load metrics. However, it assumes knowledge of the acronyms CTL/ATL/TSB, which might not be immediately clear to all agents.

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 when-to-use or when-not-to-use guidance is provided. The description implies use for training load trend analysis, but does not compare with sibling tools or specify contexts where this tool is preferred or inappropriate.

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

compare_activitiesB

Compare 2-5 rides across metrics with per-metric delta% and a narrative hint.

ParametersJSON Schema
NameRequiredDescriptionDefault
ride_idsYes
metricsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description partially covers behavior by mentioning output format (delta%, narrative hint). However, it doesn't disclose whether the tool is read-only, auth requirements, or any 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?

Single sentence, front-loaded with purpose, no redundant information. Perfectly concise.

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 output schema exists, the description doesn't need to detail return values entirely, but it lacks context on ride count limits, metric definitions, and error handling. Adequate but leaves ambiguity.

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

Parameters2/5

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

Schema coverage is 0%, and the description adds minimal meaning. It mentions 'rides' and 'metrics' but does not explain ride_ids format or valid metric values. The default null for metrics is implied but not clarified.

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 compares 2-5 rides across metrics with specific outputs (per-metric delta% and narrative hint). It distinguishes from siblings like analyze_training_load or get_activity_summary by focusing on multi-ride comparison.

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 versus alternatives like get_activity_summary for single rides or analyze_training_load for training load. The description does not specify prerequisites or exclusions.

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

get_activity_lapsC

Per-lap splits with per-lap NP computed from the record stream.

ParametersJSON Schema
NameRequiredDescriptionDefault
ride_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It mentions computation of NP from the record stream, implying a read operation, but does not explicitly state safety (read-only), required permissions, side effects, rate limits, or error conditions. The description is insufficient for an agent to understand behavioral expectations.

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 extremely concise at 12 words, with one sentence that front-loads the key output. It could be improved by clarifying the verb, but it is efficient with no wasted words.

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 output schema exists, the description does not need to detail all return fields, but it should explain the computed metric NP and how splits are organized. It feels incomplete for an agent unfamiliar with cycling metrics, but the output schema may compensate.

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

Parameters2/5

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

The only parameter ride_id is self-explanatory from its name, but schema coverage is 0% and the description does not elaborate on its format, constraints, or relationship to the returned data. The description adds no meaning beyond the parameter name.

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 'Per-lap splits with per-lap NP computed from the record stream' clearly indicates the tool returns lap-level data with computed normalized power, distinguishing it from siblings like get_activity_streams (raw data) or get_activity_summary (overall data). However, it is phrased as a noun phrase rather than a verb phrase, missing an explicit action word like 'Retrieve'.

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 provided on when to use this tool versus alternatives such as get_activity_streams or get_activity_summary. There is no information about prerequisites, data freshness, or when this tool is appropriate.

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

get_activity_streamsB

Time-series channels as compact bare arrays. Channels default to power+hr; resolution one of 1s/5s/10s/30s/1min (default 10s to keep tokens sane).

ParametersJSON Schema
NameRequiredDescriptionDefault
ride_idYes
channelsNo
resolutionNo10s
start_offset_sNo
end_offset_sNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It mentions 'to keep tokens sane' hinting at token usage, but does not disclose other behavioral traits like rate limits, auth needs, or side effects. It does not explicitly state the tool is read-only.

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 core purpose, no wasted words. Ideal length for a simple tool.

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?

Given 5 parameters and an output schema, the description is too sparse. It leaves many questions about available channels, offset behavior, and response format, which is not fully compensated by the output schema.

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

Parameters2/5

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

Schema coverage is 0%, yet the description only adds meaning for two of five parameters (channels default, resolution default). It does not explain start_offset_s, end_offset_s, or ride_id 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 tool returns time-series channels as compact bare arrays, with defaults for channels and resolution. This distinguishes it from sibling tools that provide summaries or analyses.

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 vs. siblings like get_activity_summary or get_activity_laps. The description implies use for raw data but lacks explicit context.

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

get_activity_summaryA

Derived metrics for one ride: NP/IF/TSS/work, HR & power zone time.

ParametersJSON Schema
NameRequiredDescriptionDefault
ride_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It indicates the metrics are 'derived', suggesting computation, but does not mention rate limits, data freshness, or error handling. The brief description is sufficient for a simple read-only tool but lacks explicit behavioral traits.

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 is front-loaded with key information ('Derived metrics for one ride') and lists specific metrics. No unnecessary words or redundancy.

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's simplicity (one required parameter, no nested objects) and the presence of an output schema, the description provides sufficient context about the returned metrics. However, it lacks guidance on edge cases like missing ride or access errors.

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

Parameters2/5

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

Schema coverage is 0%, and the description does not add any detail about the 'ride_id' parameter (e.g., format, required uniqueness). The description only implies it identifies a ride, leaving the agent with minimal guidance beyond the schema's basic type.

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 explicitly states 'Derived metrics for one ride' and lists specific metrics (NP/IF/TSS/work, HR & power zone time), making it clear what the tool does and distinguishing it from siblings like get_activity_laps or get_activity_streams which provide raw data.

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 obtaining summary metrics for a single ride but does not explicitly specify when to use this tool over alternatives (e.g., compare_activities or analyze_training_load) nor provide exclusions.

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

get_athlete_profileA

Athlete training parameters (FTP/LTHR from config) with HR/power zone bounds.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided. Description implies read-only access but does not explicitly state safety (non-destructive), authentication needs, or rate limits. Minimal behavioral disclosure beyond the basic return type.

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 concise sentence with no redundancy. Front-loads key information (what it returns) and is immediately useful.

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?

Has output schema to define return values. Description mentions specific parameters (FTP, LTHR) and zones, which is sufficient for a no-argument getter. Could hint that data is per athlete and from config, but not necessary.

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, so schema coverage is 100%. Description adds no parameter info, which is acceptable as there are none. Baseline for zero parameters is 4.

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 returns athlete training parameters (FTP, LTHR) and zone bounds from config. It uses specific terms and distinguishes from sibling tools like get_athlete_stats which probably returns aggregate stats, not config parameters.

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 versus siblings like analyze_training_load or get_athlete_stats. The description does not mention contexts, prerequisites, or alternatives.

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

get_athlete_statsC

Aggregate distance/duration/elevation over week|month|year|all.

ParametersJSON Schema
NameRequiredDescriptionDefault
periodNomonth
end_dateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/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 does not mention that this is a read-only operation, does not disclose any destructive behavior, auth needs, or side effects. Only the basic aggregation is stated.

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, no fluff. Efficiently conveys the core purpose. Could be slightly more structured but highly concise.

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 two parameters and an output schema, the description covers the main idea. However, missing behavioral context (e.g., read-only) and parameter details make it minimally adequate.

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

Parameters2/5

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

Schema description coverage is 0%, but the description adds the allowed period values (week, month, year, all). However, it does not explain the 'end_date' parameter or how values are interpreted. Incomplete parameter documentation.

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 aggregates distance/duration/elevation over specified time periods (week, month, year, all). It distinguishes from sibling tools like get_activity_summary (single activity) and analyze_training_load (analysis).

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 vs alternatives, no prerequisites or exclusions. It simply describes the aggregation without context.

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

list_activitiesC

List rides with optional ISO-8601 date range and paging (cached, units fixed).

ParametersJSON Schema
NameRequiredDescriptionDefault
start_dateNo
end_dateNo
limitNo
offsetNo
sport_typeNocycling

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/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. It mentions 'cached' and 'units fixed', giving some behavioral insight, but fails to disclose other traits like read-only nature, rate limits, or response behavior for missing data. Significant gaps remain.

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 concise sentence, front-loading the core action and key features. While efficient, it could include more detail without sacrificing brevity, but it earns a high score for avoiding verbosity.

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?

Despite having an output schema and 5 parameters, the description does not mention sport_type filtering or explain the caching behavior's impact. It also uses 'rides' instead of 'activities', potentially confusing. The description is incomplete for a list tool with filtering and paging.

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 description must compensate. It explains date range (start_date, end_date) and paging (limit, offset) as optional, but omits the sport_type parameter entirely. This partial coverage provides basic meaning but leaves one parameter undocumented.

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 lists rides (activities) with optional date range and paging. It uses a specific verb 'List' and resource 'rides', which is distinct from sibling tools like get_activity_summary or compare_activities, though the term 'rides' slightly diverges from the tool name 'list_activities'.

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 versus alternatives such as get_activity_summary or compare_activities. The description lacks any 'when to use' or 'when not to use' information, leaving the agent without context for selection.

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

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

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a distinct aspect: training load analysis, activity comparison, lap splits, raw streams, summary metrics, athlete profile, aggregate stats, and activity listing. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (underscore-separated) with 'get_' for most retrievals and 'analyze_'/'compare_' for specific operations. No mixing of conventions.

Tool Count5/5

8 tools cover the domain of cycling/fitness data retrieval without being excessive. Each tool serves a clear purpose, and the count is within the ideal 3-15 range.

Completeness4/5

The tool set covers core operations: listing, summary, streams, laps, athlete profile, stats, training load, and comparison. A minor gap is the lack of route/segment data, but the core analytics are well represented.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/dengxuhui/igpsport-mcp'

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