Which integrations are available for this server?

Allows connecting to the Kloakt CDP server using Puppeteer to control headless browser sessions programmatically.

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kloakt extract clean markdown from https://example.com" 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.

Kloakt

by KultMember6Banger

Overview Schema Source Related Servers Score Discussions Admin

Rust

Local

Kloakt is a headless browser built for AI agents. It runs JavaScript via V8, extracts clean markdown from any page (including SPAs), and exposes tools via MCP for Claude Code and other AI systems.

Beyond one-shot extraction it can drive persistent, stateful sessions (click, type, navigate — cookies and page/JS state persist across calls), emit an accessibility/structure snapshot as an agent-vision substitute, and capture real screenshots via system Chrome — 12 MCP tools in all.

Why Kloakt?

Metric	Kloakt	Headless Chrome
Memory	30 MB	200+ MB
Binary size	70 MB	300+ MB
Anti-detect	Built-in	None
Page load	85 ms	~500 ms
Startup	Instant	~2s
SPA extract	Yes	Manual

Install

Prebuilt binary (recommended)

One-line install (Linux & macOS). Downloads the right binary for your OS/arch from the latest GitHub Release and installs it to ~/.local/bin (or /usr/local/bin when run as root):

curl -fsSL https://raw.githubusercontent.com/KultMember6Banger/kloakt/main/install.sh | sh

You can pin a version or override the install dir:

KLOAKT_VERSION=v0.1.2 INSTALL_DIR=/usr/local/bin \
  sh -c "$(curl -fsSL https://raw.githubusercontent.com/KultMember6Banger/kloakt/main/install.sh)"

Windows: download kloakt-x86_64-windows.zip from the Releases page and extract kloakt.exe onto your PATH.

Homebrew (macOS)

brew install KultMember6Banger/kloakt/kloakt
# or, from a local checkout:
brew install --formula ./Formula/kloakt.rb

