Hive Web is a local MCP server that gives AI agents controlled web access through search, page extraction, and live browser automation — returning compact, structured data instead of raw HTML.
Static Web Tools (stateless)
Search the web (static_web_search): Query the web via a local SearXNG instance, returning normalized results.
Extract page content (static_web_extract): Render and extract content from any URL via local Firecrawl, returning markdown or other formats.
Retrieve stored artifacts (static_web_get_artifact): Fetch larger payloads previously saved by search or extraction tools using an artifact ID.
Action Web Tools (live Playwright browser sessions)
Create a browser session (action_web_session_create): Launch a live Playwright browser session (headless or visible) for interacting with dynamic sites and forms.
Navigate (action_web_navigate): Direct a live session to a URL or use a search query to find and navigate to the right page.
Take a snapshot (action_web_snapshot): Capture a compact snapshot of the current page showing visible text and interactive element refs (e.g. @1, @2) — not raw HTML.
Click elements (action_web_click): Click page elements by ref or CSS selector; sensitive targets (payment, password, 2FA, CAPTCHA) are blocked unless explicitly confirmed.
Type text (action_web_type): Fill text into input fields by ref or selector, with optional field clearing before typing.
Press keyboard keys (action_web_press): Send keyboard key presses (e.g. Enter, Escape, ArrowDown) to the live browser session.
Close a session (action_web_close): Terminate and clean up a live Playwright browser session.
Allows searching the web through a SearXNG instance, returning compact search results.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hive Web search for recent advancements in AI agents"
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.
Hive Web is a local MCP server for agents that need web access without flooding the model with raw pages. It gives Hermes, Claude Code, Codex, OpenCode, and other MCP clients a small set of tools for search, page extraction, and controlled browser sessions.
The server is built around two paths:
static-web cheap search and page extraction through SearXNG and Firecrawl
action-web live Playwright sessions with compact snapshots and safe actionsStatic tools handle normal research. Action tools are for sites that need a browser, forms, or navigation. Both return compact, structured data and store larger payloads as local artifacts.
The project is called Hive Web. The GitHub repository is hive-web.
The Python package and executable are named hive-web-runtime because they run the local MCP server. MCP clients usually register that server as hive_web.
GitHub repository hive-web
Python package hive-web-runtime
CLI command hive-web-runtime
MCP server name hive_web
Python module hive_web_runtimeRelated MCP server: Local-MCP-server
Static tools:
static_web_search(query, limit=5, max_tokens=2000)
static_web_extract(url, max_tokens=3000, format="markdown")
static_web_get_artifact(artifact_id, name?)
Browser tools:
action_web_session_create(name?, headless?)
action_web_navigate(session_id, url? | search_query?)
action_web_snapshot(session_id, max_tokens=1200)
action_web_click(session_id, ref? | selector?, confirm_sensitive=false)
action_web_type(session_id, text, ref? | selector?, clear=true)
action_web_press(session_id, key)
action_web_close(session_id)
Python 3.11+
Local or remote SearXNG endpoint
Local or remote Firecrawl endpoint
Playwright browsers for action-web sessions
Default endpoints:
SEARXNG_URL=http://localhost:8888
FIRECRAWL_API_URL=http://localhost:3002
HIVE_WEB_ARTIFACT_DIR=~/.cache/hive-web-runtime/artifacts
HIVE_WEB_SEARCH_ENGINES=bing,wikipedia,wikidata
HIVE_WEB_SEARCH_FALLBACK_ENGINES=bing
HIVE_WEB_REQUEST_TIMEOUT_SECONDS=45static_web_search pins SearXNG to reliable engines by default instead of letting blocked/CAPTCHA-heavy public engines silently return empty JSON. Override HIVE_WEB_SEARCH_ENGINES if your SearXNG instance has a better engine mix. Search responses include warnings from SearXNG unresponsive_engines, so CAPTCHA/rate-limit/backend failures are visible to the caller instead of looking like "the web has no results".
Action-web browser options:
HIVE_WEB_BROWSER_HEADLESS=false # default true
HIVE_WEB_BROWSER_CHANNEL=chrome # optional: use installed Google Chrome instead of bundled Chromium
HIVE_WEB_BROWSER_PROXY_URL_FILE=~/.config/hive-web-runtime/browser-proxy-url
HIVE_WEB_BROWSER_ARGS=--disable-blink-features=AutomationControlled
HIVE_WEB_BROWSER_LOCALE=ru-RU
HIVE_WEB_BROWSER_TIMEZONE=Europe/Moscow
HIVE_WEB_PAGE_TIMEOUT_MS=30000
# or HIVE_WEB_BROWSER_PROXY_URL=http://user:password@host:portPrefer HIVE_WEB_BROWSER_PROXY_URL_FILE for authenticated proxies so secrets stay out of MCP YAML config. The file should be user-readable only, for example mode 0600.
If you already run SearXNG and Firecrawl somewhere else, set those environment variables before starting the MCP server.
Hive Web is an MCP runtime, not a bundled search/scrape stack. Start SearXNG and Firecrawl first, then start or register the MCP server.
If you use the companion local Docker stack on macOS, the normal flow is:
cd ~/workspace/hermes/hermes-local-web-stack
./scripts/start.sh # docker compose up -d and endpoint checks
./scripts/status.sh # verifies SearXNG search and Firecrawl /v1/scrape
./scripts/ensure-running.sh # idempotent readiness/repair check used by autostartExpected healthy status:
SearXNG: 10 results
Firecrawl scrape: HTTP 200 ... markdown charsscripts/status.sh should check a real Firecrawl scrape, not just that port 3002 answers. A root HTTP 200 only proves the API process is listening; static_web_extract requires /v1/scrape to work.
For a generic setup, any SearXNG instance that serves JSON search and any Firecrawl-compatible API work:
export SEARXNG_URL=http://localhost:8888
export FIRECRAWL_API_URL=http://localhost:3002git clone https://github.com/YegorMy/hive-web.git
cd hive-web
uv run playwright install chromium
bash scripts/install-hermes-mcp.shThe installer runs uv sync, writes a hive_web entry into ~/.hermes/config.yaml, and tests the MCP connection. The Playwright install step is needed for action_web_* browser tools; static_web_* tools only need SearXNG and Firecrawl.
The installer also persists the search engine and timeout options shown above. If you set browser options such as HIVE_WEB_BROWSER_CHANNEL, HIVE_WEB_BROWSER_PROXY_URL_FILE, locale, timezone, or HIVE_WEB_BROWSER_ARGS before running it, those safe runtime options are copied into the Hermes MCP entry too. Secrets should stay in files or client secret stores, not in public examples.
After changing MCP config, reload MCP in your client or start a new session.
/reload-mcpManual server start, mostly useful for debugging:
uv run hive-web-runtimeThe server speaks MCP over stdio, so it waits for an MCP client.
With SearXNG and Firecrawl already healthy:
cd /path/to/hive-web
uv run pytest -q
hermes mcp test hive_web
uv run python scripts/test-mcp-client.py
uv run python scripts/smoke-action-web.pyscripts/test-mcp-client.py initializes the MCP server over stdio, lists tools, and calls static_web_extract against https://example.com. It fails if the MCP tool returns an error, so a green run means Firecrawl extraction actually worked.
Run the unit tests:
HIVE_WEB_ARTIFACT_DIR=/tmp/hive-web-runtime-artifacts uv run pytest -qRun a live MCP smoke test. This requires Firecrawl to be reachable at FIRECRAWL_API_URL:
uv run python scripts/test-mcp-client.pyFor live browser changes, also run:
uv run python scripts/smoke-action-web.pyIf you skipped the install script above, run it from the cloned repository:
bash scripts/install-hermes-mcp.shYou can override the server name and endpoints:
SERVER_NAME=hive_web \
SEARXNG_URL=http://localhost:8888 \
FIRECRAWL_API_URL=http://localhost:3002 \
bash scripts/install-hermes-mcp.shManual Hermes config:
mcp_servers:
hive_web:
command: /absolute/path/to/uv
args: ["run", "--project", "/absolute/path/to/hive-web", "hive-web-runtime"]
env:
SEARXNG_URL: "http://localhost:8888"
FIRECRAWL_API_URL: "http://localhost:3002"
HIVE_WEB_ARTIFACT_DIR: "/absolute/path/to/artifacts"
HIVE_WEB_SEARCH_ENGINES: "bing,wikipedia,wikidata"
HIVE_WEB_SEARCH_FALLBACK_ENGINES: "bing"
HIVE_WEB_REQUEST_TIMEOUT_SECONDS: "45"
HIVE_WEB_PAGE_TIMEOUT_MS: "30000"
connect_timeout: 60
enabled: trueAfter changing MCP config, reload MCP in the client or start a new session.
Claude Code:
claude mcp add -s user hive_web -- uv run --project /absolute/path/to/hive-web hive-web-runtimeCodex CLI:
codex mcp add hive_web -- uv run --project /absolute/path/to/hive-web hive-web-runtimeOpenCode uses the same stdio command in its MCP config:
{
"mcp": {
"hive_web": {
"command": "uv",
"args": ["run", "--project", "/absolute/path/to/hive-web", "hive-web-runtime"]
}
}
}Hive Web tries to keep browser automation boring and predictable:
Search and extraction return compact markdown or structured JSON, not full raw HTML by default.
Larger payloads go into the artifact store and can be fetched by artifact_id.
static_web_get_artifact picks the most useful artifact file automatically when name is omitted (content.md, snapshot.json, results.json, then raw.json).
Browser snapshots expose refs like @1 and @2 instead of dumping the full DOM.
action_web_click blocks payment, password, 2FA, and CAPTCHA-looking targets unless the caller explicitly confirms the action.
Static search and extraction use configurable request timeouts (HIVE_WEB_REQUEST_TIMEOUT_SECONDS).
Action-web navigation uses HIVE_WEB_PAGE_TIMEOUT_MS instead of waiting forever on stuck pages.
Duplicate named browser sessions are rejected instead of silently overwriting and leaking an old browser context.
Firecrawl error payloads are surfaced as explicit errors and their raw response is saved as an artifact for debugging.
Browser snapshots are trimmed to the requested token budget, including interactives, while the raw snapshot remains available in the artifact store.
This is not a CAPTCHA bypass tool, a shopping bot, or a payment automation layer. Treat it as read/search/extract plus careful browser control.
Hive Web does not mutate system routes or install routing helpers. For browser sessions that need a special exit path, configure an action-web browser proxy with HIVE_WEB_BROWSER_PROXY_URL_FILE or HIVE_WEB_BROWSER_PROXY_URL; static-web search/extract remains routed through its SearXNG/Firecrawl backends.
uv sync
HIVE_WEB_ARTIFACT_DIR=/tmp/hive-web-runtime-artifacts uv run pytest -q
uv run python scripts/test-mcp-client.py
uv run python scripts/smoke-action-web.pyUse a temporary artifact directory for tests if your normal cache directory is not writable in the current environment.
MIT
Click by snapshot ref or selector. Sensitive payment/password/2FA-looking targets require confirm_sensitive=true.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| selector | No | ||
| session_id | Yes | ||
| confirm_sensitive | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses one behavioral trait (sensitive target confirmation) but omits other important details like whether clicks wait for page load, error handling, or element visibility requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Every word serves a purpose, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema but the description does not explain return values. It covers core functionality but lacks detail on preconditions, error states, or post-click behavior. Adequate for a simple action but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies ref, selector, and confirms_sensitive but leaves session_id undocumented. This adds some meaning but is insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Click by snapshot ref or selector'. It also notes a specific use case for sensitive targets, distinguishing it from sibling tools like action_web_navigate or action_web_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives limited guidance: it explains when to set confirm_sensitive=true for sensitive targets. However, it does not explicitly state when to use this tool over siblings like action_web_press or action_web_click, nor does it provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a live Playwright browser session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'close', which indicates termination but does not disclose side effects, prerequisites (e.g., session must exist), error conditions, or resource cleanup. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized for a simple action, though it could add more value without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, low parameter coverage, and an output schema that is not referenced, the description is incomplete. It does not explain prerequisites, behavior upon invocation, or the context in which the tool is used, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the session_id parameter at all. It fails to explain its purpose, format, or how to obtain it, leaving the agent without necessary guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a live Playwright browser session' uses a specific verb ('close') and identifies the resource ('live Playwright browser session'). It clearly distinguishes from sibling tools like action_web_session_create (create) and action_web_navigate (navigate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to end a browser session, providing clear context. However, it lacks explicit exclusions or alternatives (e.g., when not to use it or what to use instead for other session-related operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key in the live browser session, e.g. Enter, Escape, ArrowDown.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is straightforward for a simple key press action, but lacks details on behavior such as whether key release is automatic or if special key combinations are supported. No annotations exist to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence that front-loads the action and examples, but it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no annotations, the description is minimally adequate but lacks important context about key value formats and the necessity of session_id, limiting its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no information about the parameters (key and session_id), leaving the agent without guidance on valid key values or the role of session_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses a keyboard key and provides specific examples (Enter, Escape, ArrowDown), distinguishing it from sibling tools like action_web_click and action_web_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pressing single keys but does not explicitly state when to use this tool versus alternatives like action_web_type for text input or action_web_click for mouse actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a live Playwright browser session for interactive sites/forms.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| headless | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It states 'live Playwright browser session' implying interactivity, but fails to mention whether the browser is visible, resource implications, or what happens after creation. The 'headless' parameter suggests configurability, but the description doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified. It sacrifices informativeness for brevity, making it less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool creates a session and has an output schema, the description is too minimal. It does not explain the session lifecycle, how it interacts with sibling tools like action_web_navigate, or what the output contains. The lack of context makes it insufficient for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no meaning to the parameters. It does not mention 'name' or 'headless' or explain their purpose, leaving the agent to infer entirely from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a live Playwright browser session', specifying the verb and resource. It also hints at the use case with 'for interactive sites/forms', which helps distinguish it from sibling tools like static_web_extract or navigation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or contrast with static tools that might be more appropriate for non-interactive sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a compact interactive snapshot: visible text and refs, not full HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| max_tokens | No | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output nature (visible text and refs) and what is excluded (full HTML), but does not mention side effects, session requirements, or performance characteristics. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, highly concise and front-loaded with the core action. Every word adds value, though it could be slightly expanded to cover parameters without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool in a web interaction suite. It does not explain how to integrate with other tools (e.g., navigate before snapshot), what 'interactive' means, or how the output schema provides return values. Parameter explanations are absent, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters (max_tokens and session_id). It neither explains the purpose of max_tokens (likely controlling output size) nor the need for session_id, leaving the agent to infer from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact interactive snapshot of visible text and refs, not full HTML. It uses specific verb 'return' and resource 'snapshot', and distinguishes from sibling tools like navigation or clicking by focusing on content extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus siblings. While it implies it should be used after navigation to extract page text, it lacks guidance on prerequisites or alternatives, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type/fill text into a snapshot ref or selector. Do not send passwords/secrets through this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| text | Yes | ||
| clear | No | ||
| selector | No | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only warns about passwords but does not mention error handling, typing speed, or what happens if the element is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the core purpose. Every word is useful, though a bit more detail would not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and parameter explanations, the description is incomplete. An output schema is present, so return values are covered, but usage context like element identification strategy is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal parameter meaning. It hints at 'ref' and 'selector' but does not explain them, nor does it cover 'clear', 'text', or 'session_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (type/fill text) and the target (snapshot ref or selector), which distinguishes it from sibling tools like 'action_web_click' and 'action_web_press'. However, it could more explicitly state it operates on web elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a security warning ('Do not send passwords/secrets'), which provides a when-not-to-use. However, it lacks explicit guidance on when to use this tool versus alternatives like 'action_web_press' for key presses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheap stateless page render/extract through local Firecrawl. Returns markdown plus artifact_id.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | markdown | |
| max_tokens | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It mentions 'stateless' and use of local Firecrawl, but fails to disclose important behaviors: what happens with dynamic pages, error handling, rate limits, or authentication needs. The description is too sparse for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. The first sentence front-loads the core action. However, it could be expanded slightly without losing conciseness to cover parameters and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces need to explain returns), the description omits critical context: how artifact_id relates to sibling static_web_get_artifact, what format options exist, and constraints on URLs. For a tool in a family, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no param descriptions in schema). The description adds no meaning to the three parameters (url, format, max_tokens). It only hints at markdown output but does not explain format options or the role of max_tokens. This leaves agents guessing about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Cheap stateless page render/extract' using local Firecrawl, and specifies what it returns ('markdown plus artifact_id'). This distinguishes it from sibling tools like static_web_search (search) and static_web_get_artifact (get by ID), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over alternatives. The description implies it's for quick, stateless extraction but does not contrast with interactive sibling tools (e.g., action_web_navigate) or other static_web tools. Agents lack context for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a local artifact previously created by static-web/action-web.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | content.md | |
| artifact_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral weight. It only states 'Read a local artifact' but does not disclose error behavior (e.g., missing artifact), idempotency, or whether it requires a specific session state. For a read-only tool, it lacks clarity on what happens in edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action. It wastes no words. However, it under-specifies important details, which slightly reduces the score from maximum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and an output schema exists, the description is incomplete. It does not explain what constitutes an 'artifact', how to obtain an artifact_id, or the relationship to the output. The agent cannot confidently use this tool without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters 'name' or 'artifact_id'. The default 'content.md' for name hints at a filename, but no explanation is given. The agent has no guidance on how to supply these values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a local artifact created by a specific action. The verb 'Read' and resource 'local artifact' are explicit. It distinguishes from siblings like action_web_click or static_web_extract by focusing on retrieval of a previously created artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., static_web_extract). It does not mention prerequisites or conditions for use. The agent has no context to decide between reading an artifact and extracting content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheap stateless web search through local SearXNG. Returns compact normalized results and an artifact_id.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| max_tokens | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses 'stateless' and 'cheap' but omits critical behaviors like rate limits, authentication needs, caching behavior, or error handling. The term 'compact normalized results' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loads the key information ('Cheap stateless web search'). Could be slightly improved by structuring parameter hints, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions 'artifact_id' but does not explain its purpose or how to use it (e.g., with sibling static_web_get_artifact). The output format is not described. For a tool with an output schema, the description is moderately complete but lacks clarity on return structure and usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the meaning or effect of any parameter (query, limit, max_tokens). The agent must infer from names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('web search'), the resource ('local SearXNG'), and the outcome ('compact normalized results and an artifact_id'). It effectively distinguishes from sibling tools like interactive browser actions (action_web_*) and extraction (static_web_extract).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick, stateless, non-interactive searches via 'Cheap stateless web search', hinting at when to use over interactive siblings. However, it lacks explicit guidance on when not to use or precise alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0action_web_clickaction_web_closeaction_web_navigateaction_web_pressaction_web_session_createaction_web_snapshotaction_web_typestatic_web_extractstatic_web_get_artifactstatic_web_searchScored across 10 tools
Tools are clearly split into 'action_web_' for live browser interactions and 'static_web_' for static operations. Each tool has a distinct purpose (click, navigate, snapshot, search, etc.) with no overlapping functionality.
All tool names follow a consistent 'category_action' pattern in snake_case, with prefixes indicating live vs. static operations. The naming is predictable and intuitive.
10 tools is a reasonable count for a web automation and scraping server. It covers essential operations without being overwhelming or sparse.
The tool set covers core workflows: navigation, clicking, typing, snapshotting, searching, and extraction. Minor gaps exist (e.g., no explicit wait or form element selection), but agents can work around them using snapshots and existing actions.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Scrape, crawl and search the web for AI agents via MCP.
