Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

KitchenSink4Web

PYPI · KITCHENSINK4WEB · SCANNED SEP 21

Browser MCP server: budgeted page reads, honest unread accounting, structured extraction.

Available components

+20 this week 67 Trust /100
Trust breakdown (7 categories)

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
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 Management37
  • Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
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
Install

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

# add to Claude Code
claude mcp add nometalalchemist-kitchensink4web -- uvx kitchensink4web
// .cursor/mcp.json
{
  "mcpServers": {
    "nometalalchemist-kitchensink4web": {
      "command": "uvx",
      "args": [
        "kitchensink4web"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "nometalalchemist-kitchensink4web": {
      "command": "uvx",
      "args": [
        "kitchensink4web"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add nometalalchemist-kitchensink4web -- uvx kitchensink4web
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nometalalchemist-kitchensink4web": {
      "type": "local",
      "command": [
        "uvx",
        "kitchensink4web"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add nometalalchemist-kitchensink4web --command uvx --arg kitchensink4web
# ~/.hermes/config.yaml
mcp_servers:
  nometalalchemist-kitchensink4web:
    command: "uvx"
    args: ["kitchensink4web"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "nometalalchemist-kitchensink4web": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "kitchensink4web"
      ]
    }
  }
}
# add to Vellum
assistant mcp add nometalalchemist-kitchensink4web -t stdio -c uvx -a kitchensink4web
// mcp.json
{
  "mcpServers": {
    "nometalalchemist-kitchensink4web": {
      "command": "uvx",
      "args": [
        "kitchensink4web"
      ]
    }
  }
}
Changelog

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 +1
    • Tool safety: pass → unverified security
    • Stability: 0.30 → unverified security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • First check of Schema quality: unverified functional
    • Package version: 1.0.1 → 1.0.2 functional
  • 18 Sept 26 +4
    • Stability: unverified → 0.27 functional
  • 15 Sept 26 +15
    • Malware scan: unverified → pass security
  • 14 Sept 26 −15
    • Malware scan: pass → unverified security
  • 10 Sept 26 62

    First indexed and scored.

Diagnostics

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.2

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 →

MCP tools · 12 exposed · ~2,519 tokens

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 →

Tool Tokens
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.

NameTypeReqDescription
kindstring
limitinteger
location
pagestringyes
querystringyes
role

No output schema declared.

No examples provided.

get_audit ~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.

NameTypeReqDescription
limitinteger
session
start_indexinteger
tool

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
budget_tokensinteger
detailstring
location
modestring
pagestringyes
since
viewstring

No output schema declared.

No examples provided.

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 ~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.

NameTypeReqDescription
include_hiddenboolean
location
max_charsinteger
pagestringyes
start_indexinteger

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
topic

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
actionstring
auth_state
context
contextsinteger
device
expires_minutesinteger
lane
locale
note
op
path
reason
session
site
timezone
token
viewport

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
actionstring
context
page
sessionstringyes
url

No output schema declared.

No examples provided.

monitor ~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.

NameTypeReqDescription
actionstring
check_interval_minutesinteger
condition
label
monitor
selector
since
url
value

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
actionstring
page
timeout_msinteger
url
wait_untilstring

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
actionstring
amountinteger
location
pagestringyes
timeout_msinteger

No output schema declared.

No examples provided.

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.

NameTypeReqDescription
conditionstringyes
location
pagestringyes
timeout_msinteger
value

No output schema declared.

No examples provided.

Common questions

What is the KitchenSink4Web MCP server?

KitchenSink4Web is an MCP server listed in the public MCP registry as io.github.nometalalchemist/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 67 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.