(Until a dedicated tap exists, brew tap KultMember6Banger/kloakt https://github.com/KultMember6Banger/kloakt then brew install kloakt.)

cargo install

Builds the CLI from crates.io (requires Rust toolchain; first build compiles V8, ~5 min):

cargo install obscura-cli

This installs the kloakt binary. To build with stealth mode, add --features stealth.

Build from source

git clone https://github.com/KultMember6Banger/kloakt.git
cd kloakt
cargo build --release

# With stealth mode (anti-detection + tracker blocking)
cargo build --release --features stealth

Requires Rust 1.75+ (rustup.rs). First build takes ~5 min (V8 compiles from source, cached after).

Related MCP server: zendriver-mcp

Quick Start

Extract content (AI agent use)

# Clean markdown from any page
kloakt extract https://example.com --main

# Structured JSON with metadata
kloakt extract https://example.com --main --json

# Cap output for agent context windows
kloakt extract https://en.wikipedia.org/wiki/Rust --main --json --max-chars 3000

# Wait for SPA hydration
kloakt extract https://example.com --delay 2000 --json

Fetch a page

# Get the page title
kloakt fetch https://example.com --eval "document.title"

# Extract all links
kloakt fetch https://example.com --dump links

# Render JavaScript and dump markdown
kloakt fetch https://news.ycombinator.com --dump markdown

# Wait for dynamic content
kloakt fetch https://example.com --wait-until networkidle0

Start the CDP server

kloakt serve --port 9222

# With stealth mode
kloakt serve --port 9222 --stealth

Scrape in parallel

kloakt scrape url1 url2 url3 ... \
  --concurrency 25 \
  --eval "document.querySelector('h1').textContent" \
  --format json

Snapshot page structure (agent vision)

# Indexed accessibility/structure tree — tags, text, roles, what's clickable, visibility
kloakt snapshot https://example.com

# Only the actionable elements (links, buttons, inputs), with id/name/label for targeting
kloakt snapshot https://example.com --interactive

kloakt has no rasterizer, so this is the lightweight "what's on the page and what can I act on" view for agents that work from structure rather than pixels.

Screenshot (via system Chrome)

# Real PNG — delegates to a locally-installed Chrome/Chromium/Edge
kloakt screenshot https://example.com --output shot.png --width 1280 --height 800

Persistent sessions

Drive a named session whose cookies and page/JS state survive across separate invocations, backed by a running kloakt serve daemon:

kloakt serve --port 9222 &                        # start the daemon once

kloakt session open shop --url https://example.com
kloakt session snapshot shop --interactive        # see the page structure
kloakt session type shop 'input[name=q]' 'hello'  # fill a field
kloakt session click shop 'button[type=submit]'   # click an element
kloakt session text shop                          # read the body text
kloakt session eval shop 'document.title'         # run JS, get the value back
kloakt session close shop                         # tear down (drops cookies + page)

Smart Extraction

The extract command uses a multi-phase pipeline optimized for AI agents:

Noise removal — strips cookie banners, ads, popups, nav, social widgets
Content scoring — text-density algorithm (Readability-like) finds the main content block
Markdown conversion — DOM-to-markdown with absolute URL resolution
SPA fallback — when JS rendering fails, extracts from meta tags, Open Graph, JSON-LD, and noscript content

Works on static HTML, server-rendered pages, and pure client-side SPAs (React, Vue, etc.).

Python API

from kloakt import (
    extract, extract_fields, fetch, scrape, search, crawl,
    snapshot, screenshot, session_open, session_close,
)

# Extract clean markdown
page = extract("https://example.com")
print(page.title, page.content, page.meta)

# Cap output length
page = extract("https://example.com", max_chars=3000)

# Wait for SPA content
page = extract("https://example.com", delay=2000)

# Structured field extraction via CSS selectors
data = extract_fields("https://news.ycombinator.com", {
    "title": "title",
    "stories": ".titleline > a[]",   # [] => list of all matches
    "links": ".titleline > a[]@href" # @href => an attribute
})
print(data["data"]["stories"])

# Raw fetch
html = fetch("https://example.com", dump="html")
title = fetch("https://example.com", eval_js="document.title")

# Parallel scrape
results = scrape(["https://a.com", "https://b.com"], concurrency=5)

# Discover links, or breadth-first crawl a small section of a site
links = search("https://news.ycombinator.com", same_domain=True)
pages = crawl("https://example.com", max_pages=5, max_depth=1)

# Structure snapshot (agent vision) and a real screenshot via system Chrome
snap = snapshot("https://example.com", interactive=True)
screenshot("https://example.com", output="shot.png")

# Persistent session — auto-starts a daemon if one isn't running; cookies + page
# state persist across calls. (session_nav / _click / _type / _eval / _text / _snapshot)
session_open("shop", url="https://example.com")
# ... drive the page across calls ...
session_close("shop")

MCP Server (Claude Code)

Kloakt includes an MCP server for use as a Claude Code tool:

{
  "mcpServers": {
    "kloakt": {
      "command": "python3",
      "args": ["/path/to/kloakt/mcp_server.py"]
    }
  }
}

Exposes 12 native tools:

Tool	What it does
`kloakt_extract`	Clean markdown, or structured fields via `schema`
`kloakt_fetch`	Low-level fetch (html/text/links/markdown, or JS eval)
`kloakt_scrape`	Many URLs in parallel
`kloakt_search`	Discover outbound links on a page
`kloakt_crawl`	Budget/depth-limited breadth-first crawl
`kloakt_snapshot`	Accessibility/structure tree (agent vision)
`kloakt_screenshot`	Real PNG via system Chrome
`kloakt_session_open`	Open a persistent named session
`kloakt_session_act`	navigate / click / type / eval within a session
`kloakt_session_read`	Read a session's page as text or snapshot
`kloakt_session_list`	List open sessions
`kloakt_session_close`	Close a session (drops its cookies + page)

Puppeteer / Playwright

Puppeteer

The CDP server embeds a per-session token in the WebSocket path (like Chrome). Connect via browserURL so the client discovers the token from /json/version automatically — don't hardcode the ws://.../devtools/browser path.

import puppeteer from 'puppeteer-core';

const browser = await puppeteer.connect({
  browserURL: 'http://127.0.0.1:9222', // discovers the tokenized ws endpoint
});

const page = await browser.newPage();
await page.goto('https://news.ycombinator.com');
const stories = await page.evaluate(() =>
  Array.from(document.querySelectorAll('.titleline > a'))
    .map(a => ({ title: a.textContent, url: a.href }))
);
await browser.disconnect();

Playwright

import { chromium } from 'playwright-core';

const browser = await chromium.connectOverCDP({
  endpointURL: 'http://127.0.0.1:9222', // discovers the tokenized ws endpoint
});

const page = await browser.newContext().then(ctx => ctx.newPage());
await page.goto('https://en.wikipedia.org/wiki/Web_scraping');
console.log(await page.title());
await browser.close();

Stealth Mode

Enable with --features stealth.

Per-session fingerprint randomization (GPU, screen, canvas, audio, battery)
Realistic navigator.userAgentData (Chrome 145, high-entropy values)
event.isTrusted = true for dispatched events
Native function masking (Function.prototype.toString() → [native code])
navigator.webdriver = undefined
Realistic Accept-Language + Client Hints (Sec-CH-UA) request headers
Per-session randomized navigator.languages
TLS fingerprint (JA3) rotation across Chrome 145 Linux / Windows / macOS profiles
3,520 tracker domains blocked

CLI Reference

`kloakt extract <URL>`

Flag	Default	Description
`--format`	`markdown`	Output: `markdown`, `text`, or `links`
`--main`	off	Strip nav, header, footer, sidebar
`--json`	off	Structured JSON: title, URL, content, meta
`--max-chars`	unlimited	Truncate content to N characters
`--delay`	`0`	Extra ms to wait after load
`--stealth`	off	Anti-detection mode
`--selector`	—	Wait for CSS selector
`--wait-until`	`load`	`load`, `domcontentloaded`, `networkidle0` (bounded by `--wait`)
`--schema`	—	Extract structured fields as JSON (see below)
`--har`	—	Write captured network activity to a HAR file
`--cache-ttl`	`0`	Cache the result on disk and reuse it for N seconds

Structured extraction with `--schema`

Pass a JSON object mapping field names to CSS selectors. Suffix a selector with [] to return all matches as a list, and with @attr to return an attribute instead of text:

kloakt extract https://news.ycombinator.com \
  --schema '{"title":"title","stories":".titleline > a[]","first_link":".titleline > a@href"}'
# => { "url": ..., "data": { "title": "...", "stories": [...], "first_link": "..." }, "elapsed_ms": ... }

This is also exposed through the MCP kloakt_extract tool via an optional schema argument.

`kloakt fetch <URL>`

Flag	Default	Description
`--dump`	`html`	Output: `html`, `text`, `links`, `markdown`
`--eval`	—	JavaScript expression to evaluate
`--wait-until`	`load`	Wait condition
`--selector`	—	Wait for CSS selector
`--stealth`	off	Anti-detection mode
`--quiet`	off	Suppress banner

`kloakt serve`

Flag	Default	Description
`--port`	`9222`	WebSocket port
`--proxy`	—	HTTP/SOCKS5 proxy URL
`--stealth`	off	Anti-detection + tracker blocking
`--workers`	`1`	Parallel workers

`kloakt scrape <URL...>`

Flag	Default	Description
`--concurrency`	`10`	Parallel workers
`--eval`	—	JS expression per page
`--format`	`json`	Output: `json` or `text`

`kloakt snapshot <URL>`

Emit an indexed accessibility/structure tree (always JSON) — an agent-vision substitute. Each node is compact: i (index), tag, depth, vis (visible), and when present click, role, text, type/value, href, id, name, label.

Flag	Default	Description
`--interactive`	off	Only actionable elements (links, buttons, inputs)
`--max-nodes`	`1500`	Cap on nodes emitted
`--stealth`	off	Anti-detection mode
`--delay`	`0`	Extra ms to wait after load
`--wait-until`	`load`	Wait condition

`kloakt screenshot <URL>`

Capture a real PNG by delegating to a locally-installed Chrome/Chromium/Edge (kloakt has no rasterizer). Errors clearly if none is found; override detection with --chrome <path> or the KLOAKT_CHROME env var.

Flag	Default	Description
`--output`	`screenshot.png`	Output PNG path
`--width`	`1280`	Viewport width
`--height`	`800`	Viewport height
`--chrome`	auto-detect	Path to a Chrome/Chromium/Edge binary

`kloakt session <COMMAND>`

Drive a persistent, named session against a running kloakt serve daemon. Cookies and page/JS state survive across separate invocations (client state in ~/.kloakt/sessions/<name>.json).

Command	Description
`open <name> [--url URL] [--port]`	Open (or reattach to) a session and create a page
`nav <name> <url>`	Navigate the session's page
`eval <name> <expr>`	Evaluate a JS expression, print the JSON value
`text <name>`	Print `document.body.innerText`
`snapshot <name> [--interactive]`	Structure snapshot of the session's page
`click <name> <selector>`	Click the first matching element
`type <name> <selector> <text>`	Focus an element, set its value, fire input/change
`list [--port]`	List open sessions on the daemon
`close <name>`	Close the session (drops its pages + cookies)

Multi-statement JS passed to eval returns null (the daemon evaluates a single expression); wrap it in an IIFE — (function(){ ...; return v })() — to get a value back.

`kloakt benchmark <URL...>`

Measure load performance per URL — average/min/max load time, request count, bytes, and DOM node count — as a table or --json.

kloakt benchmark https://example.com https://news.ycombinator.com --runs 3

Flag	Default	Description
`--runs`	`1`	Runs per URL (reports the average)
`--json`	off	Emit JSON instead of a table
`--wait-until`	`load`	`load`, `domcontentloaded`, or `networkidle0`

Challenge / bot-wall detection

kloakt extract --json includes a "challenge" field reporting a detected captcha or bot wall (recaptcha, hcaptcha, turnstile, cloudflare, datadome, perimeterx) or null. This is detection only — kloakt tells you a page is gated so an agent can stop and back off; it does not attempt to solve or evade challenges. (Also surfaced via the MCP kloakt_extract output and the Python Page.challenge field.)

Global flags

Flag	Default	Description
`--obey-robots`	off	Respect `robots.txt` — refuse to fetch disallowed paths
`--allow-private`	off	Allow private/internal/loopback hosts (disables the SSRF guard)

Security note: by default kloakt refuses to fetch private, loopback, link-local, and cloud-metadata addresses (SSRF protection), and rejects file:// URLs. Use --allow-private only when you intentionally need to reach internal services. The CDP server binds to 127.0.0.1 and validates the Host header to block DNS-rebinding.

CDP API

Full Chrome DevTools Protocol support for Puppeteer/Playwright compatibility.

Domain	Methods
Session	open, close, list — named, persistent browser contexts that keep cookies alive
Target	createTarget (`browserContextName` binds a page to a session), closeTarget, attachToTarget, createBrowserContext, disposeBrowserContext
Page	navigate, getFrameTree, addScriptToEvaluateOnNewDocument, lifecycleEvents
Runtime	evaluate, callFunctionOn, getProperties, addBinding
DOM	getDocument, querySelector, querySelectorAll, getOuterHTML, resolveNode
Network	enable, setCookies, getCookies, setExtraHTTPHeaders, setUserAgentOverride
Fetch	enable, continueRequest, fulfillRequest, failRequest
Storage	getCookies, setCookies, deleteCookies
Input	dispatchMouseEvent, dispatchKeyEvent

License

Apache 2.0 — Based on Obscura by h4ckf0r0day.

Available Tools

12 tools

kloakt_crawlA

Breadth-first crawl from a start URL, returning clean content for each page visited. Budget-limited (max_pages) and depth-limited (max_depth), stays on the start domain by default, with cycle detection. Use to gather a small section of a site in one call. Network-bound — keep max_pages modest.

ParametersJSON Schema

Name	Required	Description
`stealth`	No	Enable anti-detection mode
`max_chars`	No	Truncate each page's content to N chars (default: 2000)
`max_depth`	No	Max link-hops from the start URL (default: 2)
`max_pages`	No	Hard cap on pages to fetch (default: 10)
`start_url`	Yes	Where to begin crawling
`same_domain`	No	Restrict crawl to the start URL's host (default: true)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully bears the burden and covers key behaviors: breadth-first, budget-limited, depth-limited, same-domain default, cycle detection, and network-bound nature. However, it omits details on authentication, rate limits, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action and parameters, and contains no fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides sufficient context for an agent to understand the tool's purpose and constraints (max_pages, max_depth, same_domain, cycle detection). It mentions returning clean content but does not detail the output format or include error handling. Given the lack of output schema, a bit more detail on return structure could improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% description coverage for all parameters. The description adds value beyond the schema by mentioning 'cycle detection' and contextualizing 'budget-limited' and 'depth-limited,' which are not explicit in individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it's a breadth-first crawl from a start URL returning clean content, with budget/depth limits, domain restriction, and cycle detection. This clearly distinguishes it from sibling tools like kloakt_fetch (single page) or kloakt_scrape (page scraping).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using it 'to gather a small section of a site in one call' and warns it's 'network-bound — keep max_pages modest,' providing clear context. However, it does not explicitly state when not to use it or compare to specific alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_extractA

Extract clean markdown content from a web page using a headless browser with full JavaScript rendering. Strips nav/header/footer by default. Returns structured data: title, URL, markdown content, meta tags, timing. Use this instead of WebFetch when you need JS-rendered content or clean markdown.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to extract content from
`delay`	No	Extra milliseconds to wait after load for async content (default: 0)
`format`	No	Output format (default: markdown)	markdown
`schema`	No	Optional. Extract structured fields instead of markdown. An object mapping field name -> CSS selector. Suffix a selector with [] to return all matches as a list, and with @attr to return an attribute instead of text. e.g. {"title":"h1","prices":".price[]","links":"a[]@href"}. When given, returns {url, data:{...}, elapsed_ms}.
`stealth`	No	Enable anti-detection mode
`selector`	No	CSS selector to wait for before extracting
`main_only`	No	Strip nav/header/footer/sidebar (default: true)
`max_chars`	No	Truncate content to N characters (0 = unlimited, default: 0)
`wait_until`	No	When to consider page loaded (default: load)	load

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavioral traits like stripping nav/header/footer by default and returning structured data (title, URL, markdown, meta, timing). No annotations provided, so description carries the burden; it adequately covers key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two focused sentences that front-load the action and provide value without fluff. Slightly more detail on use case could be added without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no output schema, and no annotations, the description provides a clear overview and return structure, though it could mention edge cases or limitations of the schema parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage, so baseline is 3. Description adds some context (default stripping, return structure) but doesn't significantly enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool extracts clean markdown from a web page using a headless browser with JS rendering, and distinguishes from sibling tools (WebFetch) by specifying when to use it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using this tool over WebFetch when JS-rendered content or clean markdown is needed, providing good context for selection, but lacks explicit 'when not to use' for other siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_fetchA

Low-level page fetch with JS rendering. Returns raw output as string. Supports HTML dump, text dump, link extraction, or arbitrary JS evaluation.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to fetch
`dump`	No	Output format (default: text)	text
`eval_js`	No	JavaScript expression to evaluate on the page
`stealth`	No	Enable anti-detection mode

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description discloses JS rendering and raw string output, but does not address potential side effects of eval_js or stealth mode behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load purpose and cover key features without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main functionality and return format, but lacks details on eval_js output handling and stealth mode implications; adequate for a fetch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

100% schema coverage; description aligns with parameters but adds no meaningful new details beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'low-level page fetch with JS rendering' and lists supported output formats, distinguishing it from sibling tools like kloakt_extract or kloakt_scrape.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives; only implies it's for raw fetching without context from sibling descriptions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_scrapeA

Scrape many URLs in parallel with one call. Each URL is rendered with full JS, then returned as a result object. Far faster than calling kloakt_extract in a loop. Use when you already have a known list of pages to pull.

ParametersJSON Schema

Name	Required	Description
`urls`	Yes	List of URLs to scrape in parallel
`eval_js`	No	Optional JS expression evaluated on each page
`concurrency`	No	Max concurrent fetches (default: 10)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It mentions parallel rendering, JS execution, and concurrency default, but does not disclose whether the operation is read-only, idempotent, or any potential side effects. Adequate but lacks some depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the main action, no unnecessary words. Efficient and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description explains what the tool does, how it works (parallel, JS rendering), and when to use it. Could mention the return format more explicitly, but overall sufficient for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for all three parameters. The description does not add additional semantics beyond what the schema provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Scrape many URLs in parallel with one call' and mentions full JS rendering. It distinguishes itself from kloakt_extract by highlighting parallelism and speed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when you already have a known list of pages to pull' and compares to kloakt_extract, providing clear context for usage. Does not explicitly state when not to use, but the guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_screenshotA

Capture a real PNG screenshot of a page. kloakt has no rasterizer, so this delegates to a locally-installed Chrome/Chromium/Edge; it errors clearly if none is found. For structure without pixels, prefer kloakt_snapshot (always available).

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Page URL to screenshot
`width`	No	Viewport width (default: 1280)
`chrome`	No	Path to a Chrome/Chromium/Edge binary (overrides auto-detect)
`height`	No	Viewport height (default: 800)
`output`	No	Output PNG path (default: screenshot.png)	screenshot.png

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses that it delegates to a locally-installed browser and errors clearly if none is found, providing essential behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with main purpose, each sentence adding value: purpose, dependency/error handling, and alternative. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core behavior, dependency, and alternative. Could mention return value (PNG) but it's implied by 'screenshot' and output path. Valid URL handling assumed. Minor gap, but sufficient for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline of 3 applies. Description adds little beyond schema—only that Chrome parameter overrides auto-detect. No additional param details are needed given the schema richness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Capture a real PNG screenshot of a page') and explicitly distinguishes from sibling kloakt_snapshot by stating the latter is for structure without pixels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: 'For structure without pixels, prefer kloakt_snapshot (always available)' and mentions error behavior if Chrome is missing, helping the agent decide when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_searchA

