Which integrations are available for this server?

Provides tools for interacting with the Strava API to retrieve and analyze athlete activities, including running, cycling, swimming records, and athlete statistics.

How do I use Strava 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., "@Strava MCP Server Show my last 10 runs" 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.

Strava MCP Server

by groundcobra009

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Strava MCP Server

Strava APIとMCP（Model Context Protocol）を統合するサーバーです。

このMCPサーバーを使用することで、ClaudeなどのAIアシスタントから直接Stravaのアクティビティデータを取得・分析できます。ランニングやサイクリングの記録を会話形式で確認したり、統計情報を簡単に照会できます。

📦 対応クライアント

このMCPサーバーは以下のクライアントで使用できます：

✅ Claude Desktop - Anthropic公式デスクトップアプリ
✅ Cursor - AI統合コードエディタ
✅ Manus - AIアシスタントプラットフォーム
✅ Dify - ノーコードAIアプリケーションプラットフォーム
⚠️ ChatGPT（開発モード） - Custom GPT Actions 経由（HTTPラッパーが必要）

Related MCP server: Strava MCP Server

インストール

npmからインストール

npm install -g @keitaro_aigc/strava-mcp-server

またはプロジェクトローカルに：

npm install @keitaro_aigc/strava-mcp-server

ソースからビルド

git clone https://github.com/yourusername/strava-mcp-server.git
cd strava-mcp-server
npm install
npm run build

主な機能

このMCPサーバーは以下のツールを提供します：

1. `get_activities` - アクティビティ一覧の取得

最近のランニング、サイクリング、水泳などのアクティビティ一覧を取得します。

パラメータ:
- page (オプション): ページ番号（デフォルト: 1）
- per_page (オプション): 1ページあたりの件数（デフォルト: 30、最大: 200）
取得できる情報: アクティビティ名、距離、時間、平均速度、獲得標高など

2. `get_activity` - 特定アクティビティの詳細取得

指定したアクティビティIDの詳細情報を取得します。

パラメータ:
- activity_id (必須): アクティビティのID
取得できる情報: 詳細な統計、ラップタイム、心拍数、パワーデータなど

3. `get_athlete` - アスリートプロフィールの取得

認証されたアスリート（自分自身）のプロフィール情報を取得します。

取得できる情報: 名前、体重、所在地、性別など

4. `get_athlete_stats` - 統計情報の取得

アスリートの累計統計や最近の統計を取得します。

パラメータ:
- athlete_id (必須): アスリートのID
取得できる情報: 累計距離、累計時間、最近4週間の統計、今年の統計など

セットアップ

前提条件

Node.js 18以上がインストールされていること
Stravaアカウントを持っていること
Claude DesktopまたはMCP対応クライアントがインストールされていること

ステップ1: Strava APIの認証情報を取得

Strava APIを使用するには、アプリケーションを作成してAPI認証情報を取得する必要があります。

1.1 Stravaアプリケーションの作成

Strava API設定ページにアクセス
「Create App」または「My API Application」をクリック
以下の情報を入力：
- Application Name: 任意の名前（例：「My MCP Server」）
- Category: 適切なカテゴリを選択
- Club: 空欄でOK
- Website: 任意のURL（例：http://localhost）
- Authorization Callback Domain: localhost
- Application Description: 任意の説明
利用規約に同意して「Create」をクリック

1.2 Client IDとClient Secretの確認

アプリケーションを作成すると、以下の情報が表示されます：

Client ID: 数字の羅列（例：123456）
Client Secret: 英数字の文字列（例：abc123def456）

これらをメモしておいてください。

1.3 Refresh Tokenの取得

以下のURLをブラウザで開いてください（YOUR_CLIENT_IDを実際のClient IDに置き換える）：

https://www.strava.com/oauth/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=http://localhost&approval_prompt=force&scope=activity:read_all

Stravaにログインして「Authorize」をクリック
リダイレクト後のURL（http://localhost/?...）のアドレスバーからcodeパラメータの値をコピー
- 例：http://localhost/?code=abc123xyz789の場合、abc123xyz789をコピー
ターミナルで以下のコマンドを実行（各値を実際の値に置き換える）：

curl -X POST https://www.strava.com/oauth/token \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d code=YOUR_CODE \
  -d grant_type=authorization_code

レスポンスに含まれるrefresh_tokenの値をメモ：

