# STAS Running Coach for Claude (remote · stas.run)

Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.

- Trust score: 82/100 (high trust)
- Change this week: +9
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `stas.run`: 82/100 (this document), [markdown](https://verifymcp.io/servers/run-stas-stas/api-mcp.md), [page](https://verifymcp.io/servers/run-stas-stas/api-mcp)

## Channel facts

- Endpoint: `https://stas.run/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 97/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 75/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 4522 tokens (~161/item across 28 items; 20 tools + 8 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 95/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 85% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http run-stas-stas https://stas.run/api/mcp
```

### Codex

```toml
[mcp_servers.run-stas-stas]
url = "https://stas.run/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "run-stas-stas": {
      "type": "remote",
      "url": "https://stas.run/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add run-stas-stas --url https://stas.run/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  run-stas-stas:
    url: "https://stas.run/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "run-stas-stas": {
      "type": "http",
      "url": "https://stas.run/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 81, +6)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 75, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 73, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 72)

First indexed and scored.

## MCP tools (20)

### `get_user_summary` (~57 tokens)

Start here for most conversations. Load the athlete's profile, goals, rules, recent load, current fitness context, performance evidence, optional bounded historical signals, planning guidance, and persistent STAS memory opportunities.

Input parameters:

- `section` (string)

### `get_trainings` (~227 tokens)

Load one bounded, size-safe list of completed workouts. Default mode is a rich index for chronology, load, reports, compact summaries, and choosing training_id. Set full=true only for analysis-rich comparison across multiple workouts; it adds a bounded compact interval projection. For one selected workout, use get_activity_detail instead of full=true.

Input parameters:

- `full` (boolean): Optional analysis-rich list mode for comparing multiple completed workouts in a bounded date window. It adds a size-safe compact interval projection, but is not raw data and is not the detailed view…
- `limit` (integer): Max trainings per page. Server cap is 50.
- `newest` (string): End boundary date in YYYY-MM-DD, exclusive. To load one date, set newest to the next calendar date, for example oldest=2026-06-21 and newest=2026-06-22.
- `oldest` (string): Start boundary date in YYYY-MM-DD, inclusive.

### `get_activity_detail` (~100 tokens)

Load a compact read-only passport for one completed workout after identifying its training_id with get_trainings. Use for detailed one completed workout questions about intervals, laps, splits, terrain, weather, efforts, segments, and data quality. The response omits source payloads, route coordinates, latlng, and raw stream arrays.

Input parameters:

- `training_id` (string, required): Training id returned by get_trainings. Load get_trainings first to identify the exact workout.

### `get_planned_events` (~49 tokens)

Read planned events from the Intervals calendar in a date window. Use this before rewriting or replacing an existing STAS plan.

Input parameters:

- `newest` (string, required)
- `oldest` (string, required)

### `whoami` (~25 tokens)

Check which STAS user is currently authenticated. Use only for diagnostics or reconnect troubleshooting.

### `get_editable_goals_results` (~56 tokens)

Read the complete bounded editing state for general goals, calendar-linked starts, race results, standalone results, and legacy results. Stable public IDs and dataVersion are required for every later preview. This tool does not change anything.

### `get_goal_activity_candidates` (~70 tokens)

Read safe nearby activity candidates for one exact start. Use the returned opaque selectionId when previewing result_link_activity. This tool does not change the start, activity, or result.

Input parameters:

- `goalPublicId` (string, required): Stable public ID of one event goal returned by get_editable_goals_results.

### `preview_goal_result_change` (~130 tokens)

Preview one exact change to a general goal, calendar-linked start, activity pairing, race result, standalone result, or legacy result. Always load get_editable_goals_results first and send its exact dataVersion. This never saves. Show the user the exact preview, including calendar/activity effects, and ask for explicit confirmation before commit_goal_result_change.

Input parameters:

- `command` (required): One exact goal, start, activity-link, or result change. Broad replace-all writes are not supported.
- `expectedDataVersion` (string, required): Exact dataVersion returned by get_editable_goals_results. A stale version is rejected.

### `commit_goal_result_change` (~80 tokens)

Commit one previewed goal, start, activity-link, or result change. Call only after the user explicitly confirms the exact preview from preview_goal_result_change. The server rejects stale data and returns the new authoritative editing state.

Input parameters:

- `changeId` (integer, required): Preview id returned by preview_goal_result_change. Commit only after the user confirms that exact preview.

### `create_plan_event` (~1162 tokens)

Create or update planned WORKOUT events in Intervals. For changes to an existing STAS workout, keep the same external_id and call this tool again; do not delete the day/window just to edit time, name, note, load, color, or workout_builder. This tool is self-contained; do not look for SKILL.md or examples in the athlete's calendar. dry_run is required: false writes the event, true previews only. Send activity_type as Run/Ride/Swim/Workout/WeightTraining/Yoga/Pilates/Stretching/Walk/Hike/Elliptical/NordicSki/HighIntensityIntervalTraining/Other, stas_note for the human workout note, and external_id=plan:YYYY-MM-DD:<slug>. Do not send low-level Intervals fields category, type, sport, workoutType, target, description, workout_doc, icu_workout, filename, or file_contents. The server maps activity_type to Intervals type and category=WORKOUT and infers Intervals target=HR/PACE/POWER from Run/Ride workout_builder only. Use local datetimes without a timezone suffix, e.g. 2026-05-13T08:00:00, not 2026-05-13T08:00:00+03:00. workout_builder is mandatory for any interval/key workout save, mainly Run/Ride intervals; never save intervals as prose-only. Omit workout_builder only for easy/simple workouts without structured steps. If validation fails, inspect error.data.issues[].path, fix that exact event field, and retry only after changing the invalid field. If you use workout_builder, do not include ## STAS or ## Workout; the server adds wrappers. Builder headers and repeat headers are plain lines without '-', e.g. 'Warmup', 'Main Set 5x', 'Cooldown'. Actual step lines start flush-left with '- ' and contain duration/distance plus a target, e.g. '- 1km 4:25/km-4:35/km Pace', '- 10m 75%', or '- Recovery 90s Z1 HR'. For swim workouts, distance-led steps such as '- 400m easy' and '- 6 x 50m build' are allowed. For HR-only workouts, every structured step target should use HR syntax like '- 10m Z2 HR' or '- 3m Z4 HR'. Do not write '- Warmup' followed by indented child bullets. Use '1km'…

Input parameters:

- `dry_run` (boolean, required): Required. false writes to Intervals.icu; true only previews without writing.
- `events` (array, required): Example real interval write arguments. Replace the date/time and paces, but keep this exact JSON shape. Use activity_type, stas_note, and mandatory workout_builder for interval/key workout saves. wor…

### `create_note_event` (~159 tokens)

Create or update NOTE events in Intervals. dry_run is required: false writes the note, true previews only. Send category=NOTE and external_id=note:YYYY-MM-DD:<slug>. Use all-day local times for normal notes, keep description short, and omit type, moving_time, icu_training_load, and workout_doc. For weekly review notes or other notes that apply to the whole week, send for_week=true; omit it or use false for ordinary notes. Do not create a seven-day date range for weekly notes; keep one all-day anchor date and use for_week=true.

Input parameters:

- `dry_run` (boolean, required): Required. false writes to Intervals.icu; true only previews without writing.
- `events` (array, required)

### `delete_plan_events` (~221 tokens)

Delete STAS plan events. For one specific workout, pass external_ids with the exact plan:YYYY-MM-DD:<slug> id; external_id as one string is accepted as a compatibility alias. Use oldest/newest window deletion only when the user is replacing the whole STAS plan in that date window. Do not use window deletion for simple edits; update with create_plan_event using the same external_id instead. dry_run is required: false deletes, true previews only.

Input parameters:

- `dry_run` (boolean, required): Required. false writes to Intervals.icu; true only previews without writing.
- `external_id`: Compatibility alias for deleting one exact STAS event id. Prefer external_ids for multiple ids.
- `external_ids` (array): Exact STAS event ids to delete. Use this for deleting specific workouts or notes without clearing the whole day/window.
- `newest` (string): End date for full-window replacement deletes. Required unless external_ids is provided.
- `oldest` (string): Start date for full-window replacement deletes. Required unless external_ids is provided.

### `delete_note_events` (~209 tokens)

Delete STAS note events. For one specific note, pass external_ids with the exact note:YYYY-MM-DD:<slug> id; external_id as one string is accepted as a compatibility alias. Use oldest/newest window deletion only when replacing a whole note set in that date window. Do not delete user-created notes without a note: external_id. dry_run is required: false deletes, true previews only.

Input parameters:

- `dry_run` (boolean, required): Required. false writes to Intervals.icu; true only previews without writing.
- `external_id`: Compatibility alias for deleting one exact STAS event id. Prefer external_ids for multiple ids.
- `external_ids` (array): Exact STAS event ids to delete. Use this for deleting specific workouts or notes without clearing the whole day/window.
- `newest` (string): End date for full-window replacement deletes. Required unless external_ids is provided.
- `oldest` (string): Start date for full-window replacement deletes. Required unless external_ids is provided.

### `save_strategy` (~809 tokens)

Save the athlete's long-term STAS strategy only after explicit user confirmation. Strategy is a compact long-term roadmap, not a calendar, not a weekly plan, and not a full coaching analysis. Target length is about 2500-4500 characters; hard maximum is 5000 characters. Required markdown sections: Goal chain, Current point, Weekly decision contract, Roadmap, Resources / risks, Review triggers / unknowns. Build the strategy from current goals, rules, profile, condition, training history, evidence, and calendar first; do not copy or paraphrase the previous saved strategy's wording, race labels, priorities, phase names, or workout examples unless current facts independently support them. For strategy-level work, use at least 8 weeks of weekly/load history when available and 12-26 weeks for season direction; combine it with exact bounded-list windows and selected detailed workout passports instead of using only 2-4 weeks. Treat every dated goal as a real planning input by default. Do not infer a single main goal from distance, later date, target result, profile order, or old strategy wording; use priority only when it is explicit in the current profile, goal comment, athlete message, or current coaching decision. B/C/training-race/no-full-taper wording changes peak depth and risk; it does not mean the race should be ignored unless the athlete explicitly says the result does not matter. The roadmap must be the main content and say what each block prepares directly, keeps ready in the background, and leaves out for now with a reason. Do not hide a block-driving goal behind vague background wording. Keep Weekly decision contract short; it is guardrails for the blocks, not the center of the strategy. Do not write day-by-day or 8-week calendar progression inside strategy; that belongs in block planning or calendar tools. Use for meaningful changes to goals, constraints, current position, roadmap, or long-term training logic, not for one-off weekly edits. Before calling this…

Input parameters:

- `strategy_md` (string, required): Compact long-term STAS roadmap markdown, not a calendar, not a weekly plan, and not a full coaching analysis. Target length is about 2500-4500 characters; hard maximum is 5000 characters. Required se…

### `read_profile_sections` (~48 tokens)

Read controlled rules and profile memory with their hashes. Goals and results are available only through get_editable_goals_results. Use the returned hash as previousHash before previewing a rules/profile change.

### `preview_profile_section_change` (~191 tokens)

Create a controlled preview for rules or profile memory. Goals, starts, activities, and results must use preview_goal_result_change so stable IDs and calendar links are preserved. This does not update the athlete profile. Before commit, show the user the exact full text from the preview and ask for explicit confirmation of that exact text.

Input parameters:

- `diffSummary` (string): Short internal summary of the factual change. Do not include raw chat transcript.
- `newText` (string): Legacy fallback full section text for rules or profile only.
- `previousHash` (string, required): Hash returned by read_profile_sections for the same section. Used to prevent overwriting newer profile data.
- `section` (string, required): Profile memory section to update. Supports rules and profile when enabled by the server. Goals and results use preview_goal_result_change.
- `structured` (object): Preferred input. For rules/profile, send only the matching object.

### `commit_profile_section_change` (~98 tokens)

Commit a previously previewed rules or profile memory change. Call this only after the user explicitly confirms the exact full text shown for that preview. If preview returned noChange=true, do not call commit. The server updates the profile only if the section hash still matches the preview.

Input parameters:

- `changeId` (integer, required): Preview change id returned by preview_profile_section_change. Call only after the user explicitly confirms the exact full text shown for this preview.

### `read_profile_change_history` (~96 tokens)

Read a compact paginated index of goals, rules, or profile memory changes. Text bodies and hashes are omitted. Use nextCursor for another page and read_profile_change_detail for one exact record.

Input parameters:

- `cursor` (integer): nextCursor from the previous history page.
- `limit` (integer): Compact records per page. Default 10, maximum 20.
- `section` (string)
- `status` (string)

### `read_profile_change_detail` (~62 tokens)

Load the exact full text and hashes for one profile-memory record selected from read_profile_change_history. This is read-only and should be used only for details or before considering a restore.

Input parameters:

- `changeId` (integer, required): Change id returned by read_profile_change_history.

### `restore_profile_change` (~114 tokens)

Restore a committed profile, goals, or rules profile memory change back to its previous text. First load the exact record with read_profile_change_detail. For goals, restoring old-format labels is blocked; rebuild a canonical goals preview instead. Call this only after the user explicitly confirms the exact full text that will be restored.

Input parameters:

- `changeId` (integer, required): Committed change id to restore. Call only after the user explicitly confirms the exact full text that will be restored. Restore only succeeds when the current section still matches that change.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/run-stas-stas/api-mcp#diagnostics

## Score history

- 2026-08-03: 82
- 2026-08-02: 82
- 2026-08-01: 81
- 2026-07-31: 81
- 2026-07-30: 75
- 2026-07-29: 75
- 2026-07-28: 74
- 2026-07-27: 73
- 2026-07-26: 72

## Links

- Remote endpoint: https://stas.run/api/mcp
- Repository: https://github.com/hivrich/stas.run
- Website: https://stas.run/
- Changelog RSS feed: https://verifymcp.io/servers/run-stas-stas/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/run-stas-stas/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/run-stas-stas/api-mcp