Discover outbound links on a page. Renders the page, returns its anchors as absolute URLs paired with anchor text, optionally filtered by a query substring and/or restricted to the same domain. Use to find where to go next before extracting, e.g. locate article links on an index page.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Page URL to pull links from
`query`	No	Case-insensitive substring to filter links (matches URL or text)
`stealth`	No	Enable anti-detection mode
`max_links`	No	Max links to return (default: 50)
`same_domain`	No	Only return links on the page's own host (default: false)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description explains the rendering and filtering behavior, including query and same-domain restrictions. It does not mention error scenarios or rate limits, but the core behavior is transparent enough for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. The first sentence delivers the core action and output, the second provides usage guidance. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, output format (absolute URLs with anchor text), and filtering options. It lacks details on pagination or what happens if no links found, but for a simple discovery tool it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds contextual value by stating that filtering is optional and referencing 'query substring' and 'same domain,' but does not go beyond the schema's descriptions significantly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool discovers outbound links on a page, renders it, and returns absolute URLs with anchor text. It distinguishes from siblings like kloakt_extract by focusing on link discovery for navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use this tool to find where to go next before extracting, with an example of locating article links on an index page. This provides clear context and implies when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_session_actA

Act on a persistent session's page. One tool multiplexes four actions via action: 'navigate' (go to url), 'click' (click a CSS selector), 'type' (set an input's value) or 'eval' (run a JS expression). State persists, so this is how you drive a session opened with kloakt_session_open.