{
  "access_token": "...",
  "refresh_token": "abc123...",  ← この値をメモ
  "expires_at": 1234567890
}

ステップ2: Claude Desktopでの設定

Claude Desktopの設定ファイル（claude_desktop_config.json）に以下を追加：

macOS

Claude Desktopの設定ファイルを開く：

open ~/Library/Application\ Support/Claude/claude_desktop_config.json

以下の内容を追加（既存の設定がある場合はmcpServersセクションに追加）：

{
  "mcpServers": {
    "strava": {
      "command": "npx",
      "args": ["-y", "@keitaro_aigc/strava-mcp-server"],
      "env": {
        "STRAVA_CLIENT_ID": "your_client_id",
        "STRAVA_CLIENT_SECRET": "your_client_secret",
        "STRAVA_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

Claude Desktopを再起動
Claude Desktopの右下に🔨マークが表示され、「strava」が利用可能になっていることを確認

Windows

Claude Desktopの設定ファイルを開く：

notepad %APPDATA%\Claude\claude_desktop_config.json

macOSと同じJSON設定を追加
各値を実際の値に置き換え
Claude Desktopを再起動
🔨マークで「strava」が利用可能になっていることを確認

ステップ2-B: Cursor での設定

Cursor エディタで使用する場合：

設定ファイルの場所

macOS/Linux: ~/.cursor/mcp.json
Windows: %APPDATA%\Cursor\User\mcp.json

設定手順

設定ファイルを作成または編集：

# macOS/Linux
mkdir -p ~/.cursor
nano ~/.cursor/mcp.json

# Windows
mkdir %APPDATA%\Cursor\User
notepad %APPDATA%\Cursor\User\mcp.json

以下の内容を追加：

{
  "mcpServers": {
    "strava": {
      "command": "npx",
      "args": ["-y", "@keitaro_aigc/strava-mcp-server"],
      "env": {
        "STRAVA_CLIENT_ID": "your_client_id",
        "STRAVA_CLIENT_SECRET": "your_client_secret",
        "STRAVA_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

各値を実際の認証情報に置き換え
Cursor を再起動
Cursor の AI チャットで MCP ツールが利用可能になっていることを確認

ステップ2-C: Manus での設定

Manus で使用する場合：

設定手順

Manus の設定画面を開く
MCP サーバー設定セクションに移動
新しいサーバーを追加：

{
  "name": "strava",
  "command": "npx",
  "args": ["-y", "@keitaro_aigc/strava-mcp-server"],
  "env": {
    "STRAVA_CLIENT_ID": "your_client_id",
    "STRAVA_CLIENT_SECRET": "your_client_secret",
    "STRAVA_REFRESH_TOKEN": "your_refresh_token"
  }
}

設定を保存
Manus を再起動してツールを有効化

ステップ2-D: Dify での設定

Dify プラットフォームで使用する場合：

セルフホスト版の場合

Dify の docker-compose.yml に環境変数を追加：

services:
  api:
    environment:
      # 既存の環境変数...
      STRAVA_CLIENT_ID: "your_client_id"
      STRAVA_CLIENT_SECRET: "your_client_secret"
      STRAVA_REFRESH_TOKEN: "your_refresh_token"

MCP サーバーをカスタムツールとして登録：

{
  "tool_name": "strava_mcp",
  "command": "npx -y @keitaro_aigc/strava-mcp-server",
  "type": "mcp"
}

Docker コンテナを再起動：

docker-compose down
docker-compose up -d

クラウド版の場合

Dify のワークスペース設定を開く
「カスタムツール」セクションに移動
新しい MCP ツールを追加し、エンドポイント情報を設定

注意: クラウド版では MCP サーバーを別途ホスティングする必要がある場合があります。

ステップ2-E: ChatGPT（開発モード）での設定

ChatGPT の開発モード（Actions/Functions）で使用する場合：

前提条件

ChatGPT Plus または Enterprise アカウント
カスタム GPT の作成権限

設定手順

ChatGPT で「GPTs」→「Create a GPT」を選択
「Configure」タブで Actions を追加
MCP サーバーを API エンドポイントとしてホスティング（例：Vercel、AWS Lambda など）
OpenAPI スキーマを定義：

openapi: 3.0.0
info:
  title: Strava MCP Server
  version: 1.0.0
servers:
  - url: https://your-deployment-url.com
paths:
  /get_activities:
    post:
      summary: Get athlete activities
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                page:
                  type: integer
                per_page:
                  type: integer
      responses:
        '200':
          description: Success
  /get_activity:
    post:
      summary: Get specific activity
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                activity_id:
                  type: integer
              required:
                - activity_id
      responses:
        '200':
          description: Success

環境変数を Actions の設定で追加

注意: ChatGPT での使用には MCP サーバーの HTTP ラッパーが必要です。直接的な STDIO 接続はサポートされていません。

ステップ3: 動作確認

各クライアントで以下のように質問してみてください：

Claude Desktop / Cursor / Manus

最近のアクティビティを5件教えて

Dify

ワークフロー内で Strava MCP ツールを呼び出し、パラメータを指定して実行。

ChatGPT

カスタム GPT 内でアクションが利用可能になっていることを確認。

Stravaのデータが表示されれば、セットアップ完了です！🎉

トラブルシューティング

エラー: "Failed to refresh access token"

Client ID、Client Secret、Refresh Tokenが正しいか確認
Stravaアプリケーションのステータスが「Active」になっているか確認

ツールが表示されない

Claude Desktopを完全に再起動（メニューから終了して再度起動）
設定ファイルのJSON形式が正しいか確認（カンマの位置、閉じ括弧など）

"command not found" エラー

Node.js 18以上がインストールされているか確認：node -v
npmが正しくインストールされているか確認：npm -v

ローカル開発・ビルドからの使用

npm経由ではなく、ソースコードからビルドして使用する場合：

1. リポジトリのクローンとビルド

git clone https://github.com/groundcobra009/strava-mcp-server.git
cd strava-mcp-server
npm install
npm run build

2. Claude Desktop設定（ローカルビルド版）

macOS

{
  "mcpServers": {
    "strava": {
      "command": "node",
      "args": ["/Users/keitaro/🏀｜TRAE/20251028strava-mcp/dist/index.js"],
      "env": {
        "STRAVA_CLIENT_ID": "your_client_id",
        "STRAVA_CLIENT_SECRET": "your_client_secret",
        "STRAVA_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

Windows（ローカルビルド版）

{
  "mcpServers": {
    "strava": {
      "command": "node",
      "args": ["C:\\path\\to\\strava-mcp-server\\dist\\index.js"],
      "env": {
        "STRAVA_CLIENT_ID": "your_client_id",
        "STRAVA_CLIENT_SECRET": "your_client_secret",
        "STRAVA_REFRESH_TOKEN": "your_refresh_token"
      }
    }
  }
}

注意: C:\\path\\to\\strava-mcp-server\\の部分は実際のクローンしたディレクトリパスに置き換えてください。

3. 環境変数の設定（ローカル開発用）

ローカル開発では.envファイルを使用することもできます：

cp .env.example .env
# .envファイルを編集して認証情報を設定

npm公開手順（開発者向け）

このパッケージをnpmに公開するには以下の手順を実行します：

1. npmアカウントの作成とログイン

# npmアカウントがない場合は作成
npm adduser

# すでにアカウントがある場合はログイン
npm login

2. package.jsonの設定を確認

name: パッケージ名（スコープ付きの場合は @username/package-name）
version: バージョン番号（セマンティックバージョニング）
repository: GitHubリポジトリURL
author: 作者情報

3. ビルドとテスト

# ビルド
npm run build

# パッケージ内容を確認
npm pack --dry-run

4. npm公開

# スコープ付きパッケージの場合は公開アクセスを設定
npm publish --access public

# 通常のパッケージの場合
npm publish

5. バージョン更新（次回以降）

# パッチバージョンアップ（1.0.0 -> 1.0.1）
npm version patch

# マイナーバージョンアップ（1.0.0 -> 1.1.0）
npm version minor

# メジャーバージョンアップ（1.0.0 -> 2.0.0）
npm version major

# 再公開
npm publish --access public

注意事項

package.jsonのnameを自分のnpmユーザー名でスコープ化してください（例：@yourusername/strava-mcp-server）
repositoryのURLを実際のGitHubリポジトリURLに変更してください
一度公開したバージョンは削除できません（24時間以内のみ可能）
.npmignoreでソースコードや不要なファイルを除外済みです

使用例

基本的な使い方

Claude Desktopや他のMCP対応クライアントで、以下のような自然な会話でStravaデータにアクセスできます：

例1: 最近のアクティビティを確認

あなた: 「最近のランニング記録を10件見せて」

Claude: get_activitiesツールを使用して、最近のアクティビティ10件を取得します...
        
        1. 朝ラン - 5.2km, 26分15秒, 平均ペース 5:03/km
        2. 夜ラン - 10.5km, 52分30秒, 平均ペース 5:00/km
        ...

例2: 特定のアクティビティを詳しく分析

あなた: 「昨日のランニング（ID: 12345678）の詳細を教えて」

Claude: get_activityツールで詳細を取得します...
        
        アクティビティ: モーニングラン
        距離: 10.5km
        タイム: 52分30秒
        平均ペース: 5:00/km
        獲得標高: 85m
        平均心拍数: 152bpm
        最大心拍数: 172bpm

例3: 統計情報の確認

あなた: 「今月の走行距離の合計は？」

Claude: get_athlete_statsツールで統計情報を取得します...
        
        今年の累計:
        - 総距離: 245.8km
        - 総時間: 20時間35分
        - アクティビティ数: 28回
        
        最近4週間:
        - 総距離: 82.3km
        - 総時間: 6時間52分

例4: プロフィール情報の確認

あなた: 「私のStravaプロフィールを見せて」

Claude: get_athleteツールでプロフィール情報を取得します...
        
        名前: Taro Yamada
        所在地: Tokyo, Japan
        体重: 65kg
        登録日: 2020年1月15日

応用的な使い方

データ分析

あなた: 「先月と今月のランニング距離を比較して、改善点を教えて」

Claude: 統計データを取得して分析します...

トレーニング計画

あなた: 「最近のペースの傾向から、来週のトレーニングメニューを提案して」

Claude: アクティビティデータを分析してトレーニングプランを提案します...

モチベーション管理

あなた: 「今年の目標1000kmに対して、現在の進捗率と達成見込みは？」

Claude: 累計統計から進捗を計算します...

開発者向け情報

ローカル開発

開発モード（ウォッチモード）でコードを編集する場合：

# ウォッチモードで自動ビルド
npm run dev

# 別ターミナルでテスト実行
node dist/index.js

プロジェクト構造

.
├── src/
│   └── index.ts          # メインのMCPサーバー実装
├── dist/                  # TypeScriptビルド出力（自動生成）
├── package.json          # npmパッケージ設定
├── tsconfig.json         # TypeScript設定
├── .env.example          # 環境変数テンプレート
├── .gitignore           # Git除外ファイル
├── .npmignore           # npm公開除外ファイル
├── LICENSE              # MITライセンス
└── README.md            # ドキュメント

使用技術

TypeScript 5.3+: 型安全なコード
MCP SDK 0.5+: Model Context Protocolの公式 SDK
Axios: HTTPリクエストライブラリ
dotenv: 環境変数管理
Node.js 18+: 実行環境

貪献

プルリクエストやイシューの報告を歓迎します！

このリポジトリをFork
新しいブランチを作成 (git checkout -b feature/amazing-feature)
変更をコミット (git commit -m 'Add amazing feature')
ブランチをPush (git push origin feature/amazing-feature)
Pull Requestを作成

リンク

npmパッケージ: https://www.npmjs.com/package/@keitaro_aigc/strava-mcp-server
GitHubリポジトリ: https://github.com/groundcobra009/strava-mcp-server
Strava APIドキュメント: https://developers.strava.com/
MCP公式ドキュメント: https://modelcontextprotocol.io/

ライセンス

MIT

Available Tools

4 tools

get_activitiesB

アスリートのアクティビティ一覧を取得します。ページネーションに対応しています。

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	ページ番号（デフォルト: 1）
`per_page`	No	1ページあたりの件数（デフォルト: 30、最大: 200）

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It discloses pagination support but omits details such as sort order, filtering capabilities, return format, or any authentication/authorization requirements. This is minimal disclosure for a list endpoint.

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 that directly states the purpose and mentions the key feature (pagination). Every word earns its place, with no redundancy or filler.

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 two-parameter list tool with fully documented schema, the description provides adequate context. However, since there is no output schema, it does not explain the response structure (e.g., pagination metadata, fields returned), which would be helpful for an agent to parse results.

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 baseline is 3. The description's mention of pagination aligns with the page and per_page parameters, but adds no additional meaning beyond the schema descriptions, which already provide defaults and the maximum value.

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 retrieves a list of athlete activities ('アスリートのアクティビティ一覧を取得します'), which is a specific verb+resource. It is distinct from the sibling get_activity (singular vs. plural), though it does not explicitly contrast with it.

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 about when to use this tool versus alternatives. The description only mentions pagination, implying batch retrieval, but does not state when to choose this over get_activity or other sibling tools.

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

get_activityA

特定のアクティビティの詳細情報を取得します。

ParametersJSON Schema

Name	Required	Description	Default
`activity_id`	Yes	取得するアクティビティのID

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It indicates a read operation ('取得'), but does not disclose behaviors such as error responses, required permissions, or whether it returns full activity data like splits. The basic getter nature is conveyed, but additional transparency is missing.

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. Every word earns its place and it is appropriately sized for a simple getter tool.

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 has one parameter and no output schema, but the description provides minimal context—no mention of return structure, common error cases, or authorization. While adequate for a straightforward getter, it leaves gaps that could be filled to help the agent anticipate behavior.

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 has 100% coverage for activity_id, so the description adds no extra parameter semantics. Baseline 3 applies because the schema already documents the parameter adequately.

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 uses a specific verb ('取得します' = fetches) and identifies the resource ('特定のアクティビティの詳細情報' = detailed info for a specific activity), clearly distinguishing it from sibling tools like get_activities (plural list) and get_athlete (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 Guidelines3/5

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

The description implies usage for fetching a single activity's details, contrasting with get_activities which presumably lists activities, but it does not explicitly state when to use this tool vs alternatives or any exclusions.

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

get_athleteA

認証されたアスリートのプロフィール情報を取得します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/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 of behavioral disclosure. It only says 'retrieves' profile information, which implies a read operation, but lacks any detail about authentication requirements (beyond the word 'authenticated'), error cases, rate limits, or response format. This is minimal coverage for a tool that has no other structured metadata.

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, focused sentence with no filler words. It conveys the essential purpose efficiently and is appropriately sized for a simple resource-retrieval tool.

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 tool's simplicity (no parameters, no output schema, no annotations), the description is the only source of context. It covers the core purpose but is vague about what 'profile information' includes, how authentication is handled, and what to expect in the response. This leaves a moderate gap for an agent deciding whether to invoke the tool or interpret its result.

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 schema is empty, so there are no parameter semantics to explain. According to the rubric, a baseline of 4 is appropriate when there are no parameters. The description adds no parameter-related information, but none 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 verb '取得します' (retrieve) and the resource '認証されたアスリートのプロフィール情報' (profile information of the authenticated athlete). It unambiguously distinguishes the tool from its siblings (get_activities, get_activity, get_athlete_stats) by focusing specifically on the athlete's profile.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. However, the usage is implied by the tool name and description: when you need the authenticated athlete's profile, this is the tool. No alternatives are mentioned, so it stops at implied usage.

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

get_athlete_statsB

アスリートの統計情報（総距離、総時間など）を取得します。

ParametersJSON Schema

Name	Required	Description	Default
`athlete_id`	Yes	アスリートのID

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden for behavioral disclosure. It states the tool retrieves statistics but does not explicitly disclose it is a read-only operation, nor does it mention side effects, required permissions, or return format. The 'get' verb implies reading, but this is not stated.

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 is front-loaded with the action and resource, and it includes illustrative examples. Every word earns its place.

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 tool with one required parameter and no output schema, the description provides enough context by giving example outputs (total distance, total time) and using 'など' to indicate additional stats. It does not fully enumerate all possible statistics, but it is adequate for a straightforward retrieval tool.

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 single parameter athlete_id described as 'アスリートのID'. The description does not add much beyond the schema, but because the schema already fully documents the parameter, the 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 uses the specific verb '取得' (get) with the resource 'athlete stats', and provides concrete examples like total distance and total time. It clearly distinguishes from sibling tools such as get_athlete (profile) and get_activity (individual 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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like get_athlete or get_activities, nor does it state any prerequisites or exclusions.

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.

4 tool updatesv1.0.2Aug 10, 2026
- First observedget_activities
- First observedget_activity
- First observedget_athlete
- First observedget_athlete_stats

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

The four tools are clearly distinct: one lists activities, one gets activity details, one gets athlete profile, and one gets athlete stats. No overlap or confusion between them.

Naming Consistency5/5

All tool names follow a consistent get_noun pattern using snake_case. The naming is predictable and uniform across the entire set.

Tool Count4/5

With 4 tools, the count is well-scoped for a read-only Strava integration. It covers the core data retrieval endpoints without unnecessary bloat.

Completeness4/5

The set covers primary needs: listing activities, retrieving activity details, and getting athlete profile and stats. However, it lacks advanced read endpoints like activity streams or club/route data, which are minor gaps for a comprehensive Strava API surface.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

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
freddyOAuth
coach.freddy
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Health & Wellness Fitness Tracking
2
StreamScannerOAuth
net.streamscanner
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
Entertainment & Media Social Media
2
HAPI Strava MCP Server A
ai.com.mcp
Strava MCP tools for AI: athletes, activities, segments, clubs, routes. Powered by HAPI MCP server.
Fitness Tracking Sports Health & Wellness
1337

Related MCP Servers

Strava MCP Server
Fitness Tracking Health & Wellness Sports
gcoombe
A
license
B
quality
D
maintenance
Enables interaction with Strava's API to access and manage activities, athlete data, routes, segments, clubs, and gear through natural language.
Updated 8 months ago (2026-01-14 23:15 UTC)
22
25
MIT
Strava MCP Server
Fitness Tracking Health & Wellness
juanlarreapm
A
license
B
quality
D
maintenance
Integrates with the Strava API to allow AI assistants to access fitness data including athlete profiles, activity history, and segment statistics. It enables users to query detailed performance metrics and explore geographic segment data through natural language commands.
Updated 7 months ago (2026-01-25 00:32 UTC)
8
61
MIT
Strava MCP Server
Fitness Tracking Health & Wellness Search
LimeON-source
A
license
B
quality
D
maintenance
Enables users to interact with their Strava data through natural language to analyze workouts, track fitness progress, and explore routes. It supports retrieving detailed activity stats, heart rate data, and segment insights directly within AI assistants.
Updated 6 months ago (2026-03-21 04:51 UTC)
26
445
MIT
Strava Coach MCP Server
Fitness Tracking Weather Services Location Services
colinfrisch
A
license
Not graded
quality
D
maintenance
Enables AI assistants to access Strava running data, route planning, and weather information for intelligent running coaching.
Updated a year ago (2025-09-24 21:56 UTC)
15
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/groundcobra009/strava-mcp-server'

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

Strava MCP Server

📦 対応クライアント

インストール

npmからインストール

ソースからビルド

主な機能

1. get_activities - アクティビティ一覧の取得

2. get_activity - 特定アクティビティの詳細取得

3. get_athlete - アスリートプロフィールの取得

4. get_athlete_stats - 統計情報の取得

セットアップ

前提条件

ステップ1: Strava APIの認証情報を取得

1.1 Stravaアプリケーションの作成

1.2 Client IDとClient Secretの確認

1.3 Refresh Tokenの取得

ステップ2: Claude Desktopでの設定

macOS

Windows

ステップ2-B: Cursor での設定

設定ファイルの場所

設定手順

ステップ2-C: Manus での設定

設定手順

ステップ2-D: Dify での設定

セルフホスト版の場合

クラウド版の場合

ステップ2-E: ChatGPT（開発モード）での設定

前提条件

設定手順

ステップ3: 動作確認

Claude Desktop / Cursor / Manus

Dify

ChatGPT

トラブルシューティング

エラー: "Failed to refresh access token"

ツールが表示されない

"command not found" エラー

ローカル開発・ビルドからの使用

1. リポジトリのクローンとビルド

2. Claude Desktop設定（ローカルビルド版）

macOS

Windows（ローカルビルド版）

3. 環境変数の設定（ローカル開発用）

npm公開手順（開発者向け）

1. npmアカウントの作成とログイン

2. package.jsonの設定を確認

3. ビルドとテスト

4. npm公開

5. バージョン更新（次回以降）

注意事項

使用例

基本的な使い方

例1: 最近のアクティビティを確認

例2: 特定のアクティビティを詳しく分析

例3: 統計情報の確認

例4: プロフィール情報の確認

応用的な使い方

データ分析

トレーニング計画

モチベーション管理

開発者向け情報

ローカル開発

プロジェクト構造

使用技術

貪献

リンク

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `get_activities` - アクティビティ一覧の取得

2. `get_activity` - 特定アクティビティの詳細取得

3. `get_athlete` - アスリートプロフィールの取得

4. `get_athlete_stats` - 統計情報の取得