Betatrace

Live Dashboard
WebMCP Graph Use Case
Seven-Day Graph with Meal Markers
Three Registered Tools
Landing Hero Page
Meal Log Showing Agent Provenance
Safety Boundaries

Inspiration

I was diagnosed with Type 1 diabetes three years ago. The hard part was not learning one single thing. It was keeping up with dozens of small things every day: checking glucose, remembering meals and insulin, and trying to work out why the same routine sometimes produced a completely different result.

A lot of the tools I found felt old, expensive, or disconnected from how I actually wanted to manage everything. At the same time, ChatGPT and other AI tools were becoming genuinely useful. I kept wondering what would happen if an agent could work inside a diabetes app with me, using the information already on the screen instead of making me repeat it all in a separate chat. That idea became BetaTrace.

What it does

BetaTrace is a Type 1 diabetes dashboard that both a person and a browser-based agent can use.

The dashboard lets someone explore glucose readings, meals, insulin entries, trends, and time in range. The WebMCP tools let an agent work with that same demo data:

get_demo_state reads the current synthetic data, including seven days of glucose readings and logged meals.

log_demo_entry records a glucose reading, meal, or insulin dose that the user says has already happened.

reset_demo_data clears added entries and restores the original sample data, but only after the user confirms it.

For example, I can ask an agent to graph my glucose and meals from the past week, log a new meal, and then generate the graph again. The new meal appears in both the dashboard and the agent’s updated graph.

Without WebMCP, the agent would have to inspect the page, guess what each control does, and click through the interface. BetaTrace gives it clear tools with defined inputs and responses.

How I built it

BetaTrace is a React app hosted on Vercel.

The page registers its tools directly with document.modelContext.registerTool(). There is no separate WebMCP server and no polyfill. The dashboard and the agent tools use the same validation and local data, so an entry logged by the agent appears on screen immediately.

For the seven-day graph, get_demo_state returns 336 chronological glucose readings along with the meals recorded during that period. This gives the agent enough real structure to produce a useful graph instead of a rough summary.

The public demo only uses synthetic data stored in the browser. Its WebMCP tools cannot reach Supabase, private accounts, or real patient information. BetaTrace can record an insulin dose that the user says they already took, but it will not calculate or recommend one.

Challenges I ran into

The first version could return a summary of the demo, but that was not enough to make a proper seven-day graph. We had to expose the underlying timeline while keeping the response clear and predictable for the agent.

Keeping the agent and the visible dashboard in sync was another challenge. A successful tool call was not enough. If the dashboard did not update at the same moment, the whole idea of working together inside one page fell apart.

The safety boundaries also took some thought. Health data is not a good place for vague permissions. We limited the demo to synthetic local data, validated every write, blocked dose recommendations, and made reset require confirmation.

Accomplishments that I'm proud of

The part I am most proud of is the full loop.

An agent can read seven days of glucose and meal data, turn it into an interactive graph, log a meal supplied by the user, and then produce a new graph containing that meal. The person sees the same change inside BetaTrace.

It sounds simple when written out, but that shared state is what makes the project feel like collaboration instead of ordinary browser automation.

I am also proud that the safety limitations are part of the design rather than a disclaimer added at the end. The demo is useful enough to prove the idea without pretending that an experimental agent should be making treatment decisions.

What we learned

A button exposed as a tool is not automatically useful.

The tool has to match something a person would naturally ask for. It needs understandable inputs, useful output, proper validation, and clear limits. Building the WebMCP layer forced us to think more carefully about what BetaTrace actually knows and what an agent should be allowed to do with it.

We also learned that the best WebMCP moments are visible. When the agent logs a meal and the dashboard changes immediately, there is no need for a long explanation. You can see that the person and the agent are working with the same application.

What's next for Betatrace

The current version stays inside a synthetic guest demo on purpose.

The next step would be optional authenticated accounts with narrow permissions, a visible history of agent actions, and confirmation for anything sensitive. Users should always be able to see what the agent accessed and what it changed.

Future tools could prepare appointment summaries, compare glucose responses after recurring meals, and help someone collect questions for their care team. They would still stop short of diagnosis or automatic dosing advice.

The goal is not to hand diabetes management over to an agent. It is to reduce some of the repetitive work while keeping the person in control.