Actionbook: an MCP connector and Chrome extension that drives your logged-in browser
Let your AI agent get the sources behind logins and paywalls.
At a glance
- What is it?
- Actionbook pairs a hosted MCP endpoint with a Chrome extension so an agent operates your real, authenticated session instead of a headless clone. It is a browser-side product with a public Rust repository, and the README's performance claims are marketing numbers, not measurements you can reproduce from the repo.
- Who is it for?
- Adopt Actionbook if your agents need to read pages that sit behind your own logins and you are willing to run a hosted MCP endpoint plus a Chrome extension rather than a headless browser you control. Do not adopt it if you need documented self-hosting, an auditable data path, or reproducible performance numbers, because the README supplies none of those.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The login wall is the problem Actionbook targets
Most agent browser stacks run against a fresh, unauthenticated profile. That works for public pages and fails the moment a task needs your inbox, your CRM, or a paid article. Actionbook's stated purpose is to let an AI agent read data behind logins and paywalls and operate sites the user already uses. The README frames the output as finished work rather than answers: a sourced report, a CSV, or ready-to-send drafts. The intended user is someone who already has an MCP-capable assistant and wants it to act inside their existing Chrome session. The repository itself is Rust and carries an Apache-2.0 licence, but the README describes the product as a Chrome extension plus a hosted connector, not as a Rust library you build against.
A remote MCP endpoint drives your real Chrome through an extension
The architecture has three parts. An MCP-compatible client connects to a hosted endpoint at https://edge.actionbook.app/mcp. A Chrome extension installed from the Chrome Web Store links to that endpoint after you sign in from the dashboard. The agent then issues browser commands that the extension executes in your browser. Actionbook exposes a single MCP tool named actionbook whose subcommands split into action lookup (search, manual) and browser control (goto, snapshot, click, type, and others). The README says the agent discovers the full command set from the tool description once connected, which means the tool surface is not enumerated in the repository README itself. The design intent is that direct API requests are used when possible and UI automation when not, with the extension reusing your logged-in sessions either way.
Action manuals replace step-by-step page parsing
The README contrasts two agent behaviours. Without Actionbook, an agent takes a snapshot after every step, parses the page, and decides what to do next; the README gives searching one room on Airbnb as a five-minute example. It also argues that virtual DOMs, streaming components, and SPAs break agents on dropdowns, date pickers, and login walls. With Actionbook, the agent fetches what the project calls action manuals, described as telling the agent exactly what to do, so no parsing or guessing is needed. The README claims a 10x speedup and a stateless architecture that lets agents operate dozens of tabs in parallel, plus a video of an agent visiting 192 First Round portfolio company websites in two minutes. Treat all of those as vendor claims. Nothing in the repository material explains how a manual is authored, how it is versioned when a site changes, or how the agent falls back when a manual is missing or stale. That gap matters more than the speed figure.
Setup is three steps, and the CLI path is closed
The README states there is no CLI install. The steps are: install the Chrome extension from the Chrome Web Store; add Actionbook as a connector in your AI app by pasting https://edge.actionbook.app/mcp into the connector settings (the README names Claude under Settings, Connectors, Add custom connector, plus ChatGPT under Settings, Connectors, Perplexity, Hermes, OpenClaw, and any other MCP-compatible app); then finish setup from the dashboard at https://actionbook.app/dashboard, which confirms the extension is linked. The README explicitly marks the standalone @actionbookdev/cli package as deprecated and directs users to the remote connector plus extension. Once connected, the README's example prompt is a plain instruction to open stripe.com, linear.app, and vercel.com and grab the pricing from each, with an optional nudge sentence: Use Actionbook to understand and operate the web page. Releases listed for the extension run through actionbook-extension-v1.1.9, with v1.1.7 and v1.1.6 before it.
The hosted endpoint is the adoption cost, not the licence
The repository is Apache-2.0, and the README points to a LICENSE file for details. That licence covers the code in the repository. It does not describe the hosted MCP endpoint, the dashboard, or the extension as distributed through the Chrome Web Store, and the README does not state whether any of those components are open source. For an engineer evaluating this, the practical question is not the licence text but the data path: every browser action your agent takes is brokered through edge.actionbook.app. The README says the extension connects to that endpoint automatically after sign-in, and says nothing about self-hosting, regional endpoints, or an offline mode. If your organisation requires an auditable internal data path, that silence is the deciding factor. Maintenance cost also sits outside your control: the extension ships on its own release cadence, and a Chrome Web Store update can change behaviour under a client you did not redeploy.
Where this is the wrong tool
Actionbook assumes a real Chrome with your sessions and a client that speaks MCP. If either assumption fails, the product does not degrade gracefully. A server-side agent with no browser, a CI job, or a scheduled crawler cannot use it. Neither can a team that needs deterministic replay, because the README's own framing is that manuals tell the agent what to do while the agent still decides what to do next. The README's brittleness argument applies to Actionbook too: it lists virtual DOMs, streaming components, and SPAs as things agents fail to understand, and the extension operates those same pages. Parallel tab operation is also a claim about architecture, not a guarantee about a given site's rate limits or session handling. And the manual index is curated, since the README links a request-a-website form, so coverage of any specific site is not something you can assume before checking.
Playwright drives a browser you own; Actionbook borrows one you are logged into
The closest familiar alternative is Playwright, or a comparable automation library, with a persistent browser profile. The difference is who holds the browser and the session. Playwright scripts run in your process against a browser you launch and configure, and you can store the profile, run headless in CI, and pin the version. Actionbook inverts that: it runs in the Chrome you already use, keeps the login state you already have, and moves orchestration to a hosted MCP endpoint that the agent talks to. Playwright asks you to write selectors and maintain them; Actionbook asks you to trust a remote service and a store-distributed extension. For a one-off script on a public site, Playwright is less machinery. For an agent that needs to be inside an authenticated session alongside the human, the extension model is the only one of the two that fits without exporting cookies.
What the README does not answer
Several questions a reviewer would normally settle are left open. There is no description of how action manuals are produced, reviewed, or invalidated when a target site changes its markup. There is no error model for a failed click or an expired session. There is no statement on what the extension can read from a page beyond what the agent asks for, or on retention of page content at the endpoint. There is no self-hosting path and no version compatibility matrix between extension releases and the MCP tool description, which matters because the README says the command set is discovered at connect time. The repository is Rust, but the README does not explain what the Rust code does relative to the extension and endpoint, so a reader cannot tell how much of the shipped product the public repository represents. Anyone evaluating Actionbook should get answers to the manual lifecycle and the data path before rolling it out beyond a single machine.
Editorial conclusion
Adopt Actionbook if your agents need to read pages that sit behind your own logins and you are willing to run a hosted MCP endpoint plus a Chrome extension rather than a headless browser you control. Do not adopt it if you need documented self-hosting, an auditable data path, or reproducible performance numbers, because the README supplies none of those. Verify first that your MCP client can register a custom connector, that your organisation permits the edge.actionbook.app endpoint, and that the extension's Chrome Web Store version matches the release tags you intend to track.
Community notes