servo-fetch is a self-contained browser engine server (powered by Servo) offering a suite of tools for fetching, crawling, and interacting with web pages via MCP or HTTP API. It leverages real JavaScript execution and CSS layout without requiring Chromium or an API key. Key capabilities:
Fetch: Retrieve content from a single URL as Markdown, JSON, HTML, plain text, or accessibility tree, with support for CSS selector extraction, pagination (start_index), settle time for SPAs, and timeouts.
Batch Fetch: Submit up to 20 URLs in parallel, returning results in completion order with per-URL options, inline failure reporting, and Markdown/JSON output.
Crawl: Perform a BFS crawl of a website (up to 500 pages, depth 10), respecting robots.txt, with include/exclude URL glob patterns and full JavaScript execution/CSS layout for accurate content extraction.
Map: Quickly discover site URLs via sitemaps and link extraction without rendering, supporting up to 100,000 URLs, robots.txt compliance, and glob filtering.
Execute JavaScript: Evaluate a JavaScript expression on a loaded page and obtain the result alongside console messages.
Screenshot: Capture viewport or full-page PNG screenshots using a software renderer (no GPU required).
Advanced features include automatic boilerplate removal (navbars, sidebars, footers, cookie banners, modals, hidden elements) and security measures such as blocking private IPs, stripping URL credentials, disabling redirects, and output sanitization.
servo-fetch embeds the Servo browser engine. It executes JavaScript, computes CSS layout, captures screenshots with a software renderer, and extracts clean content — available as a CLI, a Rust library, a Python SDK, and a Node.js SDK.
# CLI
servo-fetch "https://example.com" # clean Markdown
servo-fetch "https://example.com" --format png -o page.png # PNG screenshot// Rust
let md = servo_fetch::markdown("https://example.com").await?;# Python
page = servo_fetch.fetch("https://example.com")
print(page.markdown)// Node.js
import { fetch } from "servo-fetch";
const md = await fetch("https://example.com");Zero dependencies — single binary, no Chromium, no API key
Real JS execution — SpiderMonkey runs JavaScript, parallel CSS engine computes layout
Layout- and visibility-aware extraction — strips navbars, sidebars, footers by rendered position, plus cookie banners, modals, and CSS-hidden content (opacity:0, aria-hidden, sr-only)
Schema-driven JSON — declarative CSS-selector schema pulls structured data
Parallel batch fetch — multiple URLs fetched concurrently
Isolated browser sessions — one-use worker process per session keeps cookies and storage fully separated
Site crawling — BFS link traversal with robots.txt, same-site scope, and rate limiting
URL discovery — sitemap-based URL mapping without rendering (fast, lightweight)
Screenshots without GPU — software renderer captures PNG/full-page screenshots anywhere
Accessibility tree — AccessKit integration with roles, names, and bounding boxes
Agent-ready — drop-in web tool for AI agents: a built-in MCP server, or wrap the Python API as a tool in any agent framework
Related MCP server: markdown-for-agents-mcp
Apple M3 Pro, versus Playwright (the typical AI-agent stack):
Benchmark | servo-fetch | playwright:optimized |
Time — static-small | ~231 ms | ~645 ms |
Time — spa-heavy | ~331 ms | ~798 ms |
Memory (peak RSS) | 51–64 MB | 300–328 MB |
Extraction quality: mean word-F1 0.819 vs Readability's 0.728 across
eight page-type fixtures, with without[] boilerplate removal at 95.0%
vs 78.6%. Direct-binary engine peers (chrome-headless-shell, Lightpanda,
curl) are opt-in.
Methodology, three-axis breakdown, per-fixture F1, and raw JSON:
benchmarks/README.md +
benchmarks/results/.
Interface | Install | Docs |
CLI |
| |
Rust |
| |
Python |
| |
Node.js |
|
cargo binstall servo-fetch-cli # prebuilt binary
cargo install servo-fetch-cli # build from sourceOr download from GitHub Releases.
Linux — install runtime deps and use xvfb-run on headless servers:
sudo apt install -y libegl1 libfontconfig1 libfreetype6
xvfb-run --auto-servernum servo-fetch "https://example.com"Windows — cargo binstall does not copy sidecar files (cargo-binstall#353), so the installed servo-fetch.exe fails at startup with a missing libEGL.dll. Download the .zip from Releases instead — it bundles libEGL.dll and libGLESv2.dll.
macOS — no extra setup needed.
servo-fetch "https://example.com" # Markdown (default)
servo-fetch "https://example.com" --format json # Structured JSON
servo-fetch "https://example.com" --format png -o page.png # PNG screenshot
servo-fetch "https://example.com" --js "document.title" # Run JavaScript
servo-fetch "https://example.com" --schema schema.json # Schema-driven JSON
servo-fetch "https://example.com" --cookies cookies.txt # Send session cookies
servo-fetch "https://example.com" -H "X-Api-Key: KEY" # Custom request header
servo-fetch URL1 URL2 URL3 # Parallel batch
servo-fetch "https://example.com" --output page.md # Save to a single file
servo-fetch URL1 URL2 --output-dir ./out/ # Save each URL to its own file
servo-fetch crawl "https://docs.example.com" --limit 20 # Crawl a site
servo-fetch crawl URL --output-dir ./pages/ # Save each crawled page to its own file
servo-fetch map "https://example.com" # Discover URLs via sitemap
servo-fetch mcp # MCP server (stdio)
servo-fetch serve # HTTP API serverFull CLI reference → servo-fetch-cli
cargo add servo-fetch// URL → Markdown in one line (async by default; use `blocking::*` for sync)
let md = servo_fetch::markdown("https://example.com").await?;
// Fetch with options
use servo_fetch::{fetch, FetchOptions};
use std::time::Duration;
let page = fetch(&FetchOptions::new("https://example.com").timeout(Duration::from_secs(60))).await?;
println!("{}", page.html);
let md = page.markdown()?;
// Crawl a site
servo_fetch::crawl_each(
&servo_fetch::CrawlOptions::new("https://docs.example.com")
.limit(100)
.user_agent("MyBot/1.0"),
|result| match &result.outcome {
Ok(page) => println!("{}: {} chars", result.url, page.content.len()),
Err(e) => eprintln!("{}: {e}", result.url),
},
).await?;
// Discover URLs via sitemap (no rendering)
let urls = servo_fetch::map(
&servo_fetch::MapOptions::new("https://example.com").limit(1000),
).await?;
for u in &urls {
println!("{}", u.url);
}Full API reference → servo-fetch
Requires Python 3.11 or later.
pip install servo-fetchimport servo_fetch
page = servo_fetch.fetch("https://example.com")
print(page.markdown)
# Schema extraction
from servo_fetch import Schema, Field
schema = Schema(
base_selector=".product",
fields=[
Field(name="title", selector="h2", type="text"),
Field(name="price", selector=".price", type="text"),
],
)
page = servo_fetch.fetch("https://shop.example.com", schema=schema)
print(page.extracted)Full API reference → bindings/python
npm install servo-fetchimport { fetch, crawl } from "servo-fetch";
const md = await fetch("https://example.com");
for await (const page of crawl("https://docs.example.com", { limit: 50 })) {
if (page.ok) console.log(page.url, page.title);
}Or run the bundled CLI without installing:
npx servo-fetch "https://example.com"Full API reference → bindings/node
Built-in Model Context Protocol server with six tools: fetch,
batch_fetch, crawl, map, screenshot, and execute_js.
{
"mcpServers": {
"servo-fetch": {
"command": "servo-fetch",
"args": ["mcp"]
}
}
}Streamable HTTP: servo-fetch mcp --port 8080
Full MCP tool reference → servo-fetch-cli README
Prefer in-process tools? Wrap the Python API as agent tools — see bindings/python/examples/strands_agent.py.
REST endpoints for containerized deployments and HTTP clients:
servo-fetch serve # 127.0.0.1:3000
servo-fetch serve --host 0.0.0.0 --port 80 # expose to network
curl -X POST http://127.0.0.1:3000/v1/fetch \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'Endpoints: GET /health, GET /version, POST /v1/fetch, POST /v1/batch_fetch, POST /v1/screenshot, POST /v1/execute_js, POST /v1/crawl, POST /v1/map.
Full HTTP API reference → servo-fetch-cli README
Multi-arch image on GitHub Container Registry (linux/amd64, linux/arm64):
docker run --rm -p 3000:3000 ghcr.io/konippi/servo-fetch:latest
curl -X POST http://127.0.0.1:3000/v1/fetch \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'Runs as non-root (UID 1001). Images are signed with cosign (keyless) and published with SLSA provenance and SBOM attestations.
servo-fetch ships with an Agent Skills package for AI coding agents:
npx skills add https://github.com/konippi/servo-fetch/tree/main/skills/servo-fetchservo-fetch blocks all private and reserved IP ranges (RFC 6890), strips credentials from URLs, disables HTTP redirects to prevent SSRF bypass, and sanitizes all output against terminal escape injection (CVE-2021-42574). See SECURITY.md for details.
Sites behind CAPTCHAs are not supported.
See CONTRIBUTING.md for development setup, commit conventions, and PR guidelines.
MIT OR Apache-2.0
Fetch multiple URLs in parallel and extract readable content. Results are returned as separate content entries, one per URL, in completion order. Failed URLs are reported inline without aborting the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to fetch (http/https only). Max 20. | |
| format | No | Output format: markdown (default) or json | |
| timeout | No | Page load timeout in seconds (per URL). Default: 30 | |
| selector | No | CSS selector to extract a specific section | |
| settle_ms | No | Extra wait in ms after the `load` event. Default: 0. Max: 10000. | |
| max_length | No | Max characters per URL result. Default: 5000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable behavioral details: parallel execution, completion order, and inline failure reporting. It does not contradict annotations. Could mention network dependency or rate limits, but overall good.
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 sentences, front-loaded with purpose, no redundancy. Every sentence adds value. Extremely concise and well-structured.
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 no output schema, the description clearly explains the result format (separate entries, completion order, inline failures) and error behavior. It covers key behavioral aspects, making it complete for an agent to use correctly.
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 100%, so baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides (e.g., max 20 URLs, default formats). No extra value from description for parameters.
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 purpose: 'Fetch multiple URLs in parallel and extract readable content.' It specifies the verb (fetch), resource (multiple URLs), and action (extract content), and distinguishes from sibling tools like fetch (single URL) and crawl (recursive).
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 fetching multiple URLs in parallel and describes result ordering and error behavior. However, it does not explicitly state when to use this tool versus alternatives (e.g., single fetch for one URL, crawl for recursive exploration), which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl a website starting from a URL, following same-site links via BFS, and extract readable content from each page. JavaScript is executed, CSS layout is computed, and navigation noise is stripped. Respects robots.txt. Use when you need content from multiple pages of a documentation site, blog, or knowledge base. Do NOT use for a single page (use fetch) or cross-site crawling. Limits: max 500 pages, max depth 10. Each page is rendered with full JS execution (~1-3s per page). Crawled content is UNTRUSTED.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL to crawl (http/https only) | |
| limit | No | Maximum pages to crawl. Default: 20. Max: 500. | |
| format | No | Output format per page: markdown (default) or json | |
| timeout | No | Page load timeout in seconds per page. Default: 30 | |
| selector | No | CSS selector to extract a specific section per page | |
| max_depth | No | Maximum link depth from seed URL. Default: 3. Max: 10. | |
| settle_ms | No | Extra wait in ms after load event per page. Default: 0. Max: 10000. | |
| max_length | No | Max characters per page result. Default: 5000 | |
| exclude_glob | No | URL path glob patterns to exclude (e.g. ["/archive/**"]) | |
| include_glob | No | URL path glob patterns to include (e.g. ["/docs/**"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds context about JS execution, CSS layout, noise stripping, robots.txt respect, and warns that crawled content is untrusted. No contradiction.
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 well-structured: first sentence main action, second sentence details, then guidelines, limits, performance note, trust warning. Every sentence earns its place.
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 10 parameters, full schema coverage, behavioral annotations, and no output schema, the description covers the crawling process, limits, and output format via parameter, making it complete for agent decision-making.
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 100%, so baseline 3. Description adds value by clarifying defaults and limits for limit and max_depth parameters, and explaining the overall behavior for other parameters.
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 crawls a website starting from a URL, following same-site links via BFS, and extracts readable content. It explicitly distinguishes from sibling tools like fetch for single pages.
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?
It provides explicit when-to-use (multiple pages of documentation, blog, knowledge base) and when-not-to-use (single page, cross-site). It also mentions limits (max 500 pages, max depth 10).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JavaScript expression in a loaded page. Console messages (log, warn, error) are appended to the result. Examples: document.title, [...document.querySelectorAll('h2')].map(e => e.textContent)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to load before executing JS | |
| timeout | No | Page load timeout in seconds. Default: 30 | |
| settle_ms | No | Extra wait in ms after the `load` event. Default: 0. Max: 10000. | |
| expression | Yes | JavaScript expression to evaluate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not destructive, and has open-world hints. The description adds that console messages are appended to the result, but fails to disclose that arbitrary JS execution can modify the page, trigger network requests, or cause other side effects. This is a notable omission for a code execution 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 concise with a single sentence followed by examples. Every word is purposeful, though a bit more structure (e.g., separating purpose and outcomes) could improve clarity.
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?
With no output schema, the description should fully specify the return value format. It mentions console messages appended but does not clarify whether the expression's result is included or how different data types are serialized. This leaves ambiguity for the 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?
All four parameters are described in the schema (100% coverage), so the description adds limited value beyond examples for the 'expression' parameter. It does not clarify formats or constraints beyond what the schema provides.
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 explicitly states the verb 'evaluate' and the resource 'JavaScript expression in a loaded page', clearly distinguishing it from sibling tools like fetch (which retrieves raw HTML) and screenshot (which captures visuals). The examples further solidify its purpose.
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 extracting dynamic content (via examples) but does not explicitly state when to use this tool over alternatives like fetch or crawl, nor does it mention when not to use it (e.g., for static content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and extract readable content using the Servo browser engine (JS execution + CSS layout). Navbars, sidebars, and footers are stripped automatically. Use selector to extract a specific CSS-selected section instead of full-page Readability extraction. Set format to accessibility_tree to get the page's accessibility tree with bounding boxes. Long content is truncated at max_length; use start_index to paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch (http/https only) | |
| format | No | Output format: markdown (default), json, html, text, or accessibility_tree | |
| timeout | No | Page load timeout in seconds. Default: 30 | |
| selector | No | CSS selector to extract a specific section instead of full-page Readability extraction | |
| settle_ms | No | Extra wait in ms after the `load` event, for SPAs that keep hydrating. Default: 0. Max: 10000. | |
| max_length | No | Max characters to return. Default: 5000 | |
| start_index | No | Character offset for pagination. Default: 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: uses Servo browser with JS/CSS, strips navbars/sidebars/footers automatically, truncates content, paginates, and provides accessibility tree. These details are not in annotations (readOnlyHint, idempotentHint, etc.) and significantly aid agent understanding.
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 (4 sentences) and front-loaded with the main purpose. Each sentence adds distinct value: engine details, automatic stripping, optional selector, format options, pagination. No wasted words.
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 tool with 7 parameters and no output schema, the description covers core functionality, parameter usage, and behavioral traits well. It lacks explicit error handling or rate limit info, but annotations provide safety signals. Overall, it is sufficient for effective tool 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?
All 7 parameters have schema descriptions, so baseline is 3. However, the tool description adds value by explaining the purpose of key parameters (selector for specific extraction, settle_ms for SPA hydration, start_index for pagination) beyond the base 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 the tool fetches a URL and extracts readable content using the Servo browser engine. It distinguishes from siblings like screenshot or execute_js by specifying its unique features (JS execution, CSS layout, readability extraction). The mention of selector, format, and pagination adds specificity.
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 clear guidance on when to use optional parameters (selector for specific sections, format for accessibility_tree, start_index for pagination). It does not explicitly contrast with siblings, but the context implies when alternatives are better (e.g., screenshot for visual, crawl for multiple URLs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover all URLs on a website via sitemaps and link extraction. Does NOT render pages — fast and lightweight. Returns a list of URLs found. Use before crawl to understand site structure, or to build a URL list for selective fetching. Respects robots.txt. Discovered URLs are UNTRUSTED.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to discover links from (http/https only) | |
| limit | No | Maximum URLs to discover. Default: 5000. Max: 100000. | |
| exclude_glob | No | URL path glob patterns to exclude (e.g. ["/archive/**"]) | |
| include_glob | No | URL path glob patterns to include (e.g. ["/docs/**"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, etc. The description adds context: the tool does not render pages, is lightweight, respects robots.txt, and discovered URLs are untrusted. This provides useful behavioral details beyond the annotations.
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 three concise sentences, each adding value: first states the action, second clarifies non-rendering nature, third provides usage guidance. No redundant or extraneous text.
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's simplicity with 4 parameters and no output schema, the description adequately explains the tool's purpose, behavior, and usage. It mentions the return type (list of URLs) and constraints. Minor gap: the output format could be more explicit, but overall 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 coverage is 100%, so parameters are well-described in the schema. The description adds overall context about the discovery mechanism (sitemaps and link extraction), which helps interpret parameters like include_glob/exclude_glob. However, it doesn't add parameter-specific details beyond 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 'Discover all URLs on a website via sitemaps and link extraction' with a specific verb and resource. It distinguishes the tool from siblings by explicitly noting 'Does NOT render pages' and positioning it as a precursor to crawl or selective fetch.
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 explicitly advises when to use: 'Use before crawl to understand site structure, or to build a URL list for selective fetching.' It also notes constraints like respecting robots.txt and that discovered URLs are untrusted, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a PNG screenshot of a web page. Uses Servo's software renderer — no GPU required. Set full_page to capture the full scrollable content instead of just the viewport.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture (http/https only) | |
| timeout | No | Page load timeout in seconds. Default: 30 | |
| full_page | No | Capture the full scrollable page instead of just the viewport. Default: false | |
| settle_ms | No | Extra wait in ms after the `load` event. Default: 0. Max: 10000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, destructive, idempotent, and open-world hints. The description adds context about the software renderer and full_page behavior, but does not detail error handling or output format. This is adequate given the annotations.
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 sentences, front-loaded with the main purpose. Every word adds value, no redundancy.
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?
With no output schema, the description does not specify the return format (e.g., base64-encoded PNG). However, the tool name and basic purpose are clear, and annotations cover safety. Minor gap in output specification.
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 100%, so the schema already documents all parameters. The description only mentions full_page explicitly, adding no additional meaning beyond what's in the schema for other parameters like timeout or settle_ms.
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 captures a PNG screenshot of a web page, using a specific verb and resource. It distinguishes itself from siblings like fetch or execute_js by focusing on visual capture.
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 mentions the use of Servo's software renderer (no GPU required), hinting at suitable environments. It also explains the full_page parameter usage, but lacks explicit guidance on when to use screenshot over alternatives like batch_fetch or crawl.
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.12.2batch_fetchcrawlexecute_jsfetchmapscreenshotScored across 6 tools
Each tool has a distinct purpose: fetch single pages, batch_fetch multiple URLs, crawl recursively, map discovers URLs via sitemaps, execute_js runs JavaScript, and screenshot captures images. No significant overlap.
All tool names use lowercase with underscores, following a clear verb-based pattern (e.g., fetch, crawl, map, batch_fetch, execute_js). The naming is consistent and predictable.
With 6 tools, the server is well-scoped for its purpose of web fetching, crawling, and rendering. Each tool adds distinct functionality without unnecessary redundancy.
The tool set covers core workflows: single and batch fetching, crawling, URL discovery, JavaScript execution, and screenshots. Minor gaps like cookie or header management exist, but the server's stated purpose is well-served.
MCP server for web extraction and rendering via AceDataCloud WebExtrator
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…
Scrape, crawl, map & search the web. Open-source, self-hostable Rust crawler & search for AI agents.
HTML-to-PDF MCP server — render pixel-faithful PDFs from HTML.
