MCP (Model Context Protocol) is the standard that lets an agent client discover and call external tools. StrideMoor runs an official MCP endpoint: once your client is connected you can simply ask "how did I sleep last night?" or "did I run more than last week?", and the client turns that into calls against your StrideMoor data.
It shares the same auth and scopes as the REST API — same key, same data, same rate limits. Only the calling convention differs: with REST you write the requests yourself, with MCP the client discovers the available tools for you.
Typical use: connect StrideMoor to the assistant client you already use and have it read your sleep and recovery every morning to draft that day's training advice.
Point your MCP client's remote / HTTP server URL at:
https://api.8keya.com/mcp
The MCP client sends the key in a request header (there is no separate login flow):
X-API-Key: sk_sm_...xxxx
Any MCP client that supports custom request headers can connect. With OpenClaw, for example (verified working):
openclaw mcp add stridemoor \
--url https://api.8keya.com/mcp \
--transport streamable-http \
--header X-API-Key=sk_sm_...xxxx
Command-line clients such as Claude Code support custom request headers too — see their own help for the exact flags.
X-API-Key cannot be sent. They need OAuth, which StrideMoor does not offer yet.The client lists the available tools automatically. The read-only tools below (11 of them) are all available as soon as the key is valid:
| Tool | Description |
|---|---|
| get_capabilities | What this key can do: scopes, rate limits, available endpoints |
| get_overview | Today at a glance: steps, distance, calories, last run, recovery |
| get_today | All body metrics for a given day (steps, sleep, VO2max …), with units |
| get_weekly_report | This week vs last week: distance, duration, count, pace |
| get_recent_runs | Summaries of your most recent runs |
| get_health_summary | Health aggregates over the last N days: steps / distance / calories / sleep / VO2max / ECG count. Summaries only, no raw time series, and no heart rate / SpO2 / temperature (those raw points come from the REST /health/data-points endpoint) |
| list_runs | Paginated list of your runs |
| get_run_detail | One run in detail by ID (pace, heart rate, cadence …) |
| list_bookmarks | Your bookmarked runs |
| list_routes | Paginated list of routes |
| list_favorite_routes | Your favourite routes |
The 8 tools below only appear when the key carries the matching write scope — so the capabilities the model sees match what the key can really do, and it will not call a tool that is bound to be rejected. Write scopes are not granted by default; tick "Also grant write access" in the app under Agent Access. Writes only ever affect your own data (bookmarks, follows) and cannot create, modify or delete your runs, health data, points or account settings.
| Tool | Required scope | Description |
|---|---|---|
| bookmark_run | write:bookmarks | Bookmark a run |
| unbookmark_run | write:bookmarks | Remove a run bookmark |
| favorite_run | write:favorites | Add a run to favourites |
| unfavorite_run | write:favorites | Remove a run from favourites |
| favorite_route | write:favorites | Favourite a route |
| unfavorite_route | write:favorites | Unfavourite a route |
| follow_user | write:follow | Follow a user (you cannot follow yourself) |
| unfollow_user | write:follow | Unfollow a user |
Same as the REST API: by default 60 requests per minute and 5000 per day per key. Exceeding it returns 429.
Only the read-only tools show up — did my write scopes not take effect?
They did. The remote endpoint is stateless: on the first request it has not yet read your key's scopes, so it registers the read-only tools first (the write tools are added about 2-3 seconds later, and the client is notified to refresh its list). Reconnect a few seconds later, or refresh the tool list, and all tools appear. Whether write tools show up depends only on whether the key carries the matching write scope.
My own client (Python etc.) gets a 403?
Cloudflare sits in front of our endpoint and blocks the default Python client signature (HTTP 403, Error 1010). Send a normal User-Agent header (e.g. curl/8.0 or your own client name) and it works. Clients built on the official MCP SDKs are unaffected.
The client fails to connect or times out during initialisation?
Raise the connect / initialise timeout to 30 seconds or more: traffic goes through Cloudflare and carries a fixed 1-2 second added latency per request, so a default 5 second timeout can be too tight.
StrideMoor