Observed facts: The Devpost description says Faraday opens local NIfTI files or a bundled de-identified demo study and renders them in the browser with NiiVue. It lists five WebMCP tools: describe a study, find bright regions, focus a region, change the view layout, and export findings. The author says tool responses provide measurements and metadata rather than scan voxels, and export requires explicit human approval.
Mechanism: The app runs on React and Vite with NiiVue rendering via WebGPU or WebGL2. A browser agent invokes registered WebMCP tools; on-device analysis includes an intensity histogram and connected-component region finding. The key design choice is that the tool schema is treated as the privacy boundary: the agent receives structured results while the sensitive volume remains in the tab.
Why now: Browser agents can struggle with canvas-rendered interfaces because the visual data is not represented as useful DOM content. Faraday’s account makes the alternative concrete: the page can offer bounded capabilities without handing an agent the raw asset or uploading it to a hosted model.
Implications: This could inform browser-local agent interfaces for other sensitive visual workflows, provided tool outputs are carefully constrained and actions remain reviewable. It also shifts attention from whether agents can click a canvas to what information the page deliberately exposes.
Evidence boundary: These are claims in a project submission, not independent validation. The page explicitly says Faraday is for research and education, not a medical device or for diagnosis; it does not establish clinical performance, security certification, or hospital deployment.
Watch conditions: Whether planned DICOM/PACS ingestion preserves the local-compute model is the first meaningful next test. Also watch for independent evaluation of tool correctness and the behavior of approval gates under real workflows.