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., "@Crawl4ai Local Extract book titles and prices from https://books.toscrape.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.
Local MCP server for Crawl4ai on Linux.
π€ Most of the code was generated with AI assistance.
See also:
Linux
Python 3.14 (installing via uv is fine: uv python install 3.14)
Related MCP server: Crawl4AI MCP
uv sync
# Install Chromium for Playwright
uv run crawl4ai-setupIf the browser fails to launch because system libraries required by Chromium are missing, install them with the command below (requires sudo; apt-based distros such as Debian/Ubuntu only).
uv run playwright install-deps chromiumπ¨ This server is a stdio server β no need to keep it running like a network server. When connected to an agent as MCP, the agent automatically spins up the server instance.
# Check for the "π Crawl4ai MCP server started." message, then exit
uv run mainβ
After confirming the welcome message, press Ctrl+C to exit, then add the MCP to your agent.
# Tip: debugging mode (MCP Inspector)
uv run mcp dev src/crawl4ai_local/server.pyclaude mcp add --transport stdio --scope user crawl4ai -- uv run --directory <parent_location>/crawl4ai-local mainparent_location: An absolute path like /home/<user>/dev/repo (use ~ only where the shell expands it)
e.g. claude mcp add --transport stdio --scope user crawl4ai -- uv run --directory /home/me/dev/repo/crawl4ai-local main
# Check MCP installation
claude mcp list
claude mcp get crawl4aihermes mcp add crawl4ai --command "uv" --args "run" "--directory" "<parent_location>/crawl4ai-local" "main"parent_location: An absolute path like /home/<user>/dev/repo (use ~ only where the shell expands it)
e.g. /home/me/dev/repo/crawl4ai-local
# Check MCP installation
hermes mcp listcrawl_markdown(url, wait_seconds=0, wait_selector="")Crawl a URL and return the content as Markdown.
crawl_structured(url, selector, fields, wait_seconds=0, wait_selector="")Extract repeated elements as JSON using CSS selectors.
crawl_structured(
url="https://books.toscrape.com/",
selector="article.product_pod",
fields={"μ λͺ©": "h3@title", "κ°κ²©": ".price_color:text"},
)
# β [{"μ λͺ©": "A Light in the Attic", "κ°κ²©": "Β£51.77"}, ...]Field spec syntax:
Spec | Meaning |
| Text of the matched element |
| Attribute of a child element ( |
| Attribute of the base element itself |
| Nth element β use standard CSS ( |
Both tools share the waiting options (see below).
crawl_screenshot(url, output_path)Capture a full-page screenshot and save it to a file. Parent directories are created automatically.
π‘ If output_path is a Windows path (C:\Users\me\shot.png, D:/shots/a.png), it is converted to the mounted drive path (/mnt/c/Users/me/shot.png) before saving.
π‘οΈ output_path is checked against a blocklist of known system directories before the crawl even runs.
Linux: /bin, /boot, /dev, /etc, /lib, /lib32, /lib64, /libx32, /proc, /run, /sbin, /snap, /sys, /usr, /var
Windows (under /mnt/<drive>/, case-insensitive): Windows, Program Files, Program Files (x86), ProgramData, System Volume Information, $Recycle.Bin, Users/All Users, Users/Default
A path that resolves into one of these (including via .. traversal or symlinks) is rejected with an error message, so an agent can't accidentally overwrite system files. This is a blocklist, not a full sandbox β it guards against mistakes, not a determined attacker. If Windows drives are mounted somewhere other than /mnt/, update _DRIVE_MOUNT_ROOT in server.py accordingly.
Instead of launching Chromium on every call (which is expensive), the server keeps one browser instance for the process lifetime. If the shared browser crashes mid-session, the server detects it and recovers automatically:
Crash detection matches Playwright collapse signatures only β Target page, context or browser has been closed, browser has crashed, browsertype.launch failures, etc. Network errors, anti-bot blocks, and timeouts are page-side causes and are never retried with a fresh browser.
On crash: dispose the dead instance β launch a new one β retry, up to _MAX_RECREATE_ATTEMPTS = 2 attempts.
Both failure paths are checked equally on every attempt: exceptions raised by arun() and result.success=False + crash message in error_message.
On the last attempt, a crash is still reported as a failure, but the crawler is not reset again β that cleanup already happened on the prior attempt, and resetting a second time could tear down an instance a concurrent request just recreated.
Preventive recycling (e.g., refresh every N pages) is intentionally left to Crawl4ai's built-in browser recycling; the server only reacts to actual collapses.
Concurrency note: multiple simultaneous arun() calls on the shared crawler are safe β Crawl4ai serializes page creation internally (_page_lock, GH-1198 fix) and manages context lifecycle with refcounting + LRU. Verified with concurrent multi-site smoke tests.
For dynamic pages that render content late using JS, use the waiting options of crawl_markdown / crawl_structured.
# Method 1: Wait for a fixed duration (seconds)
crawl_markdown(url="https://example.com", wait_seconds=5)
# Method 2: Wait until a CSS selector appears (takes precedence over wait_seconds when specified)
crawl_markdown(url="https://example.com", wait_selector="div.result-list")Comparison of 3 cases on a local test page that updates content via JS after 3 seconds:
Case | success | Captures Dynamic Content |
No waiting option | True | β Returns only "Loading..." |
| True | β Accurately captures final content |
| True | β Passes immediately if the element already exists in the initial HTML |
wait_selector is only valid for "newly created elements." If the text of an element already present in the initial HTML (e.g., <article id="dynamic">Loading...</article>) changes later, the selector matches immediately and passes without waiting. For pages that update text dynamically, use wait_seconds.
Extreme pages trigger anti-bot heuristics. Pages with minimal content and many script tags are flagged by Crawl4ai's anti-bot detector as Blocked by anti-bot protection: Structural: no_content_elements, script_heavy_shell, resulting in success=False. Although rare in production pages, testing should be done on pages containing basic static content (navigation bars, paragraphs, etc.).
μ£Όμ΄μ§ URLμ ν¬λ‘€λ§ν΄μ λ§ν¬λ€μ΄μΌλ‘ λ°ννλ€.
Args: url: ν¬λ‘€λ§ν URL. wait_seconds: HTMLμ λ°κΈ° μ λκΈ° μκ°(μ΄). JS λμ λ‘λ© νμ΄μ§μ μ¬μ©. wait_selector: μ΄ CSS μ λ ν°κ° λνλ λκΉμ§ λκΈ°. μ§μ μ wait_secondsλ³΄λ€ μ°μ .
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| wait_seconds | No | ||
| wait_selector | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does mention the waiting behavior for dynamic pages (wait_seconds, wait_selector) and the priority of wait_selector, which is useful. However, it omits error handling, timeout behavior, authentication requirements, or any side effects beyond fetching the page.
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 and well-structured, with a one-sentence summary followed by a clear parameter list. It is front-loaded with the core function and avoids unnecessary detail. The only minor loss is not using bullet points, but the format is acceptable.
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 covers the tool's purpose and parameters adequately, and an output schema exists to define the return format. However, it does not mention any limitations, error scenarios, or when it should not be used, and it lacks explicit differentiation from siblings. For a tool with three parameters and no annotations, it is slightly below the ideal 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?
The description includes an Args section that explains each parameter beyond the schema titles. It clarifies that wait_seconds is for JS dynamic loading and that wait_selector overrides wait_seconds when specified. This compensates for the 0% schema description coverage and adds meaningful semantics.
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 (crawl), the target (URL), and the output format (markdown). It is specific enough to distinguish from the sibling tools (crawl_screenshot and crawl_structured) based on the output type, though it does not explicitly name the alternatives.
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 provides no guidance on when to use this tool versus the siblings, nor any exclusions or alternative routing. Usage context is only implied by the markdown output, which is insufficient for an agent to make a confident choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
μ€ν¬λ¦°μ·μ μ°μ΄ νμΌλ‘ μ μ₯νλ€.
Args: url: ν¬λ‘€λ§ν URL. output_path: μ μ₯ν νμΌ κ²½λ‘. Windows κ²½λ‘("C:\Users\me\x.png")λ /mnt/c/Users/me/x.png λ‘ λ³νν΄ μ μ₯νλ€.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| output_path | 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 carries the full burden. It discloses one behavioral trait: Windows paths are converted to /mnt/c/ format. However, it does not mention other relevant behaviors such as network access, headless browsing, whether the page must be fully loaded, or potential side effects like cookie usage. Given the tool's simplicity, the path conversion is helpful but insufficient for full transparency.
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 extremely concise: one purpose sentence plus a formatted Args block. The key behavioral note about path conversion is included without redundancy. The structure is clean and front-loaded, with the essential purpose stated first and parameter details following. 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?
For a two-parameter screenshot tool, the description covers the basic usage and the path conversion quirk. However, it omits any mention of return values (though an output schema exists), error conditions, or runtime requirements (e.g., network access, browser dependencies). It is adequate for simple usage but leaves gaps that could cause the agent to call it incorrectly in edge cases.
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%, so the description must compensate. For 'url', it merely says 'URL to crawl,' which adds little beyond the parameter name. For 'output_path', it explains the Windows-to-WSL path conversion, which is genuinely useful and goes beyond the schema. This partial enrichment earns a 3 β it provides some semantic value but is not comprehensive.
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: 'Take a screenshot and save it as a file.' It specifies the resource (screenshot) and the action (save to file), which is specific enough. It does not explicitly differentiate from sibling tools like crawl_markdown or crawl_structured, but the name and action make it obvious it's for capturing screenshots rather than extracting text or structured data, so it's clear but not explicitly contrasted.
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?
There is no guidance on when to use this tool versus the siblings. It does not mention any alternative or exclusion criteria. The only usage-related note is about Windows path conversion, which is a technical detail rather than a decision guideline. The agent is left to infer that this tool is appropriate when a screenshot is needed, but no explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CSS μ λ ν°λ‘ λ°λ³΅ μμλ₯Ό μ‘μ μ§μ ν νλλ§ JSONμΌλ‘ μΆμΆνλ€.
Args: url: ν¬λ‘€λ§ν URL. selector: λ°λ³΅ μμλ₯Ό μ‘λ CSS μ λ ν° (μ: "table tr.item", "div.product-card"). fields: μΆμΆν νλ. ν€=νλλͺ , κ°=μΆμΆ μ§μ λ¬Έμμ΄. - ν μ€νΈ: "td" λλ "td:text" - μμ±: "a@href" (μμ@μμ±λͺ ), μμ μ체 μμ±μ "@data-value" - Nλ²μ§Έ μμλ CSS λ¬Έλ² "td:nth-of-type(1)" μ¬μ© (":eq()" λ―Έμ§μ) μ: {"μ΄λ¦": "td:nth-of-type(1):text", "λ§ν¬": "a@href"} wait_seconds: HTMLμ λ°κΈ° μ λκΈ° μκ°(μ΄). JS λμ λ‘λ© νμ΄μ§μ μ¬μ©. wait_selector: μ΄ CSS μ λ ν°κ° λνλ λκΉμ§ λκΈ°. μ§μ μ wait_secondsλ³΄λ€ μ°μ .
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| fields | Yes | ||
| selector | Yes | ||
| wait_seconds | No | ||
| wait_selector | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that wait_selector takes precedence over wait_seconds, that :eq() is not supported, and how attribute extraction works. It does not cover edge cases like missing elements or error behavior, but the output schema presumably handles return-value details.
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 one-sentence purpose is front-loaded, followed by a well-organized Args block where each line contributes actionable detail. The syntax examples and precedence note are dense but avoid redundant or promotional language. Nothing in the description is wasted.
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 covers all five parameters, including the important wait_selector precedence and field extraction grammar, which is sufficient for invoking the tool. Given that an output schema exists, return values need not be described. Minor gaps such as behavior on empty selections or pagination prevent a 5.
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 fully compensates. Every parameter is documented with concrete examples: url, selector with illustrative patterns, fields with text/attribute/Nth-child syntax and a JSON example, plus wait_seconds and wait_selector with usage guidance. This goes far beyond the bare 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 opens with a specific verb and resource: using CSS selectors to capture repeating elements and extract only designated fields into JSON. This clearly distinguishes it from sibling tools crawl_markdown and crawl_screenshot, which produce different output formats.
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 context on how to use the tool, including examples of selectors and field extraction syntax, and notes that wait_seconds is for JS-dynamic pages. However, it does not explicitly state when to prefer this over crawl_markdown or crawl_screenshot, so it lacks explicit exclusions and alternative routing.
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.0crawl_markdowncrawl_screenshotcrawl_structuredScored across 3 tools
Each tool converts a URL into a different output format: markdown, screenshot, or structured JSON. The purposes are mutually exclusive and clearly distinguishable by the suffix in the tool name. No overlap or ambiguity exists.
All tools share the consistent 'crawl_' prefix followed by the output type (markdown, screenshot, structured). This follows a predictable verb_noun pattern, making it easy to infer tool behavior from the name alone.
Three tools is well-scoped for a focused crawling server that offers three distinct output modes. Each tool earns its place without redundancy or unnecessary bloat.
The set covers the core crawling needs: full content (markdown), visual capture (screenshot), and targeted extraction (structured). A minor gap is the lack of a raw HTML option, but the three provided modes handle most practical use cases without dead ends.
Scrape, crawl and search the web for AI agents via MCP.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Web MCP: scrape/crawl sites, web search, brand assets, app stores, YouTube, Reddit, Hacker News.
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.β¦