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.
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.
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.
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
.
The server exposes nine tools, split on a hard line:
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.
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.
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.
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.
clients/
.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.