matrix-workouts-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MATRIX_PIN | No | Numeric passcode. Used for one sign-in request, never stored or logged. | |
| MATRIX_XID | No | Member number from the gym tag. Without it the server is read-only over the cache. | |
| MCP_TRANSPORT | No | Set to 'http' to serve over HTTP instead of stdio. | stdio |
| MATRIX_CACHE_DIR | No | Where the downloaded history is kept, written 0600. | ~/.cache/matrix-workouts-mcp |
| MATRIX_HTTP_HOST | No | HTTP transport only. Loopback on purpose — see Privacy. | 127.0.0.1 |
| MATRIX_HTTP_PORT | No | HTTP transport only. | 3000 |
| MATRIX_MCP_TOKEN | No | Bearer token. Required for the HTTP transport; the server refuses to start without it. | |
| MATRIX_CACHE_TTL_MINUTES | No | How long a cached history is served before a refetch. | 60 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workoutsA | List recorded rides, newest first, one compact row each: date, program mode, duration, distance, average power and heart rate. Use this first to find the id of a ride before asking for its detail. Returns no sample series. |
| get_workoutA | Everything derived about one ride: duration, distance, work done, average and peak power, cadence, resistance, both heart-rate averages, and what the console was actually holding constant. Does not return the sample series — use get_samples for that. |
| get_samplesA | The raw interval series for one ride as CSV — power, cadence, resistance, heart rate, speed, one row per 10 seconds. Ask for a window and a stride rather than a whole ride: a full ride is several hundred rows. |
| summarize_historyA | Training volume per week or month — rides, time, distance, work, average power and heart rate — plus the all-time power curve over the matched rides. This is the tool for questions about trends, totals and bests. |
| compare_workoutsB | Two or more rides side by side on every derived number. Use it for 'how did today compare to last Tuesday' rather than calling get_workout repeatedly. |
| export_workoutA | Write one ride to disk as a lossless JSON export document — normalized telemetry plus the upstream record verbatim. Returns the path, not the contents, because the document is far too large to read into a conversation. |
| refresh_historyA | Re-download the whole history from the API, replacing the cache. Needs credentials. Everything else answers from the cache, so call this only when a ride is missing because it happened since the last fetch. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct operation—listing, single-ride detail, raw samples, aggregates, comparison, export, and cache refresh—and the descriptions explicitly cross-reference the intended usage. No two tools overlap in function, and boundary cases like get_workout vs get_samples are clearly called out.
All seven tools follow a consistent verb_noun snake_case pattern (list_, get_, summarize_, compare_, export_, refresh_). Singular and plural noun usage is logical and predictable, making tool selection straightforward.
Seven tools is well-scoped for a workout-history MCP: the core read, analyze, and export paths are covered without redundancy. Each tool earns its place, and there is no sense of bloat or thinness.
The surface covers listing, detail, raw samples, aggregation, comparison, export, and cache refresh, so a user can go from finding a ride to analyzing or exporting it without dead ends. Create/update/delete are not needed because the server reads externally recorded rides and refresh_history handles new data.