Rhythm

Inspiration

Training data is often split between a notebook, app screens, exported files, and AI chats. That makes it difficult for an assistant to understand what was planned, what actually happened, and what should change next. I built Rhythm to keep that history reliable and to let people work with an AI without handing it unrestricted database access or allowing it to silently rewrite a training program.

What it does

Rhythm is a multi-user, mobile-first, offline-first PWA for strength training and swimming. It guides a workout, records weight, repetitions, RIR, substitutions, discomfort, wellbeing, and session feedback, and keeps planned work, completed facts, and future suggestions as separate data. It also provides history, charts, e1RM and progression signals, body measurements, schedules, and portable JSON, Markdown, and ZIP exports.

On the authenticated Assistant page, Rhythm exposes a focused catalog of 17 WebMCP tools: 12 read tools for profile context, programs, templates, workouts, exercise history, progress, schedules, search, and alternatives; plus 5 write tools for program drafts, workout rescheduling, exercise replacement, and plan activation.

Why WebMCP is a strong fit

Before WebMCP, the reliable workflow required six manual steps: export a report, download it, open an AI chat, upload the file, download a new plan, and import it back into the diary. With WebMCP, the assistant can request only the current context it needs, discuss the evidence with the athlete, prepare a draft, and perform a narrowly scoped action in one connected conversation.

The user remains in control. A new program is always created as an immutable draft first. Activating it displays an impact preview inside Rhythm and waits for explicit human confirmation. If WebMCP is unavailable, the ordinary PWA and the JSON/Markdown workflow continue to work normally.

How I built it

The application uses PHP 8.2+, MySQL or MariaDB, server-rendered HTML, vanilla JavaScript, Fetch API, a Service Worker, Cache API, and IndexedDB. WebMCP is implemented with document.modelContext.registerTool on the authenticated /assistant page. Each tool is a thin adapter over a same-origin semantic endpoint and existing application services.

The server session determines the current user; tool inputs never accept a user_id. Read responses are bounded and paginated. Writes use CSRF and Origin checks, Fetch Metadata policy, optimistic locking, idempotency keys, rate limits, audit trails, and tenant-scoped repository queries. Feature flags and a per-user canary allowlist support controlled rollout. Database text is treated as untrusted content rather than instructions.

What I added during the challenge

Rhythm existed before the submission period as an offline-first training diary. From August 26 through September 3, I added the complete WebMCP layer: authenticated read APIs, the page-scoped registry, 12 read tools, 5 write tools, immutable program drafts, human-confirmed activation, safe workout-instance changes, security hardening, prompt-injection fixtures, A–J end-to-end coverage, MySQL validation, paginated template reads, rollout controls, a public product guide, and full English localization. The dated Git history separates this work from the earlier PWA.

Challenges

The hardest part was designing tools that were useful to an agent but still narrow enough to protect historical training data. A generic database or endpoint tool would have been simpler, but unsafe. Another challenge was combining online agent actions with an offline-first workout flow without placing WebMCP writes into the offline queue. Activation also needed to be conversational while still ending with a real in-app human decision.

What I learned

I learned how to translate product capabilities into small semantic tools, how to treat tool annotations as hints rather than a security boundary, and how to combine agent workflows with immutable history, confirmation, idempotency, auditability, and graceful fallback. The result is not only an AI demo: it is a complete training product in which people and agents can collaborate without giving up control of the data or the final decision.

What's next

Next I want to refine onboarding for judges and new athletes, expand deterministic progress explanations, and continue compatibility testing across WebMCP clients while keeping the open JSON and Markdown workflow as a portable foundation.

Built With

• css
• fetch-api
• html5
• indexeddb
• javascript
• mysql
• php
• pwa
• service-worker
• webmcp