KitchenSink4Web is a local-browser MCP server for AI assistants to read, extract, monitor, and optionally act on websites.
Read pages with get_page_view under a token budget, getting orientation, region costs, refs, completeness, and cheap delta reads via since.
Extract prose with get_text and locate elements by text, role, description, CSS, or XPath with find_elements.
Navigate, scroll, wait for conditions, manage tabs/sessions, load saved auth, use contexts, and hand off for login/MFA.
Monitor one URL for deterministic changes while the server runs, with reports and forced checks.
Audit actions (get_audit), read recipes (get_workflows), and inspect server capabilities (get_server_info).
Load optional packs for tables/lists/links/article extraction to CSV/JSON, screenshots/PDF, network inspection, saved sessions, file upload/download, JS diagnostics, workflow record/replay, and accessibility checks.
Safety defaults: acting disabled unless allowed; passwords redacted; hidden text labeled; consequential actions confirmed; bot walls/CAPTCHAs reported, not solved.
Drives an installed Firefox browser in a separate profile for reading pages, extracting content, and performing browser actions; the Firefox lane is recommended for research-heavy work because it passes bot checks that block automated Chromium.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KitchenSink4Web Navigate to example.com and extract the article text"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read websites and extract data with your AI assistant. Read-only by default, with clicking and typing only when you allow it.
KitchenSink4Web is an MCP server that lets Claude Code, the Codex CLI, Copilot CLI, Claude Desktop and other local MCP clients read web pages through a browser on your computer. It returns each page within a size budget you choose, says what it left unread, and exports tables to CSV or JSON. It starts read-only: clicking, typing and form filling exist only when you switch them on. This is the free Community edition, licensed under the AGPL-3.0.
Product page · llms.txt · Changelog
Platform: Windows, macOS and Linux. Reading text from images uses Windows OCR. The first run may download a browser and some optional dependencies.
The package needs Python 3.12 or newer. Run the commands below in PowerShell or a terminal, not in an AI chat.
Claude Code or Codex CLI. Install uv, run the line for your app, and start a new session:
claude mcp add web -s user -- uvx kitchensink4webcodex mcp add web -- uvx kitchensink4webClaude Desktop. Install uv and restart Claude Desktop. Download the .mcpb file from the latest release, then open Settings > Extensions > Advanced settings > Install extension and choose the file. The install screen lets you choose whether to allow clicking and typing, and which capability packs to load. The first launch downloads the Python package, so it needs a network connection.
Any other local MCP client. Use uvx as the command and kitchensink4web as its argument, or install the package and run kitchensink4web as the server command:
pip install kitchensink4webRelated MCP server: Charlotte
Read a page within a size budget and see what was left unread.
Open one section or find one element without fetching the whole page again.
Extract tables, lists and article text, and export them as CSV or JSON.
Take screenshots or save a page as PDF.
Read only what changed since your last read of a page.
Watch a page for changes while the server runs.
Click, type and fill in forms, once you allow it.
Record a multi-step browser task and replay it with checks.
Run automated accessibility checks (optional extra).
The read-only startup set has 12 tools, 20 with clicking and typing allowed, and 53 with every pack enabled.
get_page_view returns the shape of a page: what it is, what each section contains, what each section would cost to open, and a sensible next call. You set the budget and the read never exceeds it. Every read ends with a completeness block that names what was left out and what it would cost to get it. The budget ladder has 16 rungs.
From there, reading gets cheaper. Open one region instead of raising the budget. Pass the token a read returns, and the next read covers only what changed. Elements come back as short-lived references your assistant can act on, and searches by text and role keep working after the page re-renders.
Open shadow roots are read and can be acted on like the rest of the page, which makes component-based sites readable. Closed shadow roots cannot be reached by any tool, so they are counted and reported. Same-origin iframes are read and searched like the page around them, each labeled with its origin; cross-origin frames are named but never entered.
An example. A raw dump of the Treaty of Versailles article on Wikipedia costs 33,073 tokens. The first read through get_page_view costs 4,445, and a delta read after one click costs 82.
The server starts with reading, navigation and session management. Packs are chosen at launch and stay fixed for the session, so a pack you did not load is absent, not just switched off.
Pack | What you get |
extract | Tables, lists, links and article text, with CSV and JSON export. |
capture | Screenshots (with password fields blurred), PDF export, and saving pages as files. |
network | The requests a page makes behind the scenes. Useful for debugging websites; most people leave it off. |
storage | Saves a signed-in session so your assistant does not have to log in each time. It saves the session, never your password, but treat the saved file like a password anyway. |
files | Downloads into one folder and uploads into page forms. Each one asks you first. |
diagnostics | Lets your assistant run JavaScript on a page, one script at a time, each shown to you for approval first. This is the most powerful setting here. Leave it off unless you need it. |
workflows | Record a multi-step task once and replay it later. Each replay checks that the page still matches before anything runs. |
accessibility | Checks a page against the WCAG rules with axe-core, groups the findings by rule, and says plainly what automated testing cannot check. Needs an optional extra; the tool explains how to install it. |
Tool definitions cost about 4.1k tokens for the read-only startup set, 6.9k with clicking and typing allowed, and 17.9k with every pack.
By default the server drives its own bundled Chromium. It never touches your browser or your profile: each session starts in a fresh profile that is deleted on close, unless you explicitly save signed-in state to a file.
You can also choose a browser you already have installed (Chrome, Edge or Firefox). It still runs with its own separate profile, never yours. Some sites respond differently to different browsers, and manage_session(action='status') reports which browsers are installed and which one it recommends for the current page. It never switches for you. The server does not disguise what it is, and it reports bot checks and CAPTCHAs rather than trying to solve them.
Signed-in sessions are saved with save_auth_state and reloaded with auth_state= when you open a session. The saved file records when its cookies expire, and loading an expired one says so instead of letting the login fail without explanation.
A browser holds your logins and your accounts, so safety is built into how the tools are offered.
Read-only unless you choose otherwise. By default, the tools that click, type and submit are not in the tool list at all, so no instruction on a web page can lead your assistant to use them. One setting at install (allow acting in the Claude Desktop bundle, KS4WEB_ALLOW_ACTING=true elsewhere) adds them.
Passwords stay out of the conversation. The server never reads what is typed into password fields. Secrets found in cookies and site storage are redacted before any text leaves the server.
Hidden text is treated as evidence, not instructions. Text a page hides from people is a common way to slip instructions to an AI. The server removes it from what your assistant reads, reports how much it removed, and labels everything a page says with where it came from.
Confirmation for consequential actions. Form submissions, payments and page scripts stop and ask you first, through your client's own confirmation prompt, and go ahead only when you choose Allow. An empty or automatic answer counts as no. Clients that cannot show the prompt refuse those actions instead of going ahead. The only exceptions are routine actions you have approved in advance through the consent scope, KS4WEB_PREAUTH, or the optional 30-minute Remember box.
Refusals that explain themselves. When something cannot be done, whether a login wall, a bot check or a page that crashed, the answer names what stood in the way and what to try next.
Your MCP client's own prompt names a tool (for example mcp__web__type_text). Approving the read-only tools there is safe and removes most prompts. A KitchenSink4Web confirmation describes the action itself ("submitting this form sends a password") and cannot be pre-approved for payments, credentials, posts, deletions or legal agreements.
The default scope is research: reading and navigation are free, search-style submissions (a search box) go ahead, and everything else asks first. The full scope lets ordinary form submissions go ahead without asking. Payments, credentials, posts, deletions and legal agreements ask under every scope.
Under full, a submit button whose wording the server does not recognize in any supported language is not gated. If that matters to you, stay on research.
Client | What works |
Claude Desktop | Everything, with confirmations shown. |
Claude Code | Everything, with confirmations shown. |
claude.ai web | Reading, navigation and search. Actions that need confirmation are refused with |
The server runs on your computer. KitchenSink4AI never receives your files, pages or usage data. The browser connects to the websites you ask it to use, and those sites see ordinary browsing requests. Your AI app may send prompts, page contents and tool results to its own provider under that app's settings and terms. A missing tokenizer table may be downloaded once; the text being measured is never sent. The optional update check contacts PyPI and sends nothing beyond the request itself. The Privacy Policy covers the product, purchases and support.
Packs and read-only mode are chosen at launch with --packs, KS4WEB_MODE and KS4WEB_ALLOW_ACTING, and apply to every connection to the running server.
Update check. The server compares its version with PyPI only when you call manage_session(action='status'), never at startup or in the background, at most once every seven days, with a two-second timeout. The request sends no identifier, usage data, page content or session state, and the server never installs anything. KS4WEB_UPDATE_CHECK=off turns it off (KS4WEB_NO_UPDATE_CHECK=1 also works).
Fewer permission prompts: in Claude Desktop's tool permissions for this server, set the read-only tools to Always Allow. They cannot change anything on any page.
Subagents: tool results are capped more tightly inside a subagent, so start reads there at budget_tokens=2500.
Cross-origin iframes are never entered; the completeness block names each one.
Closed shadow roots cannot be reached by any tool. They are counted, so you can tell a component-heavy page from an empty one.
Bot walls and CAPTCHAs are reported, never solved or evaded.
sendBeacon and ping requests bypass network routing rules, a limit of the underlying Playwright library.
Accessibility checks find a minority of real-world issues. Deque, who build the axe-core engine, publish 57% as the share of issues their own automated tooling finds. A clean report means the automated checks passed, not that the page is accessible, and there is deliberately no score.
Monitors run only while the server runs. MCP clients do not yet deliver messages a server starts, so you ask the monitor report what happened. A monitor watches one URL for one defined change, checks no more often than every five minutes, cannot get past a login or bot wall, and pauses itself if it keeps failing. content_hash is noisy on pages with clocks or counters, and a change that appears and reverts between checks is not seen. Everything stays on your machine.
Session handoff works within one running server. A handle moves a live session to another conversation in the same running KitchenSink4Web. It is the same browser, so references from before may be stale, and the report says which. Handles work once, expire in an hour, and do not survive a restart.
Each extra identity is another browser process and profile, so it uses real memory. The action budget is shared across identities, so a second identity does not double what a session may do.
The browser choice list records which sites this computer visited with which browser (host names and dates only, nothing typed, no page content) so a site that refused one browser can be read with another. It stays on this machine, learning can be turned off, and one call erases it.
The suite has more than 2,000 tests, about 700 of which drive a real browser. Tests that need saved pages use small synthetic fixtures. Each release also re-runs regression tests for prompt injection through page content, hidden-text smuggling, credential theft, confirmation bypasses, workflow replay tampering and resource abuse.
Please open an issue with the page (if it is public), what you asked for and what happened. The output of manage_session(action='status') is designed to be safe to share. For security issues, follow SECURITY.md.
The Business edition pairs these tools with a Windows installer, a signed update channel and support under the Business terms. Update checks tell you when a covered release is available, and nothing installs on its own. See pricing. The Community edition stays free under the AGPL, including business use that meets its terms.
Bug reports, fixes, tests and documentation are welcome. See CONTRIBUTING.md; first-time contributors agree to the Contributor License Agreement.
KitchenSink4Web is dual-licensed.
AGPL-3.0. Free for anyone, including businesses, for any use that complies with the AGPL. Its terms include sharing your source code, with your modifications, when you distribute the software or make it available over a network.
Commercial license. For organizations that want to build KitchenSink4Web into their own products or services without the AGPL's source-sharing obligations. Contact licensing@kitchensink4.ai.
Copyright (c) 2026 Alvut Consulting, LLC. KitchenSink4AI is a product line of Alvut Consulting, LLC. KitchenSink4AI tools are built with the help of AI coding assistants, and every release goes through the full test suite before it ships.
Not affiliated with or endorsed by Google, Mozilla, Microsoft, or any website this server visits. Chrome, Chromium, Firefox and Edge are trademarks of their respective owners, named only to identify the browsers this server can drive.
Find elements by text, role plus accessible name, natural-language
description, CSS, or XPath, and get back refs you can act on plus a note
on what was not searched. role='button' narrows any query to one
element role (field finding: 'Comment' alone matched 12; with the role
filter it matches the one button). This is the cheap targeted follow-up
that pairs with get_page_view: the page view tells you what string to
look for, and this retrieves it for a fraction of a full read.
Ambiguous results are listed rather than resolved, and zero results
come back with the nearest misses so a miss is a one-turn recovery.
The search covers the main document and every open shadow root in it,
and the matches it returns from a shadow root are actable like any
Same-origin iframes are searched too and the result says which ones
it entered. Two things stay out and the result counts both:
cross-origin iframes, which no tool here opens, and closed shadow
roots, which no tool can reach. XPath is the one kind that does not
enter a shadow root. location={'region': 'r7'} (or a ref, form, or table
from a read) narrows the search to that subtree, components inside it
included, and the first result line names the scope that was searched.
Inputs: page (required), query (required), kind, role, +2 more.
Read the action log. Returns one record per call, paginated, carrying the timestamp, lane, page, URL, resolved target with its human label, redacted arguments, outcome, any rebind, any confirmation decision, and the budget counters at that moment. This is an operational record for the user, so you can always know exactly what was done even where a web action cannot be undone. It is not forensic and not evidence.
Inputs: tool, limit, session, start_index.
Read a page as an ORIENTATION, not a transcript, under a token budget
it never exceeds whatever the page size. Returns identity, landmark
regions each priced with the cost to expand it, the interactive surface
with refs you can act on, a digest or app skeleton, form and table
inventories, an account of what was NOT read and why, and the next call
for anything unexpanded. location scopes to one region ref,
budget_tokens=2500 suits a subagent, mode='links' includes in-prose
links at their real cost. since=<read_token> is the cheap repeat
read: only what changed, refs kept, a few hundred tokens instead of a
fresh read, and it falls back to a full read when the page navigated in
between and nothing survives to diff. Open shadow roots are read and
their contents get refs you can act on; closed roots cannot be reached
by any tool and are counted at creation, so the completeness block
reports both numbers rather than one confident zero. Same-origin
iframes are entered and read, and their contents get refs naming the
frame they came from; a cross-origin frame is never entered, because
its document belongs to an origin the page itself cannot read either,
and the completeness block counts every frame it did not open.
Inputs: page (required), mode, view, since, +3 more.
Report what this server is and what it is running: the product and PyPI package names, the version a client was handed at initialize, the homepage and repository, the sibling servers in the same suite, the tool surface registered in THIS process (how many tools, how many of them are the lite core, which capability packs are loaded and which exist, and the read-only grade and consent scope in force), the test figures measured for this release, and the host Python and platform. Counts come from the live registry, so they describe the process you are connected to rather than the product in general. Needs no browser, opens no page, and reveals no path or user name, so a bug report can carry the output as it stands.
Inputs: no named parameters.
Extract readable prose from a page or one region of it, paginated by
start_index so a long article is read in bounded pieces rather than
one unbounded dump. Text arrives as labeled data with its origin stated,
and hidden regions are stripped and counted rather than silently dropped
or silently included. Hidden content IS retrievable, deliberately:
include_hidden=true returns it in a separately labeled section with the
hiding technique named per block. There is no silent middle tier,
because display:none is a real injection channel; the labeled route is
the whole design. Prose inside open shadow roots is read, the same as
get_page_view reads it; closed roots are counted and stay unreadable.
Prose inside same-origin iframes is read after the main document, each
frame under a header naming it and its origin, because one page can
now deliver text from several documents and a single origin in the
label would be a claim about only one of them.
Inputs: page (required), location, max_chars, start_index, +1 more.
Get recipes for this server: the cheap-read-then-act pattern, the auth workflow (headed handoff plus saved state), reading strategy, budgeting, troubleshooting a page that will not read, the subagent budget setting, lanes, what each capability pack contains with the exact launch flag that loads it, what a site profile is and where it lives, and how to record and replay a multi-step flow. Packs are chosen at launch rather than at runtime, so this is where you learn which flag you need before restarting. Tool availability reflects the packs this server was started with.
Inputs: topic.
One session is one browser. open starts one on a chosen lane (the
first navigate of a conversation can open one for you, and says so when
it does); close ends the browser; with auth state saved, the login
survives; the session never does. status reads liveness first, so a
dead browser says so, then lists every session this server holds with its
pages, budgets, and what is shared: sessions belong to the server
process, not to a conversation. capabilities, budget, and
reset_budgets report and manage limits. handoff hands the window to
the human for a login, an MFA prompt, or a bot wall. export_handle and
import_handle move a live session between conversations on this
machine: see get_workflows(task='session-transfer'). lanes is the
local lane database (status, export, import, erase). profiles reloads
site profiles from disk. On open, auth_state loads a saved login,
contexts=2 gives one session two independent cookie jars, and device,
viewport, locale, and timezone set what pages in this session
believe about their environment.
Inputs: op, lane, note, path, +13 more.
List, open, select, or close tabs, report which is focused, and
capture pages a click opened in a popup. Mints and returns the explicit
page handles every other tool accepts, which is how browser state
survives across calls without relying on protocol sessions. Closing a
page invalidates its refs and its delta read tokens, and the result says
so rather than leaving a later failure to explain it. On a session with
more than one cookie jar, context says which jar a new tab opens in
and every listed page says which jar it belongs to.
Inputs: session (required), url, page, action, +1 more.
Watches one URL for one deterministic change while this server runs. Four conditions: content_hash, text_appears, text_gone, selector_count; the same page state always answers the same way. Nothing is pushed anywhere: report is how you ask what happened, and check_now forces a check. A monitor that could not check reports stale with the failure, never unchanged. Checks run in a dedicated headless session, never the caller's. There is a floor on the interval and caps on monitors and daily checks; a 429 is honored rather than retried; a monitor that keeps failing pauses itself.
Inputs: url, label, since, value, +5 more.
Scroll by an amount, to a named element, to the end, or inside a specific container, plus a next-chunk mode that remembers position across calls so a long page is walked without re-reading it. Reports how much content is now reachable and how much remains below, and names virtualized containers where the DOM holds far fewer rows than the page claims, rather than presenting a partial list as complete.
Inputs: page (required), action, amount, location, +1 more.
Wait for text to appear or disappear, an element to reach a state, a URL
to match, or a JS predicate to hold. EVERY condition is checked against the
current state first and returns immediately when it already holds, so a
wait issued after the thing already happened costs nothing instead of
timing out (a URL wait could otherwise expire on a navigation that had
already finished). A url value without wildcards matches as a substring;
use * and ? for globbing. Real timeouts, and a failure that says what was
awaited and what was observed instead.
Inputs: page (required), condition (required), value, location, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 12 tools
Most tools target clearly distinct operations (navigate, scroll, wait_for, monitor, manage_tabs, manage_session, get_audit, get_server_info, get_workflows), and the reading tools (get_page_view, find_elements, get_text) are carefully differentiated by purpose. However, get_page_view/find_elements/get_text all touch page content and could be confused by a less careful agent, with the descriptions doing the heavy lifting to separate them.
Nearly all names are snake_case and follow a verb_noun pattern (manage_tabs, get_audit, get_page_view, find_elements, get_text, manage_session, get_workflows, get_server_info). A few devolve to bare verbs (navigate, scroll, monitor) or a non-verb (wait_for), but the convention is predictable overall.
Twelve tools is well-scoped for a browser-automation server: navigation, reading, search, tab/session management, monitoring, waiting, and meta tools each earn a distinct place. No padding or obvious redundancy.
The surface covers navigation, reading, searching, tab/session lifecycle, monitoring, and meta info well, but it repeatedly promises 'refs you can act on' with no click, type/fill, screenshot, or evaluate/JS tool present. For a web-interaction server, missing the action primitives is a notable gap that would create dead ends.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.
Hosted browser for agents: open pages, search the web, extract data, read PDFs and take screenshots.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Web data for agents. Extract web pages, crawl websites, discover URLs, and search the web.
