fitness-mcp

A small, self-hosted fitness tracker exposed as a remote Model Context Protocol (MCP) server on Cloudflare Workers.

It is designed for conversational logging from MCP-capable AI clients: workouts, sets, weigh-ins, meals, goals, plans, and progress photos are parsed by the model and stored as structured data.

Architecture

ChatGPT / Claude / other MCP client
              |
              v
       Cloudflare Worker
              |
       +------+------+
       |             |
       v             v
      D1             R2
 structured data   photos

The example configuration contains two generic users. Each user gets a separate D1 database with the same schema. Authentication selects the database binding before application code handles the request, so even the raw read-only SQL tool cannot cross user boundaries.

Photos live in one R2 bucket under user-specific prefixes. Photo links returned to clients are short-lived HMAC-signed URLs rather than account credentials.

Related MCP server: fitness-agent-mcp

What it can do

• Log resistance-training sets from natural language.

• Record reps, timed holds, and distance-based work.

• Record workout metadata when set-level numbers are unavailable.

• Upsert weigh-ins.

• Log meals and macros.

• Store goals and training plans.

• Upload, list, and retrieve progress photos.

• Query the authenticated user's D1 database through a guarded read-only SQL tool.

• Export data as JSON or CSV.

The server intentionally keeps analytics light. The MCP client can reason over the structured rows; aggregate tools can be added later if histories become too large for efficient context use.

Stack

• Cloudflare Workers

• Cloudflare D1

• Cloudflare R2

• Cloudflare KV for OAuth provider state

• @modelcontextprotocol/sdk

• @cloudflare/workers-oauth-provider

• TypeScript

• Vitest / Miniflare

Public example

This repository is a sanitized reference implementation. It uses generic users, placeholder Cloudflare resource IDs, example email addresses, an example Workers hostname, and test-only credentials. It contains no production credentials or production deployment identifiers.

Setup

npm install
npx wrangler login
npx wrangler d1 create fitness-user1
npx wrangler d1 create fitness-user2
npx wrangler r2 bucket create fitness-pics
npx wrangler kv namespace create OAUTH_KV

Put the generated D1 database IDs and KV namespace ID into wrangler.toml.

Set Worker secrets:

npx wrangler secret put TOKENS_JSON
npx wrangler secret put SIGNING_SECRET
npx wrangler secret put GOOGLE_CLIENT_ID
npx wrangler secret put GOOGLE_CLIENT_SECRET
npx wrangler secret put COOKIE_ENCRYPTION_KEY
npx wrangler secret put USER_EMAILS_JSON

Example email allowlist:

{
  "user1@example.com": "user1",
  "user2@example.com": "user2"
}

Then:

npm run migrate -- --remote
npm run typecheck
npm test
npm run deploy

Register the deployed /mcp endpoint in an MCP-capable client and complete the OAuth flow.

Why one database per user?

D1/SQLite does not provide row-level security. Because this server exposes a raw read-only SQL escape hatch, putting each user in a different D1 database makes the account boundary structural rather than relying on SQL rewriting or a forgotten WHERE user_id = ... filter.

The cost is operational: adding a user means adding another D1 binding and running the same migrations against it.

Development

cp .dev.vars.example .dev.vars
npm run migrate
npm run dev
npm test
npm run typecheck

Never commit .dev.vars, real tokens, OAuth secrets, database exports, or signing keys.

License

ISC