KitchenSink4Web
PYPI · KITCHENSINK4WEB · SCANNED SEP 21
Browser MCP server: budgeted page reads, honest unread accounting, structured extraction.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 1 of 24 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 0 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability57
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 2659 tokens (~221/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage67
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
How do I install the KitchenSink4Web MCP server?
KitchenSink4Web runs locally as a PyPI package, launched with uvx kitchensink4web. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · kitchensink4web
claude mcp add kitchensink4ai-kitchensink4web -- uvx kitchensink4web
{
"mcpServers": {
"kitchensink4ai-kitchensink4web": {
"command": "uvx",
"args": [
"kitchensink4web"
]
}
}
} {
"servers": {
"kitchensink4ai-kitchensink4web": {
"command": "uvx",
"args": [
"kitchensink4web"
]
}
}
} codex mcp add kitchensink4ai-kitchensink4web -- uvx kitchensink4web
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"kitchensink4ai-kitchensink4web": {
"type": "local",
"command": [
"uvx",
"kitchensink4web"
],
"enabled": true
}
}
} openclaw mcp add kitchensink4ai-kitchensink4web --command uvx --arg kitchensink4web
mcp_servers:
kitchensink4ai-kitchensink4web:
command: "uvx"
args: ["kitchensink4web"] {
"McpServers": {
"kitchensink4ai-kitchensink4web": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"kitchensink4web"
]
}
}
} assistant mcp add kitchensink4ai-kitchensink4web -t stdio -c uvx -a kitchensink4web
{
"mcpServers": {
"kitchensink4ai-kitchensink4web": {
"command": "uvx",
"args": [
"kitchensink4web"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 62
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed pypi/kitchensink4web@1.0.3
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | setuptools.build_meta |
Background: Why install scripts are a supply-chain risk →
Dependencies 24 packages
| Packages resolved | 24 |
|---|---|
| Stale | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
find_elements Find Elements ~334
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.
| Name | Type | Req | Description |
|---|---|---|---|
| kind | string | – | – |
| limit | integer | – | – |
| location | – | – | – |
| page | string | yes | – |
| query | string | yes | – |
| role | – | – | – |
No output schema declared.
No examples provided.
get_audit Read the Action Log ~126
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| session | – | – | – |
| start_index | integer | – | – |
| tool | – | – | – |
No output schema declared.
No examples provided.
get_page_view Get Page View ~333
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.
| Name | Type | Req | Description |
|---|---|---|---|
| budget_tokens | integer | – | – |
| detail | string | – | – |
| location | – | – | – |
| mode | string | – | – |
| page | string | yes | – |
| since | – | – | – |
| view | string | – | – |
No output schema declared.
No examples provided.
get_server_info Get Server Info ~166
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_text Get Text ~244
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.
| Name | Type | Req | Description |
|---|---|---|---|
| include_hidden | boolean | – | – |
| location | – | – | – |
| max_chars | integer | – | – |
| page | string | yes | – |
| start_index | integer | – | – |
No output schema declared.
No examples provided.
get_workflows Get Workflows ~137
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.
| Name | Type | Req | Description |
|---|---|---|---|
| topic | – | – | – |
No output schema declared.
No examples provided.
manage_session Manage Session ~368
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | – |
| auth_state | – | – | – |
| context | – | – | – |
| contexts | integer | – | – |
| device | – | – | – |
| expires_minutes | integer | – | – |
| lane | – | – | – |
| locale | – | – | – |
| note | – | – | – |
| op | – | – | – |
| path | – | – | – |
| reason | – | – | – |
| session | – | – | – |
| site | – | – | – |
| timezone | – | – | – |
| token | – | – | – |
| viewport | – | – | – |
No output schema declared.
No examples provided.
manage_tabs Manage Tabs ~158
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | – |
| context | – | – | – |
| page | – | – | – |
| session | string | yes | – |
| url | – | – | – |
No output schema declared.
No examples provided.
monitor Watch a URL for Change ~187
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | – |
| check_interval_minutes | integer | – | – |
| condition | – | – | – |
| label | – | – | – |
| monitor | – | – | – |
| selector | – | – | – |
| since | – | – | – |
| url | – | – | – |
| value | – | – | – |
No output schema declared.
No examples provided.
navigate Navigate ~176
Go to a URL, or go back, forward, reload, or stop, and wait for the load state you name. Can be the FIRST call: with no `page`, navigate opens a browser session itself (bundled Chromium, headless) or uses the one already open, and returns the minted session and page handles. Returns the final identity after redirects, the HTTP status, a robots.txt advisory, and a verdict on whether the destination is a bot wall, a CAPTCHA interstitial, or a login wall, so a blocked request is reported as blocked instead of surfacing as a timeout or an empty page that invites a retry loop.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | – |
| page | – | – | – |
| timeout_ms | integer | – | – |
| url | – | – | – |
| wait_until | string | – | – |
No output schema declared.
No examples provided.
scroll Scroll ~128
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | – |
| amount | integer | – | – |
| location | – | – | – |
| page | string | yes | – |
| timeout_ms | integer | – | – |
No output schema declared.
No examples provided.
wait_for Wait For ~162
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 (the field's URL wait expired on a navigation that had finished before the call). 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.
| Name | Type | Req | Description |
|---|---|---|---|
| condition | string | yes | – |
| location | – | – | – |
| page | string | yes | – |
| timeout_ms | integer | – | – |
| value | – | – | – |
No output schema declared.
No examples provided.
What is the KitchenSink4Web MCP server?
KitchenSink4Web is an MCP server listed in the public MCP registry as io.github.KitchenSink4AI/kitchensink4web. Browser MCP server: budgeted page reads, honest unread accounting, structured extraction. This page covers its PyPI package (kitchensink4web).
Is the KitchenSink4Web MCP server safe to use?
KitchenSink4Web scores 62 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the KitchenSink4Web MCP server expose?
KitchenSink4Web exposes 12 tools: get_page_view, find_elements, get_text, navigate, scroll, and 7 more. Their descriptions and schemas cost roughly 2,519 tokens of context every time the server is loaded.
Is the KitchenSink4Web MCP server still maintained?
KitchenSink4Web is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.