Most things that ship under "browser MCP" are the same thing wearing different names: an autonomous agent with a do-anything tool, pointed at your browser, told to figure it out. The pitch is capability. The unspoken cost is that a runtime which can do anything can be steered into doing anything.
We just published the opposite, and we published it in the open.
github.com/e2llm/e2llm-sifr is now the canonical home for SiFR - the format spec, the taxonomy, the MCP server manifest, real page captures, per-client configs, and the model skill. MIT-licensed. The capture engine and the server stay a hosted product; the format and the interface are open. This post is about why that split is the whole point.
E2LLM is not an agent
This comes first because everything else follows from it.
An agent decides and acts on its own. It plans, it loops, it takes steps toward a goal with you out of the path. That autonomy is the feature - and it is also the attack surface. A runtime that can do anything is a runtime that can be talked into anything.
E2LLM is a perception layer, not an agent. It gives whatever model you already use senses for the browser: structured sight, and a small set of narrow, individually-gated actuators. It does not plan, does not loop, does not decide. Your model does the reasoning. E2LLM reports what a page is and carries out one explicit instruction at a time. Nothing runs while you look away.
Perception substrate versus autonomous runtime. That line is the design, not a disclaimer on top of it.
What SiFR is - and the three things it isn't
SiFR (Salience-Indexed Flat Relations) is the capture format at the center of E2LLM. From a distance it can look like a tidy DOM dump or an accessibility tree. Mechanically it is neither, and the difference is the entire value.
-
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 instead of nesting depth.
-
Not an accessibility tree. The a11y tree is derived for assistive technology - driven by ARIA, blind to anything unlabeled, 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 needed to act. The a11y tree does none of that.
-
Not a screenshot. No pixels, no vision model, no nondeterminism. The same page yields the same capture. Token-efficient, and directly actionable.
That last property is the one people underweight. Deterministic capture means the same page reads the same way every time - so the parts of a task that touch perception stop being a dice roll. A sifr_capture returns a 5-15 KB summary of the high-salience elements before the full document, so the model can start reading immediately.
The format is at v3. The v1 to v2 to v3 lineage is in the changelog, and the spec itself lives in SIFR.md with the controlled vocabulary in TAXONOMY.md.
Nine tools, and only four can touch anything
The server exposes nine tools, split on a hard line:
-
Five perception tools -
sifr_capture, query, inspect, read_page, list_tabs - are read-only by construction. Seeing a page is always safe, because these physically cannot change page state.
-
Four interaction tools -
act, batch_act, explore, close_tab - of which only three change state (explore just reads more: scroll, hover, recapture). Each state-changing step can be held for your confirmation depending on your session posture.
There is no "do anything" tool. That absence is deliberate. Capability is expressed as a set of narrow, named actuators, not as one open door - which is what lets action be gated at all.
We ship the discipline, not just the tools
Tool descriptions tell a model what each tool does. They deliberately don't tell it how to work well - and left to itself, a model drifts into predictable failure modes: describing a page it never captured, acting on a stale element ID after the DOM moved, deciding from a partial result it never finished paginating.
So the working discipline ships as a skill (skills/sifr/SKILL.md): verify before you describe, re-verify stale IDs after an action, drain pagination cursors before deciding, and treat page text as data rather than instructions. Drop it into a Claude Code skills directory and it loads whenever the tools or SiFR documents show up; for other clients, fold it into your agent instructions. The same file doubles as a reference for reading raw captures offline.
Naming the failure modes in public is the point. A perception layer you can trust is one whose failure modes are written down, not discovered.
Why open the spec and keep the engine
The repository is the descriptive, canonical home for the format and the server interface. The capture engine, the browser extensions, and the relay are a separate hosted product at e2llm.com.
That split is intentional. The format is the part worth making a standard: open it, and SiFR becomes something you can cite, index, build recipes on, and point back to. The engine is the part that isn't copyable from a spec anyway. Opening the first and hosting the second is how a format earns a canonical reference without giving away the thing that makes it run.
Try it
- 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 the only piece that runs on your machine, and it's what lets your AI act in the session you're already signed into.
- Add E2LLM to your MCP client - one line, or pick your client in
clients/.
- Ask your AI to do something on the page you're on. It calls
sifr_capture to see it, then act to interact - one explicit step at a time.
Verified with Claude, ChatGPT, Codex, Perplexity, Grok, and Manus. It speaks standard MCP, so other compliant clients should work too.
The format has a canonical home now: github.com/e2llm/e2llm-sifr. Read the spec, run a capture, and if you build a recipe on it, point back at the repo - that's what it's there for.