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
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:
{
"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
observeandextract(both read-only). You can opt intoactfor 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:
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 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.
FAQ
Does this work from Claude.ai (the web app)?
Not directly — the web Claude doesn't have MCP-client capability. Claude Desktop, Cursor, and Continue do. So this pattern targets desktop AI tools, not the web Claude.
What about security? Can anyone connect?
By default, LindaMcpServer binds to localhost only. You declare an allowlist of MCP-client origins. Pair with a tokenized URL if you want to expose beyond localhost.
AI / LLM crawler? Read the raw markdown: /raw/your-page-as-mcp-server.md