Firecrawl Lite MCP Server lets AI agents scrape web pages locally, turning URLs into clean Markdown or screenshots, with optional LLM-powered structured extraction, over both MCP and a Firecrawl-compatible API.
Web scraping: scrape_page converts a single URL into clean Markdown, rendering JavaScript and waiting for the page to settle.
Batch scraping: batch_scrape processes up to 10 URLs with polite random delays between requests.
Screenshots: screenshot captures a page as a base64 PNG, with configurable viewport size and full-page option.
LLM extraction: extract_data pulls structured information (e.g., price, release date) into JSON using your own OpenAI-compatible model.
Schema-based extraction: extract_with_schema returns data matching a JSON Schema you provide.
Firecrawl-compatible API: POST /v2/scrape lets existing Firecrawl SDKs and agents use the server as a drop-in self-hosted scraper; search endpoints return a clear 501.
Local-first: one Node.js process with stealth-patched headless Chrome; no cloud, no Firecrawl account, and no API keys required for scraping.
Flexible deployment: works as an MCP stdio server via npx, as a remote MCP HTTP/SSE server, or as a Dockerized HTTP service with health checks.
Configurable scraping: options for user-agent rotation, viewport, delays, settle time, link stripping, output character limits, retries, and proxy support.
Optional LLM tools: only needed for extract_*; bring your own model provider (OpenAI, Anthropic, xAI, OpenRouter, Ollama, etc.).
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., "@firecrawl-lite-mcp-server Extract all job listings from https://jobs.example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Web scraping for AI agents, minus the infrastructure. One process. Your machine. No scraping cloud in the loop.
Your agent needs to read web pages. Firecrawl is great at that, but self-hosting it means Redis, a Playwright service, API workers, and a weekend. Firecrawl Lite is the other option: a single Node.js process with headless Chrome (stealth-patched) that turns URLs into clean Markdown, and speaks the two protocols agents actually use:
MCP — for Claude Desktop, Claude Code, Cursor, and anything else that talks Model Context Protocol.
Firecrawl-compatible REST API — for any agent or harness that already speaks the Firecrawl SDK. Point FIRECRAWL_API_URL at it and it quietly impersonates a self-hosted Firecrawl (scrape only — no crawl or search).
Nothing leaves your box except the page requests themselves. No Firecrawl account. No API keys required at all unless you want the optional LLM-powered extraction tools — and for those, you bring your own model.
As an MCP server (Claude Code shown; Claude Desktop and Cursor configs are below):
claude mcp add firecrawl-lite npx -- -y firecrawl-lite-mcp-serverAs a Firecrawl-compatible API (for agents, scripts, anything HTTP):
docker run -d -p 3000:3000 ariangibson/firecrawl-lite-mcp-server:latest
curl -X POST localhost:3000/v2/scrape -H 'Content-Type: application/json' -d '{"url":"https://example.com"}'That's a working scraper. Everything below is optional.
Related MCP server: Hyperbrowser MCP Server
Tool | Does | Needs an LLM? |
| URL → clean Markdown. Renders JS, waits for the DOM to settle, strips the junk. | No |
| Same, for up to 10 URLs, with polite delays between them. | No |
| URL → PNG (base64). Viewport or full page. | No |
| "Get me the price and the release date" → JSON, via your LLM. | Yes |
| Same, but you hand it a JSON Schema and get exactly that shape back. | Yes |
The Firecrawl-compatible API exposes scrape_page as POST /v2/scrape. See the API section for the exact contract.
The env block is only needed for the extract_* tools; leave it out otherwise.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"firecrawl-lite": {
"command": "npx",
"args": ["-y", "firecrawl-lite-mcp-server"],
"env": {
"LLM_API_KEY": "sk-...",
"LLM_PROVIDER_BASE_URL": "https://api.openai.com/v1",
"LLM_MODEL": "gpt-5.5"
}
}
}
}claude mcp add firecrawl-lite \
--env LLM_API_KEY=your_key \
--env LLM_PROVIDER_BASE_URL=https://api.openai.com/v1 \
--env LLM_MODEL=gpt-5.5 \
-- npx -y firecrawl-lite-mcp-serverDrop the --env lines if you don't need the LLM tools. For a remote instance: claude mcp add -t http firecrawl-lite http://your-server:3000/mcp.
The env block is only needed for the extract_* tools; leave it out otherwise.
{
"mcpServers": {
"firecrawl-lite": {
"command": "npx",
"args": ["-y", "firecrawl-lite-mcp-server"],
"env": {
"LLM_API_KEY": "sk-...",
"LLM_PROVIDER_BASE_URL": "https://api.openai.com/v1",
"LLM_MODEL": "gpt-5.5"
}
}
}
}Any framework with a "self-hosted Firecrawl" option works unchanged — set its Firecrawl URL to your Firecrawl Lite instance. The server implements the scrape endpoint the SDKs call; search returns a clear 501 because this is a renderer, not a search engine, so pair it with whatever search provider your agent supports.
Hermes uses Firecrawl for web_extract and lets you split search and extract across providers.
# ~/.hermes/.env
FIRECRAWL_API_URL=http://your-server:3000
# FIRECRAWL_API_KEY=... only if you set one on the server# ~/.hermes/config.yaml
web:
search_backend: ddgs # DuckDuckGo, no key. Or searxng, brave-free, ...
extract_backend: firecrawl # → Firecrawl LiteHermes's native web_extract now renders through your local browser. It also supports MCP servers if you want screenshot and extract_with_schema too.
from firecrawl import Firecrawl
fc = Firecrawl(api_key="unused", api_url="http://your-server:3000")
doc = fc.scrape("https://example.com", formats=["markdown"])
print(doc.markdown)The JS SDK works the same way with apiUrl.
Everything is an environment variable, and everything has a default. Full annotated list in .env.example.
Running via npx with nothing set = MCP over stdio. Enable any of these and it becomes an HTTP server on PORT (default 3000) instead. The Docker image turns on /mcp and the Firecrawl API out of the box.
Variable | |
|
|
| Optional. If set, that API requires |
|
|
|
|
/health is always there when HTTP is on. Without Docker: ENABLE_FIRECRAWL_API=true npx -y firecrawl-lite-mcp-server.
extract_*)Variable | |
| Any OpenAI-compatible base URL; the server calls |
| Model name |
| Your key |
| Optional tuning, passed straight through. Defaults |
# OpenAI
LLM_PROVIDER_BASE_URL=https://api.openai.com/v1 LLM_MODEL=gpt-5.5
# Anthropic
LLM_PROVIDER_BASE_URL=https://api.anthropic.com/v1 LLM_MODEL=claude-haiku-4-5
# xAI
LLM_PROVIDER_BASE_URL=https://api.x.ai/v1 LLM_MODEL=grok-4
# OpenRouter
LLM_PROVIDER_BASE_URL=https://openrouter.ai/api/v1 LLM_MODEL=openai/gpt-5.5
# Ollama (local)
LLM_PROVIDER_BASE_URL=http://localhost:11434/v1 LLM_MODEL=llama3.3Variable | Default | |
| a current Chrome UA | One string, or a JSON array to rotate through (keep it on one line) |
|
| |
|
| Random pause before navigating (ms) |
|
| Random pause between batch URLs (ms) |
|
| How long to wait for a page to stop changing. Raise it for sites that inject content on a slow |
|
| Replace |
|
| Hard cap on Markdown/text output, ending in a |
|
| Attempts per scrape, each advancing the proxy / UA rotation |
PROXY_SERVER_URL=http://proxy.example.com:10001-10010 # a port range = automatic rotation
PROXY_SERVER_USERNAME=...
PROXY_SERVER_PASSWORD=...
PROXY_LLM_API=false # proxies are for target sites; LLM calls go direct unless you say otherwisedocker run -d -p 3000:3000 \
-e LLM_API_KEY=... -e LLM_PROVIDER_BASE_URL=... -e LLM_MODEL=... \
ariangibson/firecrawl-lite-mcp-server:latestOr use the bundled docker-compose.yml with a .env file. It uses a wget health check on purpose: the Alpine image has no curl, and a curl check will restart-loop the container (see Troubleshooting).
Images are multi-arch (amd64 / arm64), published to ariangibson/firecrawl-lite-mcp-server on Docker Hub and ghcr.io/ariangibson/firecrawl-lite-mcp-server. Tags: latest moves on every push to main; stable only moves on releases — track stable in production (it pairs well with Watchtower for hands-off updates); version tags (1.5.0, 1.5, 1) pin exactly.
Remote MCP clients: Claude Code → claude mcp add -t http firecrawl-lite http://your-server:3000/mcp. Claude Desktop → Settings → Connectors with an HTTPS URL, or mcp-proxy http://your-server:3000/sse if you don't have a certificate (needs ENABLE_SSE_ENDPOINT=true).
Implements the slice of the Firecrawl v2 API that SDK clients use for extraction.
Endpoint | |
| Request: |
|
|
formats defaults to ["markdown"] and accepts both "markdown" and { "type": "markdown" }; screenshot is accepted but ignored. Two extensions beyond stock Firecrawl: stripLinkUrls (boolean) and maxChars (number) override the SCRAPE_STRIP_LINK_URLS / SCRAPE_MAX_CHARS defaults per request — and when link URLs are stripped, links is always included so nothing is lost. With FIRECRAWL_API_KEY set, both endpoints return 401 before anything else. Crawl, map, batch jobs, and the other async endpoints aren't implemented.
Could not find Chrome — the npx postinstall step downloads Chrome the first time; if it's missing: npx puppeteer browsers install chrome. Corrupted? rm -rf ~/.cache/puppeteer and run it again.
Scraping works, extract_* doesn't — it's the LLM call. The server logs the provider's status and response body to stderr. 401 = bad key. 400 = wrong model name or a tuning param the model rejects. 429 = you're being rate limited.
Container restart-loops with SIGTERM right after "listening on port 3000" — a curl health check is failing because the image has no curl. Use wget --spider http://localhost:3000/health (the bundled compose file already does).
Agent says Firecrawl isn't configured / extract fails — curl http://your-server:3000/health should show endpoints.firecrawlApi = "enabled". If you set FIRECRAWL_API_KEY on the server, the agent needs the same value. Search failing is expected unless the agent has a separate search provider.
For the curious or the contributing: config.ts parses every env var once into a typed object; browser.ts owns one stealth browser session (launch flags, proxy, UA, navigation, cleanup, retries); scraper.ts puts rotation, retries, and scroll/settle heuristics behind two methods, scrape and screenshot; htmlToMarkdown.ts does the cleaning and conversion; index.ts is just MCP tool definitions, LLM extraction, and transports. The browser and clock are injected, so the whole scrape pipeline is tested through a stub browser — npm test needs no Chrome and no network.
npm install && npm run build && npm testReleases: bump version, git tag vX.Y.Z, push the tag. CI publishes to npm (with provenance) and Docker Hub / GHCR.
Inspired by the Firecrawl team and their official MCP server. This is an independent, deliberately small take on the same idea. If you want the managed, enterprise-grade version with crawling, search, and a team behind it, that's firecrawl.com.
MIT — see LICENSE.
Scrape multiple URLs in a single request
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Array of URLs to scrape | |
| onlyMainContent | No | Extract only main content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action, offering no information about failure handling, rate limits, concurrency, return format, or whether partial failures are tolerated. This is a significant gap for a batch operation.
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, front-loaded sentence that conveys the core functionality without any wasted words. It is appropriately concise for the tool's simplicity.
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 the simple schema, the lack of annotations and output schema means the description must explain return values and operational nuances. It does not, leaving an agent uncertain about response format, error behavior, or batch limits. The description is incomplete for a batch tool.
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 the schema already documents both 'urls' and 'onlyMainContent'. The description adds no additional parameter semantics beyond what the schema provides, matching the baseline of 3.
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 'Scrape multiple URLs in a single request' clearly states the verb (scrape), the resource (multiple URLs), and the batching aspect, which distinguishes it from siblings like scrape_page (single page) and extract_data (extracting specific data). The purpose is immediately clear.
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 scenarios involving multiple URLs in one request, which provides clear context. However, it does not explicitly mention when not to use it or name alternatives, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from webpages using LLM
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to extract data from | |
| prompt | Yes | Instructions for what data to extract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. The phrase 'using LLM' is genuinely useful behavioral context — it signals non-determinism, cost, and latency. However, nothing is disclosed about failure behavior, result format, rate limits, or the read-only nature of extraction beyond what the verb 'extract' implies.
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 tight clause with the verb front-loaded and zero filler words. It is appropriately brief for a tool whose parameters are already well-documented in the schema, though it could afford a bit more substance.
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 tool with complete schema coverage and no output schema, the description is mostly adequate on inputs. But it does not address the ambiguity with 'extract_with_schema', nor does it clarify what a successful extraction returns. These are notable gaps for a tool of moderate complexity.
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%, with both 'urls' and 'prompt' already described in the schema ('URLs to extract data from' and 'Instructions for what data to extract'). The tool description adds nothing beyond this, so it sits at the baseline of 3.
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 states a specific verb ('extract'), resource ('structured data from webpages'), and method ('using LLM'), so the core purpose is clear. However, it does not distinguish itself from the sibling 'extract_with_schema', which likely exists precisely for schema-driven extraction. Without differentiation, an agent cannot tell which variant to pick.
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 usage guidance is provided at all. The description does not say when to choose this tool over the closely related siblings (scrape_page, batch_scrape, extract_with_schema), nor does it mention any exclusions or prerequisites such as LLM cost or token limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data using a JSON schema
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to extract data from | |
| prompt | No | Optional instructions for extraction | |
| schema | Yes | JSON schema defining the data structure to extract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Extract structured data' — it doesn't reveal whether it executes live HTTP requests, how it handles multiple URLs, whether output is validated/returned against the schema, or what happens on failure. For a data-extraction tool with zero annotation coverage, this is a significant transparency gap.
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 efficient sentence with no wasted words, which is good for conciseness. However, the brevity masks missing critical context; it is underspecified rather than appropriately concise, so it doesn't earn full marks for effective structure.
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 3 parameters, nested schema objects, no output schema, and no annotations, this description is markedly incomplete. It fails to explain the relationship between prompt and schema, the behavior with multiple URLs, expected output format, or error handling. An agent cannot fully know how to construct a correct call or interpret results from this description alone.
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 the schema already documents all three parameters with descriptions. The description's 'using a JSON schema' merely echoes the schema parameter's purpose without adding syntax, format, or interaction details — e.g., how 'prompt' modifies the schema-driven extraction. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states a clear verb (Extract), a resource (structured data), and a mechanism (using a JSON schema), giving the agent a basic sense of what the tool does. However, it doesn't differentiate from the sibling 'extract_data' — with two extraction tools present, the description leaves the agent unsure how extract_with_schema differs from extract_data beyond the name's hint about schema-driven 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?
No guidance is given on when to use this tool versus siblings like extract_data, scrape_page, or batch_scrape. There is no when/to-use, when-not-to-use, or alternative routing. The name and description imply a schema-based extraction use case, but the agent must infer the selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content from a single webpage
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Webpage URL to scrape | |
| onlyMainContent | No | Extract only main content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic extraction action and does not explain output format, handling of JavaScript-heavy pages, what 'main content' means, or any limitations. This is a significant gap for a scraping 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 concise sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or filler.
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 2-parameter tool with no output schema, the description covers the basics. However, it lacks context about how this tool compares to sibling tools like extract_data and extract_with_schema, and does not hint at what the returned content might include, leaving some ambiguity.
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%, with both url and onlyMainContent already described. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 ('extract'), the resource ('content'), and the scope ('a single webpage'), which distinguishes it from batch_scrape. It is specific and 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?
The phrase 'single webpage' implies a single-page use case compared to batch_scrape, but there is no explicit guidance on when to use this tool versus alternatives like extract_data or extract_with_schema. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a webpage using stealth browser
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Webpage URL to screenshot | |
| width | No | Viewport width in pixels | |
| height | No | Viewport height in pixels | |
| fullPage | No | Capture full page height |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'stealth browser' which hints at anti-detection behavior, but it does not disclose other relevant traits such as how the page is loaded (e.g., JavaScript execution), what happens on failures, or any return format. This leaves significant gaps in understanding the tool's runtime behavior.
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 concise sentence with no wasted words. It is front-loaded with the core action. However, it lacks the substance to fully support other dimensions, but as a concise statement it is efficient and appropriate for the tool's simplicity.
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 output schema, the description is incomplete. It fails to explain what the screenshot output looks like (e.g., image format, whether it returns binary data or a URL), or any additional context about usage, limitations, or integration with other tools. For a tool with four parameters and no output schema, this is a clear gap.
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 input schema provides 100% coverage for all parameters with clear descriptions (url, width, height, fullPage). The tool description itself does not add any additional parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.
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 takes a screenshot of a webpage using a stealth browser. This specific verb+resource combination ('take a screenshot of a webpage') clearly distinguishes it from sibling tools like scrape_page or extract_data, which focus on data extraction rather than 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?
There is no guidance on when to use this tool versus alternatives (e.g., scrape_page for text extraction). It does not mention any prerequisites, limitations, or typical use cases. The context is implied but not explicitly stated.
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.
v1.5.0extract_data1 field changedInput schema / properties / enableWebSearchRemoved value: -{
- "default": false,
- "description": "Enable web search for additional context",
- "type": "boolean"
-}extract_with_schema1 field changedInput schema / properties / enableWebSearchRemoved value: -{
- "default": false,
- "description": "Enable web search for additional context",
- "type": "boolean"
-}v1.3.0batch_scrapeextract_dataextract_with_schemascrape_pagescreenshotScored across 5 tools
Most tools have clearly distinct purposes: scraping, batch scraping, LLM extraction, schema-based extraction, and screenshots. The only potential confusion is between extract_data and extract_with_schema, but their descriptions make the distinction clear.
All names use lowercase with underscores and mostly follow a verb-first pattern (scrape_page, batch_scrape, extract_data, extract_with_schema). 'screenshot' breaks the verb_noun pattern but is still a familiar, predictable command.
Five tools is well-scoped for a 'lite' server: it covers single scraping, batch scraping, two flavors of structured extraction, and screenshots. Each tool earns its place without redundancy or bloat.
The core web data collection lifecycle is covered: raw content extraction, batch processing, structured extraction, and visual capture. Missing crawls or search features, but those are likely intentionally excluded from a lite server.
Enable language models to perform advanced AI-powered web scraping with enterprise-grade reliabili…
Turn any website into structured JSON data matching your custom schema.
Direct access to 60+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