ParametersJSON Schema

Name	Required	Description
`url`	No	For action=navigate: the URL
`name`	Yes	Session name
`value`	No	For action=type: the text to set on the element
`action`	Yes	What to do
`selector`	No	For action=click/type: CSS selector of the target element
`expression`	No	For action=eval: the JS expression to evaluate

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses state persistence and four actions, but does not mention error behavior, timeouts, or session lifecycle details beyond 'State persists.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with key concept. Every word earns its place; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multiplexed tool with no output schema, description explains actions and parameter mapping adequately but omits return values or side effects (e.g., page content, confirmation). Leaves agent guessing about what the action returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with individual parameter descriptions. Description adds value by mapping each action to its relevant parameters (e.g., 'For action=navigate: the URL'), clarifying which parameters apply when.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it acts on a persistent session's page, multiplexes four actions. Distinguishes from sibling tools like session_open and session_read by being the driving tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states this is how you drive a session opened with kloakt_session_open, implying prerequisite. Could improve by noting when not to use (e.g., reading data via session_read), but context from sibling names provides differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_session_closeA

Close a persistent session, dropping its pages and cookies. Call this when you are done with a session opened by kloakt_session_open to free resources.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Session name to close

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses side effects: 'dropping its pages and cookies' and 'free resources.' No annotations provided, so description fully covers behavioral traits for a close operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no unnecessary words, front-loaded with main action and side effects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 1-parameter tool with no output schema, the description completely covers purpose, usage, and side effects. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter 'name' is described in the schema with 'Session name to close.' Description adds no further meaning, so baseline score of 3 applies due to 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool closes a session and drops its pages and cookies, differentiating it from sibling tools like kloakt_session_open (opens) and kloakt_session_list (lists).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this when you are done with a session opened by kloakt_session_open to free resources,' providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_session_listA

