DEV Community

hao li
hao li

Posted on Originally published at github.com

I gave Alexa a memory for my workouts — a stdlib-only MCP server with OAuth 2.1

I track every gym session, but logging sets means fumbling with my phone between exercises. I wanted to just talk: "log bench press, 185 for 5, three sets" — and have it remembered, with PRs tracked and protein targets answered.

So I built FitLog: a self-hosted MCP server that turns Alexa into a fitness coach. Six tools — log_workout, get_history, get_personal_records, plan_workout, log_protein, get_nutrition_targets — over Streamable HTTP, implementing MCP spec 2025-11-25.

The interesting part isn't the tools. It's the auth checklist, because Alexa+ is picky:

  • OAuth 2.1 + PKCE account linking, real authorization-code flow
  • 401s with no WWW-Authenticate header (Alexa+ treats its presence as a different auth scheme)
  • RFC 9728 Protected Resource Metadata at /.well-known/oauth-protected-resource
  • Scoped tokens (fitlog.read / fitlog.write), SQLite-persisted codes and tokens
  • Rate-limited owner login, fail-closed when no password is configured

And the whole thing is zero dependencies — Python standard library only. No framework, no ORM. The OAuth flow, the JSON-RPC dispatcher, the persistence layer: all hand-rolled, ~testable, and every security decision covered by tests (49/49 passing), including the fail-closed behavior I verified with an actual attack script.

git clone https://github.com/hahahahahahahahah6/fitlog-mcp.git
cd fitlog-mcp
python3 server.py
Enter fullscreen mode Exit fullscreen mode

Built for the Alexa+ track of Amazon's "Build, Ship, Shape" hackathon. MIT licensed.

Repo: https://github.com/hahahahahahahahah6/fitlog-mcp

If you're building MCP servers for Alexa+, happy to compare notes on the auth checklist — that part took longer than the tools.

Top comments (0)