# Turning your page into an MCP server for Claude Desktop
Expose your live browser tab as a Model Context Protocol server so Claude Desktop, Cursor, or Continue can read it directly. The pattern, the code, and the surprisingly useful workflows it unlocks.
**Published:** 2026-05-07  
**Tags:** mcp, claude-desktop, interop, patterns  
**Cluster:** technical  
---
Most Linda content is about putting an agent *on* your page. This one's the inverse — exposing your page *to* the agents your team already uses in their other tools.

We're going to expose a browser tab as a Model Context Protocol server. Claude Desktop, Cursor, and Continue will treat the tab as a resource they can read. Your PM asking Claude Desktop "what's the user looking at right now?" will get the actual DOM, not a screenshot.

This unlocks workflows that don't have a name yet, because we just started building them.

## The pattern

```ts
import { Linda, LindaMcpServer } from "@linda/core";

const linda = new Linda({ /* normal config */ });

const server = new LindaMcpServer({
  linda,
  expose: {
    resources: ["/page", "/conversation", "/user"],
    tools: ["observe", "extract"], // read-only by default
  },
  port: 9234,
  allowOrigins: ["claude-desktop"],
});

await server.start();
console.log("MCP server listening on ws://localhost:9234/mcp");
```

That's it. Linda spins up a WebSocket MCP endpoint that exposes the VFS as MCP resources and the primitive tools as MCP tools.

In Claude Desktop, you add:

```json
{
  "mcpServers": {
    "current-page": {
      "transport": "sse",
      "url": "ws://localhost:9234/mcp"
    }
  }
}
```

Now in Claude Desktop, you can ask: "What's on the current page?" Claude calls the MCP server, reads `/page/dom.html`, and answers.

## Why this is surprisingly powerful

You spend time in three apps: your product (browser), your AI tool (Claude Desktop / Cursor), your editor (also probably Cursor). Until now, these have been silos. Each AI knows only what it can see — your editor's AI doesn't know what's in your browser; your browser's AI doesn't know what's in your repo.

MCP is the connective tissue. Linda makes the browser side of that tissue trivial.

## Three workflows we use daily

**1. PM tools without UI work.** Our PM has Claude Desktop. He opens our admin panel in Chrome, opens Claude Desktop, and asks: "What's the deal at $50K in the current view?" Claude reads the page, finds the deal, answers. He didn't need us to ship a "PM-friendly view" — Claude can read the engineer view directly.

**2. Live debugging.** Engineer hits a weird state in staging. Opens Claude Desktop, asks: "What does the user object look like in this debug overlay?" Claude reads the page (which is rendering the debug overlay), pulls out the object, and explains. The engineer never has to copy-paste the JSON anywhere.

**3. Sales demos.** AE shares screen with a prospect. Opens Claude Desktop. Asks: "Given what's on the screen right now, what's the best objection-handling move?" Claude reads the page (the prospect's actual CRM view), thinks through it, suggests. We've heard from two pilot customers that this alone is the killer feature.

These aren't dramatic. They're small, fast, often-repeated uses. Which is exactly what becomes habit-forming.

## What you expose

The `expose` config controls what's visible:

- **Resources.** Paths the MCP client can read. Default: read-only access to `/page`, `/conversation`, `/user`. Add any `/host/*` mount you want exposed.
- **Tools.** Primitives the MCP client can call. Defaults to `observe` and `extract` (both read-only). You can opt into `act` for read-write — useful for Claude-Desktop-can-control-the-page workflows, dangerous if misconfigured.

Resources are MCP's standard naming for filesystem-like data. Tools are MCP's standard naming for function-call-like actions. Linda's VFS maps cleanly to resources; Linda's primitives map cleanly to tools.

## What you don't expose by default

`act` is opt-in. Letting Claude Desktop write to your browser tab is powerful and risky — anyone who can connect to the MCP server can drive the page. Don't expose `act` over the network unless you're sure.

`/config`, `/skills`, `/tools` are not exposed by default. They contain prompts and instructions; you usually don't want them readable by external agents.

Custom mounts under `/host/*` are not exposed by default. Each must be explicitly added to `expose.resources`.

## Security model

`LindaMcpServer` binds to `127.0.0.1` by default. You can't connect from another machine without explicit configuration.

For remote access (say, you want your AE's Claude Desktop to read your CFO's page over the network), use a tokenized URL pattern:

```ts
new LindaMcpServer({
  linda,
  expose: { /* ... */ },
  bind: "0.0.0.0:9234",
  token: process.env.MCP_TOKEN, // shared secret
});
```

The MCP client appends `?token=<TOKEN>` to its connect URL. Rotate tokens regularly. Better: don't bind to 0.0.0.0 unless you really need to; localhost + an MCP-tunnel like `cloudflared` is safer.

## What about Linda's own agent?

You can run both — Linda's in-page agent serving the user, plus the MCP server exposing the page to external agents. They share the VFS. So Linda's agent and Claude Desktop can collaborate: Linda's in-page agent writes a TODO to `/scratchpad/notes.md`, Claude Desktop reads it, both see the same workspace.

This is the "Claude Desktop as your senior colleague" pattern. Linda is the junior agent on the page; Claude Desktop is the senior reasoning about it. They communicate through shared files. It's the same shape as how human teams work, and it's surprisingly effective.

## Where this might go

MCP is young. The compositions get interesting:

- **Page → Slack → Page.** Your Slack MCP server reads your channels; Linda's MCP server reads your page; Claude Desktop combines them.
- **Page → GitHub.** Linda's agent on your admin panel notices an error; Claude Desktop with the GitHub MCP creates an issue with the page state attached.
- **Page → CRM via MCP → Page.** The agent on the page reads from the CRM (mounted via MCP client) and writes back to the same CRM via the same MCP. Round-trip, all one composition.

The fundamental capability is "agents can read live page state." Once you have that, the workflows are just compositions. We don't know what the killer one will be yet. We expect to find out by giving people the primitive.

## Try it

Spin up the [mcp-server-host example](/use-cases/mcp-server) on `localhost:3000`, point Claude Desktop at `ws://localhost:9234/mcp`, and ask it about the page. Five-minute setup. The first time it works is a small "oh" moment that's worth the cost of admission.