Faraday

Inspiration

Building applications for the healthcare industry provides enough red-tape to jump through on a good day. In a world where web technology has made it to every device and is capable of providing full blown applications; I chose to explore building something that always intrigued me at a personal level, the viewing of an MRI (or similar) scan. It neatly taps into the fact that the data does not need to leave the browser.

Medical imaging makes this concrete. A CT or MRI in the browser is a GPU texture on a canvas. An agent looking at the DOM sees an empty element. The usual shortcut is to upload the study to a hosted model, which hospitals may not want to do with patient data. So either agents stay out of radiology workflows entirely, or the tools have to run where the scan already is.

That is what Faraday is for. Data stays in the tab, agents are capable of getting the information they need, and it stays token efficient.

What it does

Faraday is a browser reading room for volumetric CT and MRI. You open a local NIfTI file, or load the bundled de-identified demo study, and the viewer renders it with NiiVue. An agent connected over WebMCP can call five tools: describe the study, find bright regions, focus one of those regions, change the view layout, and export findings. While that happens, the human can see overlays update on the image itself.

The agent never receives the scan. Tool responses are measurements and metadata — dimensions, millilitre volumes, window hints, a JSON report. The only tool that moves anything off the page is export_findings, and it requires explicit human approval before it returns.

How It's Built

The app is React and Vite on top of NiiVue for WebGPU and WebGL2 volume rendering. WebMCP registration goes through a vendored https://github.com/thegreataxios/webmcp stack: document.modelContext.registerTool, journey grouping, and HITL-guarded tools, with a polyfill when native WebMCP is not available.

describe_study runs an on-device intensity histogram (WebGPU compute when it works, CPU otherwise) and suggests a bright window for region finding. find_regions does connected-component labeling in that window and paints the results into NiiVue’s drawing overlay. Study loads bump an epoch so stale agent work cannot paint the wrong volume, and mutating tools run one at a time so concurrent agent calls do not interleave.

Challenges I ran into

Without WebMCP, canvas-based viewers are basically unreachable. DOM automation cannot see a volume texture, so the agent has nothing reliable to act on. Making “measurements only” real also meant treating the tool output schema as the privacy boundary, not as documentation.

Running more than one agent against one study was messier than the first version assumed. Opening a new file replaces the current study, in-flight calls need to know when their epoch is stale, the tool queue has to stay exclusive, and a pending export approval has to cancel if the study changes underneath it. Getting the UI to feel like a reading room instead of a hackathon demo took longer than wiring the tools.

Accomplishments that I'm proud of

The loop works end to end: an agent can measure a volume in the browser and the raw voxels never leave the tab. Export is actually gated. Multi-file and multi-agent safety does not require a backend. The repo is open source, the app is live, and there are agent discovery manifests so the tools are not a private handshake.

What I learned

WebMCP is not mainly about letting agents click better. It lets a page define what an agent is allowed to know and do while the sensitive asset stays put. For medical canvases especially, structured tools are the difference between a real workflow and an agent staring at a blank .

What's next for Faraday

DICOM and PACS ingestion without breaking the local-compute model. Better radiologist UX around hanging protocols and series stacks. Better evaluation around tool correctness when the model fails. It stays research and education for now — not a medical device, and not for diagnosis.