List the names of all open persistent sessions on the daemon.

ParametersJSON Schema

Name	Required	Description	Default
`port`	No	Daemon port (default: 9222)

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description implies a read-only listing operation, which is straightforward. However, it does not disclose any potential side effects, permissions required, or details about the output format. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence that is front-loaded with the key action and resource. Every word earns its place with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description adequately states what the tool does. It covers the essential information, though the output format (just names?) is implicit. Slightly above average given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as the single parameter 'port' is described in the schema with a default value. The description adds no additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'List', the resource 'names of all open persistent sessions', and the context 'on the daemon'. It effectively distinguishes from sibling tools like kloakt_session_open and kloakt_session_close.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives. The description only states what it does, not when it is appropriate or when to prefer other session tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_session_openA

Open (or reattach to) a persistent, named browser session. Unlike the stateless tools, a session keeps its cookies AND its page/JS/DOM state alive across separate calls, so you can log in once and keep driving the same page over many turns. A background daemon is auto-started if needed. Use this to begin a multi-step interaction; follow with kloakt_session_act / kloakt_session_read, and kloakt_session_close when done.

ParametersJSON Schema

Name	Required	Description
`url`	No	Optional URL to open the page at
`name`	Yes	Session name (your handle for it)
`port`	No	Daemon port (default: 9222)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden of disclosing behavior. It explains that the tool keeps cookies and JS/DOM state across calls and that a background daemon is auto-started. However, it could mention session timeout, resource usage, or error handling, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences), front-loaded with the purpose, and efficiently explains the tool's value and usage flow without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a tool with no output schema and full parameter schema coverage. It explains the tool's role in a multi-step workflow and how it relates to sibling tools. However, it does not describe the return value or output format, which could be clarified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds little beyond what is already in the schema. The description mentions 'name' as a handle and 'url' as optional, but does not provide additional semantics or usage tips for the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to open or reattach to a persistent, named browser session that retains state. It explicitly differentiates from stateless tools and mentions keeping cookies and DOM state, distinguishing it from siblings like kloakt_session_act and kloakt_session_read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance: 'Use this to begin a multi-step interaction; follow with kloakt_session_act / kloakt_session_read, and kloakt_session_close when done.' It contrasts with stateless tools but lacks explicit 'do not use' scenarios, which is acceptable given the context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_session_readA

