Building an AI glasses app sounded like learning a dedicated SDK and a new UI framework first.

But the direction Meta showed at Connect 2026 is a little different.

If you already write HTML, CSS, and JavaScript, you can build Web Apps for Meta Ray-Ban Display with those same skills — and with WebMCP you can let Meta AI call parts of your app directly.

Imagine a wearer saying this through the glasses:

"Add milk to my shopping list."

The old way might have AI look at the screen, find the button, and press it — or require a separate app-specific integration API.

With WebMCP, the website itself can declare:

Features this web app allows AI to use

- add_item
- complete_item
- show_today_list

Meta AI finds and calls only the allowed features.

The important shift here is not simply "a web page opens on glasses."

Web apps are starting to ship an interface for AI agents alongside the interface for people.

First, separate Web Apps from WebMCP

Treating the two as one technology makes both confusing.

Web Apps

Web Apps are web applications that run on Meta Ray-Ban Display.

Per Meta's official docs, they use standard Web APIs with no companion app, built in HTML, CSS, and JavaScript.

Representative supported features look like this.

Display
- 600 x 600 additive display

Input
- directional moves
- select
- pinch-and-drag
- Meta Neural Band input

Text
- voice dictation
- handwriting
- on-screen keyboard

Context
- device motion
- orientation
- phone location

Network
- fetch
- WebSocket

Offline
- Service Worker
- Cache API

In short, you can reuse much of your existing web skill set.

WebMCP

WebMCP is the pattern for exposing features an AI agent may call as structured tools inside a web app.

Meta offers WebMCP as a developer preview today, and developers define which features to open to Meta AI.

Simplified, the flow looks like this.

User
  ↓
"Add milk to my shopping list"
  ↓
Meta AI
  ↓
check tools the web app exposed
  ↓
add_item({ name: "milk" })
  ↓
web app runs it
  ↓
result returns

Instead of AI guessing "this button looks right" from the screen, the web app supplies an explicit feature contract.

Why is this interesting?

Agent control of the web has mostly taken two shapes so far.

1. See the screen and operate it

Screenshot
→ infer button position
→ click
→ confirm screen change

This resembles how people use apps, but it breaks easily when the UI changes.

2. Call the service API directly

Agent
→ REST API
→ Backend

Stable, but each service may need its own agent integration.

WebMCP aims somewhere in between.

The web app itself
tells the agent "these are my features."

If UI is the interface for people, WebMCP tools are the interface for AI.

CodeBridge Mini Lab: add one AI tool to a Todo web app

Take the smallest possible example.

Say your existing web app has this function.

async function addTodo(text) {
  todos.push({ text, done: false });
  renderTodos();
}

People type into the input and press the Add button.

User
 ↓
Input
 ↓
Button
 ↓
addTodo()

With WebMCP, you wire that same function as a tool the AI can call.

The example below illustrates the concept of the September 2026 WebMCP draft API. WebMCP and Meta support are still in preview, so recheck the latest spec and Meta docs before shipping anything real.

const controller = new AbortController();

await document.modelContext.registerTool(
  {
    name: "add_todo",
    description: "Adds one new todo to the current todo list.",
    inputSchema: {
      type: "object",
      properties: {
        text: {
          type: "string",
          description: "The full text of the todo to add"
        }
      },
      required: ["text"]
    },
    async execute({ text }) {
      await addTodo(text);

      return {
        content: [
          {
            type: "text",
            text: `Added the todo '${text}'.`
          }
        ]
      };
    }
  },
  { signal: controller.signal }
);

The point is not building one more piece of business logic.

It is giving the existing addTodo() two entrances — one button for people, one tool for AI.

             ┌─ UI Button ───────┐
User ─────────┤                   ↓
             │                addTodo()
Meta AI ──────┤                   ↑
             └─ WebMCP Tool ─────┘

When that structure holds, the UI path and the agent path stop drifting into separate implementations.

The goal is not exposing lots of tools

Seeing WebMCP for the first time, you may want to expose every app feature as a tool.

The safer move is the opposite.

For a shopping app with:

search_products
show_cart
add_to_cart
remove_from_cart
checkout
change_address
cancel_order

