Using a local iPhone MCP server to plan Apple Watch workouts with Codex

A developer created Ask My Health, a local MCP server that lets AI agents like Codex read Apple Health data and schedule Apple Watch workouts via an iPhone bridge. The tool exposes HealthKit and WorkoutKit tools over the local network, requiring bearer token authentication and user approval for scheduling. It enables agents to query recent workouts, training load, and missing data without sending health information to the cloud.

I had a problem explaining Ask My Health in one sentence. "An MCP server for HealthKit" is true, but it only makes sense if you already care about MCP. The clearer version is this: it lets an agent use your iPhone as a local, permissioned bridge to Apple Health training data. That matters because Apple Health already has the useful context: workouts, duration, distance, heart rate, power, cadence, HRV, VO2max and recovery signals. Normally, an agent cannot read that data. Ask My Health runs a local server on the iPhone and exposes a small set of tools to trusted clients on the same network. The setup The server is local network only. Codex connects to the iPhone endpoint over Streamable HTTP with bearer token authentication. Codex supports HTTP MCP servers and bearer tokens in its MCP configuration, so the app can be added without a cloud account or custom backend. mcp servers.ask my health url = "http://<iphone-local-ip :8787/mcp" bearer token env var = "ASK MY HEALTH TOKEN" default tools approval mode = "prompt" The token comes from the iPhone app. I do not put it into screenshots, commits or blog posts. After a demo, I rotate it. The prompt The useful prompt is not "make me fitter". It should tell the agent what data to read, what to avoid guessing, and when to stop for approval. Use my local Ask My Health MCP server. Look at my recent cycling workouts and training load. Use HealthKit as the source. Say which fields are missing instead of guessing. Then suggest one structured Apple Watch workout for tomorrow. Validate it with WorkoutKit. Do not schedule it until I approve it on the iPhone. That prompt gives Codex enough shape to use the tools in the right order. First authorization and read status. Then recent workouts. Then derived load metrics if the required inputs are available. Only after that should it produce a WorkoutKit plan. What Codex can read For a workout planning session, the agent usually starts with these tools: healthkit get authorization status checks whether HealthKit read access can be requested. healthkit request read authorization triggers the native iPhone permission sheet when needed. healthkit query workouts reads recent workouts, filtered by sport and date range. training compute load metrics computes derived load values when the required HealthKit inputs exist. The important part is what happens when data is missing. If there is no readable cycling power, the agent should not invent TSS. If there is no recent HRV, it should say so. Health data is useful, but it gets noisy fast when software starts filling gaps with confidence. Creating the workout Writing is narrower than reading. The app does not write arbitrary HealthKit values. It can prepare and schedule WorkoutKit workouts, which means structured sessions for the Apple Watch Workout app. The agent should validate the workout before scheduling it: workoutkit get capabilities workoutkit get authorization status workoutkit validate workout plan workoutkit schedule workout The final scheduling call still requires iPhone approval. That is intentional. An agent may suggest the workout, but the phone remains the place where the user grants HealthKit and WorkoutKit permissions. Why this is useful The product is not another dashboard. It is a small local bridge. The app lets an agent answer questions that are hard to answer from a generic chat window: - What did my last three rides look like? - Did I increase volume too quickly? - What is a sensible next interval workout? - Which data is missing from HealthKit? - Can you prepare that workout for my Apple Watch? This is where MCP makes sense to me. Not as a buzzword. As a narrow, local interface between an agent and data that should stay on the device unless the user explicitly opens it up. The tradeoff The local setup is slightly more work than a cloud login. You need the iPhone and the Mac on the same network. You need to copy a token. You need to approve HealthKit and WorkoutKit prompts on the phone. I think that is the right tradeoff for this category. Health data should not quietly become another remote account. The agent can help, but it should stay obvious when it reads private data and when it writes a workout.