Dusky

Inspiration

Smart glasses are becoming a real product category, not a demo. Google and Samsung are building their own, and Apple is rumored to be entering the space too. I own a pair of Meta Ray-Ban Display glasses myself and wanted to build for them directly.

Wearable displays cannot use ordinary websites effectively. Meta Ray-Ban Display provides a 600 by 600 screen, directional controls, and no pointer or scrolling. Shrinking a webpage does not make it usable on glasses.

WebMCP offers a better starting point: the actions a website says it can perform. Dusky explores whether those actions can become a practical wearable interface without every provider building a separate glasses app.

What it does

Dusky discovers actions exposed by authorized WebMCP websites and turns their schemas into small, step-by-step screens for Meta Ray-Ban Display.

The wearer can select actions, provide parameters, review results, and confirm anything Dusky does not classify as read-only. If information moves between providers, Dusky separately shows the source, destination, and exact value before sharing it.

Tools still execute inside their original website pages. Dusky supplies the wearable interface and task flow (not a replacement backend).

How I built it

Dusky has three main parts:

• A browser console discovers and invokes live WebMCP tools.

• A relay maintains the paired task and sends each interface frame to the glasses.

• A fixed 600 by 600 Display app renders the current frame and accepts directional input.

Tool schemas generate choices, text entry, confirmations, progress states, and results. An optional planner can propose a short sequence of actions, but deterministic code validates every tool, argument, policy decision, and provider boundary before execution.

Challenges I ran into

Browser WebMCP behavior differed from the published API, especially around invocation arguments, cross-origin discovery, and tools returned from the calling page. Dusky uses a temporary read-only compatibility probe so it never tests browser behavior by risking a real provider action.

The glasses introduced different constraints. Pairing codes had to remain legible through a waveguide, dim text became difficult to read on an additive display, and delayed input had to be rejected when it belonged to an older frame.

Cross-provider tasks also required a clear trust model. Sharing a value and approving the action that uses it are intentionally separate wearer decisions.

What I learned

A website’s interface and its capabilities do not have to travel together. Once a provider describes its actions and inputs through WebMCP, those capabilities can be reshaped for a 600 by 600 display without recreating the webpage.

I also learned that emerging browser APIs must be tested at the exact boundary a product uses. Top-level WebMCP support did not guarantee cross-origin provider discovery, and actual browser behavior sometimes differed from the published API.

Finally, designing for glasses is not simply responsive web design. Limited input, additive-display legibility, interrupted connections, and wearer confirmation change how tasks must be presented. The useful interface was not a smaller website, but a focused sequence of choices and decisions.

Built With

• ar
• browserapi
• glasses
• hci
• hono
• json
• node.js
• playwright
• react
• render
• turborepo
• typescript
• vercel
• vite
• webmcp
• websockets
• zod
• zustand