open everything at once less readily; start from low side-effect features.

Step 1
search_products
show_cart

Step 2
add_to_cart
remove_from_cart

Step 3
checkout
cancel_order

Payment, deletion, and ordering change real state, so a wrong AI call costs more.

So before asking "what can AI do," ask this first when designing agent tools.

What happens when the AI gets it wrong?

A good tool schema reads like a small API doc

Which of these two tools could an AI use more reliably?

The vague version

{
  name: "add",
  description: "Add item"
}

The clear version

{
  name: "add_todo",
  description: "Adds one new todo to the current user's todo list.",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "The full sentence the user wants to add as a todo"
      }
    },
    required: ["text"]
  }
}

The second one is far clearer.

To an AI agent, tool names, descriptions, and parameter schemas are effectively API docs and part of the prompt at once.

So using WebMCP well depends less on prompt writing than on:

clean function boundaries
clear names
small input schemas
predictable return values
side-effect management

On AI glasses this structure feels even more natural

On a phone, you can touch the screen yourself.

On AI glasses, the situation differs.

Cooking
Cycling
Repairing equipment
Inspecting a site
Exercising

Hands are often busy in these moments.

That is why Meta frames AI glasses development as a hands-free, eyes-up experience.

For a site-inspection web app, a wearer could say:

"Mark the current equipment as inspected."

and a WebMCP tool would call:

mark_inspection_complete()

That fits the glasses form factor better than opening menus and hunting small buttons.

Do not build the screen like a mobile UI either

Meta Ray-Ban Display Web Apps use a 600x600 additive display.

Meta explains that dark backgrounds fade from view while bright, high-contrast elements stand out.

So instead of shrinking a desktop site:

one screen
one purpose
short text
large status display
minimal choices

fits far better.

Even in a Todo app, prefer this:

Next todo

Send the meeting notes

[Done]

over this:

17 todos today
6 filters
stats charts
side menu

Show only what the moment needs.

You can start without the hardware

This also lowers the entry barrier substantially.

Meta ships a browser-based Web App Simulator for Ray-Ban Display.

In Chrome you can simulate:

600 x 600 display
D-pad input

and test layout plus basic interaction without real glasses.

So a web developer's smallest experiment can start here.

1. Prepare an existing Todo web app
2. Simplify the UI to 600x600
3. Support arrow keys + Enter
4. Add exactly one WebMCP tool
5. Verify in the browser simulator

No giant AR project needed.

WebMCP and Meta AI Connector are not the same thing

Another easy confusion.

WebMCP

Meta AI
→ calls tools of the currently open web app

It lets AI operate features inside the web app.

Meta AI Connector

Meta AI
→ external service / API / MCP server

It connects the service itself to Meta AI without opening any web app.

A simple selection rule:

An experience that needs a screen
→ Web App

Voice control of features inside the web app
→ WebMCP

Connecting the service itself to Meta AI
→ Meta AI Connector

Deeper camera, audio, or hardware access
→ Device Access Toolkit

Should you build an AI glasses app right now?

Not every service needs one.

WebMCP is in developer preview today, and general distribution and discovery paths are still expanding.

Still, the value of looking now is real for web developers.

Because a bigger change sits behind the Ray-Ban Display itself.

The assumption that a website's users are only people is quietly breaking.

Web apps will likely carry two interfaces at once:

UI for people
Tools for AI

From that angle, WebMCP is less "an AI glasses feature" than an experiment showing how agent use of the web may change.

Conclusion: good web apps may soon need to design for AI use too

Meta Ray-Ban Display Web Apps let web developers enter a new form factor with familiar skills.

WebMCP goes one step further.

The old web
person → UI → function

The web with WebMCP
person → UI ───────┐
                   ↓
AI → Tool ──────→ function

The point is never giving AI every permission.

It is designing which tasks to expose as tools, which run only after user confirmation, and which never open at all.

Web development's focus is widening from screen layout toward designing the feature boundaries agents may use. That is the most interesting place to watch WebMCP right now.

Further reading

References

Go deeper with a course

If you want to build web apps hands-on with AI assistance — from layout to deployment — a guided course takes you through the full flow.