Read the current state of a persistent session's page without changing it. mode='text' returns document.body.innerText; mode='snapshot' returns an indexed accessibility/structure tree (pass interactive=true for only the actionable elements). Use to observe what the page looks like now.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	What to read (default: text)	text
`name`	Yes	Session name
`interactive`	No	For mode=snapshot: only return actionable elements (default: false)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description explicitly says 'without changing it', indicating read-only. Details return values for each mode and the interactive option, adding behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with core purpose. Every sentence adds information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 3 simple params and no output schema; description explains return formats adequately. Could mention that the session must be open, but context from session tools implies it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema describes parameters with 100% coverage; description adds value by explaining what each mode returns (document.body.innerText vs accessibility tree) and how interactive filters for actionable elements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Read the current state of a persistent session's page without changing it', specifying the verb and resource. It distinguishes from siblings like kloakt_session_act and kloakt_screenshot by emphasizing read-only and non-modifying behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States 'Use to observe what the page looks like now', implying inspection context. No explicit exclusions or alternatives, but siblings cover other actions, providing implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

kloakt_snapshotA

Get an indexed accessibility/structure tree of a page — an agent-vision substitute when you can't see pixels. Returns compact nodes (index, tag, depth, visible, clickable, role, text, input type/value, href, label). Use to understand page layout and decide what to act on; pass interactive=true to get only the actionable elements (links, buttons, inputs).

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Page URL to snapshot
`delay`	No	Extra ms to wait after load for async content (default: 0)
`stealth`	No	Enable anti-detection mode
`max_nodes`	No	Cap on nodes emitted (default: 1500)
`interactive`	No	Only return actionable elements (default: false)

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses returning compact nodes with specific fields, and the behavior of the interactive flag. It does not mention side effects or auth, but as a read-only snapshot, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise, front-loaded sentences. Every word adds value—no filler or tautology. The structure immediately states the tool's core purpose, then details return fields and usage hints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description effectively covers the return format by listing fields. It positions the tool in the agent's workflow (vision substitute). However, it lacks details on error handling or page load limitations, keeping it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already documented. The description adds context like 'agent-vision substitute' and explains interactive returns 'only the actionable elements', enriching the schema. It partially repeats schema but adds meaningful usage guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets an 'indexed accessibility/structure tree of a page' as a 'vision substitute', using a specific verb and resource. It distinguishes itself from sibling tools like screenshot (visual) and scrape (raw content).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using it 'to understand page layout and decide what to act on', and explains the interactive flag for actionable elements. It implies usage when vision is unavailable, but lacks explicit when-not or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.1.2Jul 28, 2026
- First observedkloakt_crawl
- First observedkloakt_extract
- First observedkloakt_fetch
- First observedkloakt_scrape
- First observedkloakt_screenshot
- First observedkloakt_search
- First observedkloakt_session_act
- First observedkloakt_session_close
- First observedkloakt_session_list
- First observedkloakt_session_open
- First observedkloakt_session_read
- First observedkloakt_snapshot

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-28 13:45 across 12 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: extraction, low-level fetch, batch scrape, link discovery, crawl, accessibility tree, screenshot, and session management. No overlapping responsibilities.

