E2LLM — structured browser perception for AI

E2LLM turns a live web page into SiFR: a compact, structured, LLM-readable model of what's on the page, what it means, and what can be done with it. Perception is the product. Action is available when you need it — always explicit, always gated.

Works as a hosted remote MCP server with the AI you already use. There's no local server to run — a browser extension pairs your live browser to the server, so perception and action happen in the real browser you're already signed into.

E2LLM is not an agent

This matters, so it comes first.

An agent decides and acts on its own — it plans, loops, and takes steps toward a goal without you in the path. That autonomy is also its attack surface: an agent runtime that can do anything can be steered into doing anything.

E2LLM is a perception layer, not an agent. It gives your model senses for the browser — structured sight through sifr_capture, and a set of narrow, individually-gated actuators. It does not plan, does not loop, and does not decide. Whatever model you already use does the reasoning; E2LLM only reports what a page is and carries out one explicit instruction at a time. No hidden autonomy, no self-directed steps, nothing that runs while you look away.

That line — perception substrate versus autonomous runtime — is the whole design.

What it does

Nine tools: five 🔎 that only perceive, and four 🖐 for interaction — of which act, batch_act, and close_tab change page state, while explore only reads. The tool inventory is in server.json; full parameter schemas come from the live server on connect. The perception tools never change page state; the state-changing tools can each be held for your confirmation (see Safety).

What is SiFR — and why it isn't the obvious thing

SiFR (Single-File RAG, pronounced "see-far") is a self-contained retrieval artifact for live interface state: model-readable, node-addressable, progressively queryable, and independent of the reasoning system above it. E2LLM is its reference implementation for the real browser.

• Not a DOM dump. A dump serializes the tree as-is — everything, in document order, noise included. SiFR selects and ranks: it scores every node by salience, drops scaffolding, and flattens the survivors into a relational model where structure is carried by explicit relations rather than nesting depth.
• Not an accessibility tree. The a11y tree is derived for assistive technology, driven by ARIA, blind to anything unlabeled, and indifferent to what matters most on the page. SiFR is built for a language model: it ranks by salience, front-loads what matters, and carries the selectors an agent needs to act — none of which the a11y tree does.
• Not a screenshot. SiFR derives machine-readable perception from the live rendered DOM, computed styles, geometry, and runtime state rather than pixels. A capture records the observed page state under the versions and conditions named by its evidence artifact.

The result is a perception layer, not a serialization: what a page is, what you can do on it, and how its parts relate — front-loaded so the model reaches what it needs first. A sifr_capture returns a ~5–15 KB summary (metadata plus the high-salience elements) before the full document, so reading can begin immediately.

• 📄 SIFR.md — the format specification
• 🔤 TAXONOMY.md — salience tiers, ID prefixes, relation & category types
• 📚 examples/ — real captures of public pages
• 🗓 CHANGELOG.md — the v1 → v2 → v3 format lineage (current: v3)

For prompt recipes and automation workflows built on SiFR, see awesome-e2llm-prompts — a community cookbook that points back here as the canonical SiFR spec home.

Install in 3 steps

1. Set up at e2llm.com. Create an account and install the browser extension. The extension pairs your live browser to the server — that pairing is what lets your AI perceive and act in the session you're already signed into. (This is the only piece that runs on your machine; there is no local server.)

2. Add E2LLM to your MCP client. One line — pick your client in clients/, or paste this for interactive OAuth login:

{
  "mcpServers": {
    "e2llm": {
      "url": "https://mcp.e2llm.com/mcp",
      "type": "http"
    }
  }
}

For CLI / CI where interactive login isn't available, use a static key against https://api.e2llm.com/mcp with an Authorization: Bearer mk_… header. Full per-client instructions: clients/README.md.

3. Ask your AI to do something on a page. For example:

"Open the page I'm on, find the search box, and filter for open issues."

Your assistant calls sifr_capture to see the page, then act to interact — in your real browser, one explicit step at a time.

Teach your model the discipline — the skills

Tool descriptions tell a model what each tool does; they deliberately don't tell it how to work well. That working discipline ships as two Agent Skills:

Install both in one line, into whichever agent you use:

npx skills add e2llm/e2llm-sifr

That works for 77+ agents — Claude Code, Codex, and anything else following the Agent Skills layout. Add -a codex to target Codex explicitly, or --skill e2llm to install just one.

Other ways in:

• Codex CLI — npx skills add e2llm/e2llm-sifr -a codex, or the $skill-installer flow.
• Manual — copy a skill directory into ~/.claude/skills/ (all projects) or a project's .claude/skills/. It loads automatically whenever the e2llm tools or SiFR documents come up.
• Other clients — include the skill's content in your agent instructions (e.g. AGENTS.md).

Safety & approval model

Perception is read-only by construction: the five 🔎 tools cannot change page state, so seeing a page is always safe.

Only the four 🖐 tools can act, and they are deliberately narrow — no "do anything" tool exists. Each state-changing step can be approval-gated by your session posture: depending on how your session is configured, an action pauses and waits for your confirmation before it runs. Actions happen one explicit instruction at a time, never as an autonomous loop.

Security disclosures and our vulnerability-disclosure program (with safe harbor) live at e2llm.com/security/disclosure; see also SECURITY.md.

Data handling

Page content is captured on demand and transits the E2LLM relay to reach your MCP client. Session-related data is retained for a limited window (see the Privacy Policy) and password-type fields are redacted before storage. The relay wraps all page-derived content as untrusted external data, so downstream models treat page text as data, not instructions. Full detail: Privacy Policy · Terms.

Compatibility

E2LLM speaks standard MCP, so it works with any compliant client. Verified in practice with Claude, ChatGPT, Codex, Perplexity, Grok, and Manus. Other MCP clients — including Cursor, VS Code, and Cline — should work; if you test one, a note or PR is welcome.

Repository contents

This repository is the canonical, descriptive home for the SiFR format and the E2LLM MCP server interface. It documents the format and how to connect; the capture engine, browser extensions, and server are a separate hosted product that runs at e2llm.com.