Naming Consistency5/5

All tools follow the 'kloakt_' prefix with underscore-separated verb_noun pattern (e.g., kloakt_extract, kloakt_session_open). Session tools consistently use 'kloakt_session_<action>'.

Tool Count5/5

12 tools cover the domain of web scraping and session interaction without being excessive or too sparse. Each tool earns its place.

Completeness4/5

Covers major workflows: fetch, extract, scrape, crawl, snapshot, screenshot, and session management. Minor gaps like dedicated cookie or popup handling, but core operations are solid.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2
Aginx Browser A
net.aginx
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Browser Automation Agent Orchestration
31116
playwright-mcp-server A
com.thenextgennexus
Headless browser primitives for AI agents when sites need real JS rendering.
Browser Automation Web Scraping
175

Related MCP Servers

WebControl
Browser Automation Web Scraping
matanSht
F
license
Not graded
quality
C
maintenance
Headless browser automation for LLM agents via REST API or MCP tools. Enables navigating pages, reading structured content, clicking elements, filling forms, and executing JavaScript.
Updated 2 months ago (2026-07-15 09:27 UTC)
-
zendriver-mcp
Browser Automation Web Scraping Agent Orchestration
bituq
A
license
B
quality
C
maintenance
Provides undetectable browser automation for LLM agents via MCP, enabling real Chrome interaction with stealth features, DOM accessibility, and DevTools integration.
Updated 2 months ago (2026-07-22 13:43 UTC)
98
3
MIT
bwb-browser
Browser Automation Web Scraping
krshforever
A
license
B
quality
A
maintenance
A lightweight 30KB MCP browser automation server that uses raw Chrome DevTools Protocol to enable AI agents to browse the web, take screenshots, interact with elements, and capture live page events like console logs and network requests.
Updated a month ago (2026-08-06 18:22 UTC)
26
7
15
MIT
b4n1-webofficial
Browser Automation Web Scraping Autonomous Agents
B4N1-com
F
license
Not graded
quality
A
maintenance
Ultra-lightweight headless browser for AI agents. Provides MCP tools for navigating URLs, extracting structured content, and building autonomous agent workflows.
Updated 7 days ago (2026-09-03 13:50 UTC)
2
-

Why Kloakt?

Install

Prebuilt binary (recommended)

Homebrew (macOS)

cargo install

Build from source

Quick Start

Extract content (AI agent use)

Fetch a page

Start the CDP server

Scrape in parallel

Snapshot page structure (agent vision)

Screenshot (via system Chrome)

Persistent sessions

Smart Extraction

Python API

MCP Server (Claude Code)

Puppeteer / Playwright

Puppeteer

Playwright

Stealth Mode

CLI Reference

kloakt extract <URL>

Structured extraction with --schema

kloakt fetch <URL>

kloakt serve

kloakt scrape <URL...>

kloakt snapshot <URL>

kloakt screenshot <URL>

kloakt session <COMMAND>

kloakt benchmark <URL...>

Challenge / bot-wall detection

Global flags

CDP API

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

b4n1-webofficial

`kloakt extract <URL>`

Structured extraction with `--schema`

`kloakt fetch <URL>`

`kloakt serve`

`kloakt scrape <URL...>`

`kloakt snapshot <URL>`

`kloakt screenshot <URL>`

`kloakt session <COMMAND>`

`kloakt benchmark <URL...>`