Firecrawl vs Context.dev
Firecrawl
Mendable AI, Inc.
Firecrawl wins · 23–20 (51 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to Context.devA direct probe confirms Firecrawl publishes a working llms.txt at docs.firecrawl.dev/llms.txt with structured agent-readable documentation links, letting an AI agent be pointed directly at it to navigate Firecrawl's docs. Missing for 10: explicit first-party announcement/documentation describing llms.txt support as a deliberate feature, and independent community confirmation of agents successfully using it.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.firecrawl.dev/llms.txt # Firecrawl Docs ## English ### v2 #### Documentation ##### Get Started …”
Context.dev has a confirmed live llms.txt at docs.context.dev/llms.txt (HTTP 200, agent-oriented index of docs), plus agent-oriented docs, MCP server, CLI, and a coding-agent skill install guide, directly enabling an agent to be pointed at agent-native documentation. Missing for 10: independent third-party confirmation that agents successfully consume the llms.txt in practice beyond the probe check.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.context.dev/llms.txt # Context.dev - [The go-to web data API](https://docs.context.dev/introductio…”
- [claimed-docs] “Connect your AI client to Context.dev tools for live web and company data.”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [claimed-docs] “Teach your coding agent how to choose and use the Context.dev API.”
- [probe] “official MCP server documented at https://mcp.context.dev/mcp”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Context.devFirecrawl offers an API-first product (async scraping, webhooks, CLI, SDKs) that is well-suited to headless/CI use, and docs confirm a CLI and webhook-based async event delivery for automation pipelines. However, there's no explicit CI-specific documentation (e.g., GitHub Actions examples, Docker image for CI), and community comments note some daemon/CLI limitations rather than confirming robust CI usage. missing for 10: explicit CI/headless deployment docs or examples, independent confirmation of stable CLI/daemon behavior in automated pipelines, containerization guidance for CI environments.
- [claimed-docs] “Webhooks Async event delivery”
- [probe] “official CLI documented at https://docs.firecrawl.dev/sdks/cli”
- [github] “Scrape thousands of URLs asynchronously”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Context.dev ships a CLI explicitly documented for scripting and CI use ('Call Context.dev from your terminal and use JSON responses in scripts or CI'), backed by a full REST API with OpenAPI spec, async batch jobs for long-running headless crawls, and documented rate-limit/timeout handling suited to automated pipelines. Missing for 10: no explicit CI/CD pipeline example (e.g., GitHub Actions), and no independent/community confirmation of headless CI usage beyond vendor docs.
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userConnect an agent via an official MCP server
weight 3 · round drawnFirecrawl is a scraping/data-extraction service (not itself an agent), and it documents an official MCP server for connecting AI tools/agents to Firecrawl, corroborated by a dedicated GitHub repo (firecrawl-mcp-server). Missing for 10: independent hands-on testing of the MCP server itself and details on tool/resource coverage exposed via MCP.
- [claimed-docs] “MCP Server: Connect Firecrawl to any AI tool via the Model Context Protocol”
- [probe] “official MCP server documented at https://github.com/mendableai/firecrawl-mcp-server”
Context.dev is a web-data API (not itself an agent), so the MCP-server axis applies, and it publishes an official hosted MCP endpoint (mcp.context.dev/mcp) plus install docs for connecting AI clients to its tools for live web/company data. Missing for 10: independent/hands-on verification of the MCP server working in practice beyond first-party docs and a probe confirming the endpoint exists.
- [probe] “official MCP server documented at https://mcp.context.dev/mcp”
- [claimed-docs] “Connect your AI client to Context.dev tools for live web and company data.”
ai-native userUse an official CLI
weight 2 · round to FirecrawlFirecrawl ships an official CLI (docs.firecrawl.dev/sdks/cli) that installs, authenticates, and adds skills to coding agents, directly matching an AI-native CLI story. However, community feedback notes real limitations in CLI/daemon mode (e.g., inability to return HTML), suggesting it's not fully mature. Missing for 10: independent hands-on verification of full CLI feature parity, and no comparison data beyond one critical community comment.
- [claimed-docs] “One command installs the Firecrawl CLI, authenticates in your browser, and adds skills to every detected coding agent.”
- [probe] “official CLI documented at https://docs.firecrawl.dev/sdks/cli”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Docs and probe confirm an official CLI exists ('Call Context.dev from your terminal and use JSON responses in scripts or CI') with a dedicated install page, supporting agentic/CI workflows. However, there's no independent/hands-on corroboration of the CLI's functionality or depth beyond first-party docs. Missing for 10: independent verification/hands-on review of CLI usage, details on CLI command coverage vs the full API surface.
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userDrive the product through a documented public API
weight 3 · round to Context.devFirecrawl is API-first: docs cover scrape/crawl/search/extract endpoints, schema-based structured output, webhooks, and SDKs/CLI, all confirmed by an extensive llms.txt-indexed documentation site and GitHub feature list. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (probe returned 404s) and independent third-party confirmation of API completeness.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Search the web and get full page content from results in one call.”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [github] “Use a schema to get structured data:”
- [claimed-docs] “Webhooks Async event delivery”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.firecrawl.dev/llms.txt # Firecrawl Docs ## English ### v2 #### Documentation ##### Get Started …”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.firecrawl.dev/openapi.json, https://docs.firecrawl.dev/swagger.json, https://docs.firec…”
- [probe] “official CLI documented at https://docs.firecrawl.dev/sdks/cli”
Context.dev is fundamentally an API product with a public OpenAPI spec, documented endpoints (crawl, extract, screenshot, brand data, auth), API key management, rate-limit headers, plus a CLI and MCP server built on top of the same API — clear evidence of a documented, drivable public API for AI-native consumption. Missing for 10: independent third-party developer confirmation of full API coverage beyond docs/probes.
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Choose **Restricted** when an integration needs only selected operations; a restricted key with no permissions cannot call the API.”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
- [claimed-docs] “discover → register → deliver setup link & code to the user → user completes claim in browser → poll for access_token → call API.”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to Context.devFirecrawlnone0/10No evidence of scoped or least-privilege API key/credential management for agents; documentation covers scraping, crawling, MCP, CLI, and webhooks but nothing about API key scopes, permissions, or credential issuance controls.
Docs explicitly describe restricted API keys scoped to selected operations only, with a no-permission key unable to call the API at all, directly supporting least-privilege credential issuance for agents; the OAuth-like device flow (discover→register→claim→poll) also supports scoped token issuance per client. missing for 10: no evidence of fine-grained scoping beyond operation-level (e.g., resource/data scoping), and no independent/hands-on confirmation of restricted-key behavior in production.
- [claimed-docs] “Choose **Restricted** when an integration needs only selected operations; a restricted key with no permissions cannot call the API.”
- [claimed-docs] “discover → register → deliver setup link & code to the user → user completes claim in browser → poll for access_token → call API.”
ai-native userBuild against official SDKs
weight 2 · round to FirecrawlThe only concrete artifact tied to 'SDKs' in the evidence is the CLI documented at docs.firecrawl.dev/sdks/cli, implying an SDKs section exists, but no evidence pack item names or links a Python/Node/other language SDK, shows install/usage snippets, or corroborates community usage. Missing for 10: explicit language SDK docs/links, code examples, independent/community confirmation of SDK usage.
- [probe] “official CLI documented at https://docs.firecrawl.dev/sdks/cli”
- [claimed-docs] “One command installs the Firecrawl CLI, authenticates in your browser, and adds skills to every detected coding agent.”
Context.devnone0/10The evidence shows an OpenAPI spec, CLI, MCP server, and 'skill' for coding agents, but there is no mention of official SDK client libraries (e.g., Python, JS, Go packages) for Context.dev. Missing for 10: explicit official SDK packages/documentation, language-specific client libraries, versioning/release notes for SDKs.
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
ai-native userSubscribe to events via webhooks
weight 2 · round to FirecrawlFirecrawl's docs explicitly document a Webhooks feature for async event delivery, directly matching the story. Missing for 10: details on event types, payload schema, retry/security guarantees, and independent/hands-on confirmation of webhook usage.
- [claimed-docs] “Webhooks Async event delivery”
Context.dev supports monitoring pages/sitemaps/datasets and receiving 'signed change events' on a schedule, which functions as a webhook-like event delivery mechanism, but the docs never explicitly describe a subscribe/webhook API, event types, delivery retries, or webhook management endpoints. missing for 10: explicit webhook subscription/management API docs, event schema/type documentation, delivery reliability/retry details, and independent confirmation of webhook functionality.
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round drawnFirecrawlnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
Context.devnone0/10Context.dev is a data-extraction/scraping API (Markdown, structured JSON extraction, screenshots, brand data) intended to feed external AI agents and applications, but there is no evidence of the product itself surfacing AI-generated insights, recommendations, or analysis inside a Context.dev interface — it delivers raw/structured data, not in-product AI insight generation.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “retrieve brand profiles with logos, colors, descriptions, and social links through the same API.”
- [claimed-docs] “Connect your AI client to Context.dev tools for live web and company data.”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to Context.devFirecrawl supports webhooks for async event delivery and crawling jobs that run without blocking, which enables background/autonomous data-retrieval workflows, and its MCP server/CLI let agents trigger these jobs programmatically. However there's no evidence of a scheduling/trigger system (e.g., cron-like recurring jobs) or persistent autonomous 'automation' orchestration beyond one-off crawl/extract jobs with webhook callbacks. Missing for 10: scheduled/recurring job support, autonomous multi-step automation orchestration, independent confirmation of long-running background automation reliability.
- [claimed-docs] “Webhooks Async event delivery”
- [github] “Scrape thousands of URLs asynchronously”
- [claimed-docs] “MCP Server: Connect Firecrawl to any AI tool via the Model Context Protocol”
- [probe] “official MCP server documented at https://github.com/mendableai/firecrawl-mcp-server”
Context.dev supports background automation via async batch crawling that runs as a tracked job until completion, and scheduled monitoring of pages/sitemaps/datasets that emits signed change events without user intervention — both run autonomously once configured. However, there's no evidence of a broader automation/workflow engine (e.g., chaining actions, triggering downstream agent tasks, retries/orchestration) beyond these two specific background job types. Missing for 10: evidence of workflow chaining or agent-triggered automation, independent confirmation of monitoring reliability, and details on scheduling flexibility.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round to FirecrawlFirecrawl exposes an 'AI agent' mode where a user describes what they need and the agent searches/navigates/retrieves without URLs, with configurable reasoning effort (firecrawl-gh-1, firecrawl-gh-2) — a limited form of task delegation to an embedded AI. However, this is a narrow scraping/search agent, not a general-purpose in-product assistant, and there's no evidence of a broader conversational assistant UI for delegating arbitrary tasks. Missing for 10: evidence of a general-purpose conversational assistant interface, examples of delegated multi-step tasks beyond search/navigate, and independent confirmation of this agent's real-world reliability.
ai-native userOperate the product with natural-language commands
weight 2 · round drawnFirecrawl offers a natural-language 'search agent' mode ('Describe what you need... No URLs required') and lets users tune agent reasoning effort, which supports NL-driven operation, and its MCP/CLI integrations let AI agents invoke it conversationally through coding assistants. However, most of the product's core surface (scrape, crawl, extract, map) is still driven by structured API calls/schemas rather than free-form natural language commands. Missing for 10: evidence of full NL command coverage across all core endpoints (not just the search agent), and independent hands-on confirmation that NL commands reliably work end-to-end.
- [github] “Describe what you need, and our AI agent searches, navigates, and retrieves it. No URLs required.”
- [github] “Set how much reasoning the agent spends on the task”
- [claimed-docs] “One command installs the Firecrawl CLI, authenticates in your browser, and adds skills to every detected coding agent.”
- [claimed-docs] “MCP Server: Connect Firecrawl to any AI tool via the Model Context Protocol”
- [probe] “official MCP server documented at https://github.com/mendableai/firecrawl-mcp-server”
Context.dev ships an official MCP server ('Connect your AI client to Context.dev tools for live web and company data') and an agent 'skill' file that teaches coding agents how to call the API, which together let AI-native users issue natural-language requests that get translated into API calls; there is also a CLI for scripted/terminal use. However, all natural-language operation is mediated through third-party AI clients (Claude, agents) rather than a native NL interface in Context.dev itself, and no community/hands-on evidence confirms this NL workflow works smoothly in practice. Missing for 10: first-party or independent evidence of actual natural-language usage/output quality via the MCP or skill integration, and any native chat/NL interface within the product itself.
- [claimed-docs] “Connect your AI client to Context.dev tools for live web and company data.”
- [claimed-docs] “Teach your coding agent how to choose and use the Context.dev API.”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [probe] “official MCP server documented at https://mcp.context.dev/mcp”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userApply a preset configuration tuned for research agents that returns structured, citable output
weight 2 · round drawnFirecrawlnone0/10Firecrawl offers general scraping, structured JSON extraction, and search, but the evidence pack shows no dedicated preset/mode tuned specifically for research agents that returns citable, source-attributed output — no citation formatting, source-tracking, or research-agent-specific configuration is documented.
Context.devnone0/10Context.dev is a web scraping/data extraction API with structured extraction, crawling, and monitoring features, but there is no evidence of a preset or configuration profile specifically tuned for 'research agents' that returns structured, citable output (e.g., with source attribution/citations). The extraction guide supports JSON Schema output but nothing about citation tracking or a research-agent preset.
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnFirecrawlnone0/10No evidence of an interactive API reference or runnable-example playground; the OpenAPI/swagger probe explicitly returned 404s at all candidate paths, and docs items only describe features, not an interactive reference experience.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.firecrawl.dev/openapi.json, https://docs.firecrawl.dev/swagger.json, https://docs.firec…”
Context.devnone0/10Evidence confirms docs, guides, and an OpenAPI spec exist, but nothing indicates an interactive reference with runnable/try-it-out examples (no Swagger/Redoc playground, no 'try it' feature mentioned).
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to Context.devFirecrawlnone0/10A direct probe for OpenAPI/Swagger spec files at all standard locations (openapi.json, swagger.json, etc.) returned 404s, and no other evidence pack item mentions a downloadable machine-readable API spec; only an llms.txt documentation index was found, which is not an OpenAPI-equivalent spec.
A probe confirms a live OpenAPI JSON spec at docs.context.dev/openapi.json (HTTP 200, contains 'openapi' key), directly satisfying the machine-readable spec requirement, alongside first-party docs describing the API surface. Missing for 10: independent third-party corroboration of spec completeness/versioning beyond the probe check.
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round drawnFirecrawlnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnFirecrawlnone0/10The docs reference a 'v2' API version (firecrawl-probe-1), showing some versioning exists, but there is no evidence of a documented deprecation policy, version support timelines, or migration guides, and an OpenAPI spec could not even be located (firecrawl-probe-2). Missing for 10: explicit deprecation policy documentation, versioning/support lifecycle statements, migration guidance for older API versions.
data-engineerThe documented rate limit (requests per second or minute) enforced on my API key before throttling kicks in
weight 3 · round to Context.devFirecrawlnone0/10No evidence pack item documents specific rate limits (requests per second/minute) per API key or plan tier; only general product features and community commentary are present.
Docs confirm a per-minute rate limit exists and that authenticated responses expose rate-limit headers, but no specific numeric threshold (requests/sec or /min) is given in the evidence. Missing for 10: the actual documented numeric limit value, guidance on limits per plan/key tier, and confirmation via headers example showing remaining/limit values.
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
Anti bot — getting past bot defenses — CAPTCHAs, fingerprinting, blocksAnti bot
Getting past bot defenses — CAPTCHAs, fingerprinting, blocks
Block evasion
ai-native userHave an agent automatically get past a CAPTCHA, login, or form wall without my manual intervention
weight 2 · round to FirecrawlFirecrawl's docs support form-filling, clicking, and navigating via a 'Browser Sandbox' for interactive workflows (firecrawl-docs-3, firecrawl-docs-8), and community comments reference actual CAPTCHA 'solves' being consumed at cost (firecrawl-comm-6), suggesting some automated CAPTCHA handling exists in practice. However, there is no first-party documentation explicitly claiming automatic CAPTCHA bypass or login-wall traversal, and community sentiment flags cost/reliability friction rather than seamless unattended operation. Missing for 10: explicit vendor documentation of CAPTCHA-solving/login automation, and independent hands-on confirmation that it reliably completes login flows without manual steps.
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [community] “same setup here for news pages. tier 3 is where my money went, 320 solves a day and 10gb of proxy gone in two days.”
- [community] “Quite useful. Currently we do overpay for the services [referring to Firecrawl-like scraping services].”
Context.devnone0/10Context.dev is a web scraping/crawling/data-extraction API; there is no evidence of CAPTCHA-solving, login/session automation, or form-wall bypass capability. Community comments even question its handling of restricted/anti-scraping sites, and no docs describe login or CAPTCHA handling.
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “\"Websites can opt out of our service, and we respect these requests and add them to our block list.\" I.e: robots.txt already exists and is…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
data-engineerAutomatically retry through a chain of different proxies when anti-bot detection blocks a request
weight 2 · round drawnFirecrawlnone0/10No evidence describes proxy rotation or anti-bot retry chains; the only relevant community comment explicitly states Firecrawl lacks a proxy service, which is core to bypassing anti-bot blocks.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.devnone0/10No documentation or evidence describes proxy rotation, proxy-chain retries, or anti-bot bypass mechanisms; a community comment explicitly notes the homepage never mentions IP rotation or residential proxies, reinforcing the absence of this capability.
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
developerUse an undetected browser mode to bypass sophisticated bot detection systems
weight 3 · round drawnFirecrawlnone0/10Evidence mentions a 'Browser Sandbox' for managed browser sessions and general scraping/crawling features, but there is no documentation or claim of a stealth/undetected browser mode specifically designed to bypass sophisticated bot detection. Community comments (e.g., proxy tiers, captcha solves) hint indirectly at anti-bot infrastructure but do not confirm an official 'undetected mode' feature. missing for 10: explicit stealth/undetected browser mode docs, technical details on bypassing bot detection (fingerprint spoofing, TLS/JA3 randomization, etc.), independent verification of bypass success.
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [community] “same setup here for news pages. tier 3 is where my money went, 320 solves a day and 10gb of proxy gone in two days.”
Context.devnone0/10No evidence in the pack claims an 'undetected browser' or anti-bot-bypass mode; the docs describe scraping, crawling, screenshots, and browser actions but never mention stealth/anti-detection techniques, and community comments explicitly question whether the product uses rotating/residential IPs at all, suggesting no such capability is documented.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
Proxy rotation
developerRequest a proxy from a specific country to get geolocation-appropriate content
weight 2 · round drawnFirecrawlnone0/10No evidence in the pack shows Firecrawl offering country-specific or geolocation proxy selection; in fact a community comment explicitly states Firecrawl lacks a proxy service entirely, and no docs or GitHub references mention proxy/geolocation features.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.devnone0/10No documentation or feature mentions country-specific proxy selection or geolocation control; community comments even question whether Context.dev uses rotating/residential proxies at all, suggesting no such capability exists.
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
developerUse premium residential or datacenter proxies to bypass sites that are hard to scrape
weight 3 · round drawnFirecrawlnone0/10The evidence pack contains no vendor documentation mentioning residential or datacenter proxy support; in fact a community source explicitly states 'Firecrawl... don't have proxy service which is the heart of any crawler and scraper' (firecrawl-comm-3). No official docs or GitHub features reference proxy rotation, IP pools, or anti-bot proxy tiers.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.devnone0/10No documentation or product page mentions residential/datacenter proxies, IP rotation, or anti-bot bypass infrastructure; community comments explicitly note the absence of any proxy mention and question whether the product can handle high-value/anti-scraping targets like LinkedIn.
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
developerRoute requests through a rotating pool of proxy IPs to avoid blocks
weight 3 · round drawnFirecrawlnone0/10No first-party documentation or GitHub evidence claims a rotating proxy pool feature; in fact community commentary explicitly states Firecrawl 'don't have proxy service which is the heart of any crawler and scraper.' Without vendor claims to dispute, this is simply unevidenced.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.devnone0/10No documentation or product page mentions proxy IP rotation, residential proxies, or anti-blocking infrastructure; a community comment on Hacker News explicitly notes the homepage never mentions 'ip' and questions whether rotating/residential proxies are used at all.
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
developerRoute multiple requests through the same proxy IP using a session identifier to maintain a consistent identity
weight 2 · round drawnFirecrawlnone0/10No evidence that Firecrawl exposes a session-identifier parameter to pin requests to the same proxy IP; the closest evidence is a community comment stating Firecrawl lacks its own proxy service entirely, which undercuts rather than supports this specific anti-bot capability.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.devnone0/10No documentation or product page mentions session-based IP persistence, sticky sessions, or proxy identity management; the crawl/scrape/extract guides only cover content retrieval, not proxy control. A community comment even flags the total absence of any IP/residential-proxy discussion on the site, reinforcing that this capability isn't offered.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to FirecrawlFirecrawl explicitly supports bulk operations at scale: crawling entire websites, scraping thousands of URLs asynchronously, batch discovery of URLs, and async webhook delivery for large jobs. This directly matches an AI-native user's need to operate across many items at once. Missing for 10: independent hands-on benchmarks validating throughput/reliability at scale and more detail on rate limits/error handling for bulk jobs.
- [github] “Crawl an entire website and get content from all pages.”
- [github] “Discover all URLs on a website instantly.”
- [github] “Scrape thousands of URLs asynchronously”
- [claimed-docs] “Webhooks Async event delivery”
Docs describe genuine bulk capability: async crawl jobs processing up to 25,000 pages in the background with progress tracking, plus a smaller 500-page synchronous crawl mode, which cover bulk operations across many web pages. However, evidence doesn't show bulk operations across arbitrary item sets (e.g., batch brand lookups, batch document parsing, or bulk extraction across a list of disparate items) beyond website crawling, and there's no independent/hands-on corroboration of large-scale batch reliability. Missing for 10: evidence of bulk/batch endpoints beyond crawling (e.g., batch document conversion, batch structured extraction across arbitrary item lists), and third-party validation of large-scale batch performance.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Context.devFirecrawl offers webhooks for async event delivery (e.g., notifying when a crawl job completes), which is the only automation-adjacent capability in the evidence; there's no documented rule-definition engine or conditional trigger system for defining custom actions on events. Missing for 10: a rules/trigger engine, conditional logic, or action-chaining beyond simple webhook notifications, and any independent confirmation of automation depth.
- [claimed-docs] “Webhooks Async event delivery”
Context.dev supports watching a page, sitemap, or dataset on a schedule and receiving signed change events, which functions as an event-trigger mechanism, but this is presented as a single monitoring feature rather than a general rule-definition system with configurable conditions and varied actions. Missing for 10: evidence of a rules/conditions engine, multiple trigger types beyond scheduled monitoring, and configurable downstream actions (e.g., webhooks to arbitrary endpoints, multi-step workflows).
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to Context.devFirecrawlnone0/10Firecrawl offers webhooks for async event delivery and async crawling/scraping, but there is no evidence of a scheduler or recurring-job/workflow feature (e.g., cron-based crawls or scheduled scrape jobs).
The docs describe a monitoring feature that watches a page, sitemap, or dataset 'on a schedule' and emits signed change events (context-dev-docs-9), which is a form of recurring job scheduling, but this is scoped only to change-detection, not general recurring crawl/extract/workflow jobs. Missing for 10: evidence of cron-style scheduling for arbitrary crawl/extract jobs, workflow chaining, or a broader job-scheduling API beyond the single 'monitor' feature.
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
Dev experience — day-to-day developer experience — setup friction, docs, debugging, iteration speedDev experience
Day-to-day developer experience — setup friction, docs, debugging, iteration speed
Collaboration
developerShare scrapers with teammates and manage organizations and role-based permissions
weight 2 · round drawnFirecrawlnone0/10No evidence pack items mention team collaboration, organizations, workspaces, or role-based access control for sharing scrapers; documentation focuses on scraping, extraction, CLI, and MCP features only.
Context.devnone0/10No evidence of team/organization features, shared scraper workflows, or role-based permission management beyond restricted API keys, which is a single-key scoping mechanism, not team/org collaboration. Missing for 10: organization/team creation, member invites, role-based access control across users, shared scraper/workflow assets.
- [claimed-docs] “Choose **Restricted** when an integration needs only selected operations; a restricted key with no permissions cannot call the API.”
Deployment flexibility
developerBuild and deploy custom serverless scraping scripts on the platform without managing my own infrastructure
weight 2 · round drawnFirecrawlnone0/10Firecrawl's evidence shows a fixed API/SDK/CLI for scraping, crawling, extracting, and search, plus webhooks and an MCP server — but nothing about writing and deploying custom serverless scripts or actor-style code that runs on Firecrawl's own infrastructure (unlike platforms such as Apify Actors). No docs, GitHub, or community evidence mentions custom script deployment or a functions/actors runtime.
Context.devnone0/10Context.dev exposes a fixed set of hosted scraping endpoints (crawl, extract, screenshot, monitor, parse) accessed via API/CLI/MCP, but there is no evidence of a mechanism for developers to write and deploy their own custom scraping scripts or actors on the platform's infrastructure. This is a fair question for a web-scraping-as-a-service category, so absence of evidence yields 'none' rather than 'na'.
developerDeploy the scraping service via a Docker container for production use
weight 2 · round drawnFirecrawlnone0/10The evidence confirms Firecrawl is open source (AGPL-3.0) and self-hostable, but no citation mentions Docker, docker-compose, or containerized deployment instructions for production use.
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
developerSelf-host an open-source version of the scraper instead of relying on a hosted cloud service
weight 2 · round to FirecrawlFirecrawl is explicitly confirmed open source under AGPL-3.0 with the cloud version noted as having 'additional features', confirming self-hosting is possible but with reduced functionality (firecrawl-gh-6). Community commentary corroborates this, noting the self-hosted version lacks the proxy service considered 'the heart' of a scraper and other missing capabilities like screenshots (firecrawl-comm-3, firecrawl-comm-4). Missing for 10: first-party self-hosting setup/docker docs, explicit feature-parity comparison, and independent hands-on confirmation of a smooth self-host deployment experience.
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
- [community] “Interesting... Looks like it would be good for RAG. Maybe add Ollama support for local hosting?”
Context.devnone0/10No evidence anywhere in the pack of an open-source or self-hostable version of Context.dev; it is presented exclusively as a hosted cloud API/service with CLI, MCP server, and SDKs pointing to context.dev endpoints. Missing for 10: any open-source repo, self-hosting instructions, Docker image, or license permitting local deployment.
Integrations
developerConnect the scraping API to no-code automation platforms like n8n or Zapier through a prebuilt connector
weight 2 · round drawnFirecrawlnone0/10No evidence of a prebuilt n8n or Zapier connector; docs mention MCP server, CLI, SDKs, and webhooks but nothing about no-code automation platform integrations.
Library compatibility
developerBuild scrapers using popular open-source automation libraries like Playwright, Puppeteer, Selenium, or Scrapy
weight 2 · round drawnFirecrawlnone0/10Firecrawl is a hosted scraping/crawling API with its own primitives (scrape, crawl, extract, browser sandbox) rather than a framework for developers to write Playwright/Puppeteer/Selenium/Scrapy scripts; there is no documented support for plugging in or building on these open-source libraries. A community comment even notes Firecrawl internally uses Puppeteer (not user-selectable) and lacks the openness these libraries provide, contradicting any claim of multi-library dev flexibility.
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
Migration lock in
developerExport my scraped data and job configurations in a portable format to migrate to another provider without lock-in
weight 3 · round to FirecrawlFirecrawl's outputs (markdown/HTML/structured JSON) are inherently portable formats, and its open-source AGPL-3.0 license means self-hosting/forking is possible, reducing lock-in — but there is no documented feature for exporting job configurations, crawl settings, or webhooks setups for migration to another provider. missing for 10: explicit job-configuration export/import tooling, migration guides, or documented data-portability features beyond raw scrape output formats.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
- [community] “Finally, people starting to realize that AGPL means you can just fork and remove everything you don't like (including branding).”
Quickstart
developerPublish my custom scraper to a public marketplace and earn revenue when others use it
weight 1 · round drawnFirecrawlnone0/10The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)
developerRun a ready-made scraper from a marketplace instead of building one from scratch
weight 2 · round drawnFirecrawlnone0/10No evidence of a marketplace of ready-made scrapers/templates that developers can pick up and run; Firecrawl's evidence covers building scraping/crawling calls via API, CLI, MCP, and SDKs, not a curated marketplace of pre-built scrapers.
Context.devnone0/10Context.dev's evidence describes a general-purpose scraping/crawling/extraction API, CLI, and MCP server that developers configure themselves, but no marketplace of pre-built, ready-made scrapers for specific sites/use-cases is mentioned anywhere in the docs, community discussion, or probes.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
developerStart building immediately using a library of ready-made project templates
weight 1 · round drawnFirecrawlnone0/10Evidence shows CLI, SDKs, MCP server, and API docs, but nothing about a library of ready-made project templates or starter projects to jumpstart development.
Extraction quality — how faithfully content is extracted — structure, fidelity, edge casesExtraction quality
How faithfully content is extracted — structure, fidelity, edge cases
Ai extraction
developerExtract structured data from a page using natural language instructions instead of writing selectors
weight 3 · round to Context.devFirecrawl's Extract feature lets developers get structured JSON via schemas and its agent can be described in natural language to find/retrieve content without URLs, but the evidence pack shows schema-based extraction more than fully free-form natural-language field extraction replacing selectors. Missing for 10: explicit documentation of prompt-only (no schema) extraction, and independent hands-on confirmation of extraction accuracy.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Use a schema to get structured data:”
- [github] “Describe what you need, and our AI agent searches, navigates, and retrieves it. No URLs required.”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
Docs describe an extract endpoint that crawls relevant pages and returns an object matching a JSON Schema with controls for grounding, coverage, and freshness—no CSS/XPath selectors required, just a schema/instructions-driven approach. Missing for 10: no explicit mention of natural-language instruction fields (vs. schema-only), no independent hands-on benchmark of extraction accuracy/quality.
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “retrieve brand profiles with logos, colors, descriptions, and social links through the same API.”
developerPass a JSON schema so the API returns structured data matching that schema
weight 2 · round drawnFirecrawl's docs and GitHub explicitly advertise passing a JSON schema to extract structured data ("Use a schema to get structured data") and general structured JSON extraction from URLs, PDFs, and other formats. Missing for 10: independent/hands-on confirmation of schema-conformance accuracy and edge-case handling beyond vendor docs.
- [github] “Use a schema to get structured data:”
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
Docs explicitly describe extracting structured data by supplying a JSON Schema, with the API returning an object matching it, plus controls for grounding, coverage, and freshness; an OpenAPI spec is also available for verification. Missing for 10: independent hands-on confirmation of schema-conformance accuracy and no explicit mention of schema validation/error handling edge cases.
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
ai-native userHave an LLM read a page and decide what structured fields to pull out without pre-written selectors
weight 2 · round drawnFirecrawl's docs and GitHub note schema-based structured extraction ("Use a schema to get structured data") and general LLM-driven content extraction to JSON, which aligns with selector-free, LLM-decided field extraction. However, evidence doesn't show prompt-only (schema-less) extraction quality, nor independent verification of how well the LLM infers fields without any schema hints. missing for 10: evidence of extraction working from a pure natural-language prompt without any schema, and independent/hands-on validation of extraction accuracy.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Use a schema to get structured data:”
- [github] “Describe what you need, and our AI agent searches, navigates, and retrieves it. No URLs required.”
The extract-structured-data guide shows the product accepts a JSON Schema and returns matching structured data with grounding/coverage controls, which fits an LLM-driven extraction without pre-written CSS/XPath selectors. However, the evidence doesn't explicitly describe the underlying mechanism as an LLM 'deciding' fields freely versus schema-guided extraction, and there's no example of open-ended field discovery without a supplied schema. Missing for 10: evidence of schema-less/free-form field discovery, and independent hands-on confirmation of extraction quality without selectors.
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
developerPlug in a local or self-hosted LLM as the extraction backend instead of a cloud-only model
weight 2 · round drawnFirecrawlnone0/10No evidence that Firecrawl allows swapping in a local or self-hosted LLM as the extraction backend; a community comment even suggests adding Ollama support as a future wish, implying it isn't currently offered.
- [community] “Interesting... Looks like it would be good for RAG. Maybe add Ollama support for local hosting?”
Basic scraping
developerScrape a web page with a single API call and get its raw HTML back
weight 3 · round to FirecrawlFirst-party docs explicitly state that Firecrawl's scrape endpoint extracts content from any URL as markdown, HTML, or structured JSON in a single call, directly matching the story. A community comment raises a narrow caveat about HTML not being returned in a separate 'daemon mode', but this does not contradict the main scrape API. Missing for 10: independent hands-on confirmation of raw HTML output quality/fidelity for the primary scrape endpoint.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Context.dev's primary scrape endpoints convert pages to Markdown by default (docs-1, docs-2), and raw HTML is only mentioned as an output option for the async batch-crawl job that must be polled for completion (docs-3), not as an immediate single-call response for a single page. This satisfies the general 'scrape a page via API' need but not the specific 'single call → raw HTML' expectation. Missing for 10: documented synchronous single-page endpoint that returns raw HTML directly, independent confirmation of HTML fidelity/quality.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
Data safety
data-engineerAutomatically detect and filter personally identifiable information out of scraped content before it reaches storage
weight 2 · round drawnFirecrawlnone0/10No evidence in the pack mentions PII detection, redaction, or filtering capabilities; Firecrawl's documented features cover scraping, extraction, crawling, and structured output but nothing about privacy/PII compliance controls.
Document extraction
data-engineerExtract text content from PDFs, Word, Excel, and PowerPoint files without hosting them myself
weight 2 · round drawnFirecrawl explicitly documents converting local PDFs, DOCX, XLSX, HTML and more into Markdown or structured JSON as a hosted (cloud) service, directly matching the story of extracting text from PDFs/Word/Excel/PowerPoint without self-hosting. Missing for 10: explicit mention of PowerPoint (.pptx) support and independent hands-on confirmation of file-parsing quality/accuracy.
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
Docs explicitly describe a 'parse-documents' API that converts PDFs, Office documents, and spreadsheets into Markdown, including OCR recovery for scanned PDFs, delivered as a hosted API (no self-hosting required). Missing for 10: independent/hands-on verification of extraction quality and no explicit mention of PowerPoint file type beyond generic 'Office documents'.
- [claimed-docs] “Convert PDFs, Office documents, spreadsheets, and other files into Markdown. Recover scanned PDF pages with optional OCR.”
Multimodal extraction
ai-native userGet automatic captions for images on a page so a text-only model can reason about visual content
weight 2 · round drawnFirecrawlnone0/10No evidence Firecrawl generates automatic image captions or alt-text descriptions for visual content; evidence only covers text/HTML/markdown extraction, crawling, and structured data extraction.
Context.devnone0/10No evidence of automatic image captioning or alt-text generation for visual content; the product's extraction focuses on Markdown/JSON/screenshots and document parsing, not describing images for text-only models. Missing for 10: any mention of image captioning, vision-to-text description, or alt-text generation feature.
Search integration
developerSearch the web and get full page content from results in a single call instead of just links and snippets
weight 3 · round to FirecrawlFirecrawl's docs explicitly advertise a search endpoint that returns full page content from results in one call, matching the story exactly, and this is backed by broader scrape/extract capabilities showing it can fetch full markdown/HTML/structured content rather than just snippets. Missing for 10: independent hands-on verification of the search+content endpoint specifically (community evidence discusses scraping/crawling generally but not this exact combined search feature).
- [claimed-docs] “Search the web and get full page content from results in one call.”
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Describe what you need, and our AI agent searches, navigates, and retrieves it. No URLs required.”
Context.devnone0/10Context.dev's documented capabilities are URL-based (crawl, scrape, extract, sitemap discovery, screenshot, document parsing, monitoring) but no evidence shows a web-search endpoint that returns full page content for search results in one call — 'discover website URLs' only reads a site's own sitemap, not the open web.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Read a website's public sitemaps and return a filtered URL list without rendering each page.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
Selector extraction
developerExtract specific fields from a page using CSS or XPath selector rules
weight 3 · round drawnFirecrawlnone0/10Evidence shows Firecrawl's extraction relies on schema-based/LLM extraction (firecrawl-gh-7) and general markdown/HTML/JSON output (firecrawl-docs-1), but nothing in the pack documents CSS or XPath selector-based field extraction rules. Missing for 10: any mention of CSS selector or XPath rule support in scrape/extract config, docs page confirming selector-based extraction, or independent confirmation of this capability.
- [github] “Use a schema to get structured data:”
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
Structured data handling
data-engineerExtract data from very large tables using intelligent chunking so it fits within processing limits
weight 1 · round drawnFirecrawlnone0/10No evidence pack items mention table extraction, large-table handling, or intelligent chunking strategies for oversized data; the evidence only covers general scraping, crawling, and structured extraction features. missing for 10: any mention of table-specific extraction, chunking mechanisms, or handling of oversized documents/tables to fit token/processing limits.
Js rendering — handling JavaScript-heavy pages — rendering, waiting, dynamic contentJs rendering
Handling JavaScript-heavy pages — rendering, waiting, dynamic content
Headless rendering
developerRender JavaScript-heavy single-page applications and get the fully rendered HTML
weight 3 · round to FirecrawlDocs confirm Firecrawl scrapes pages with an actual browser session ('Browser Sandbox... managed browser sessions for interactive workflows', 'click, fill forms, extract dynamic content'), and community evidence confirms it uses a real headless browser (Puppeteer) to render pages rather than static HTTP fetch, which supports JS-heavy SPA rendering. Output can be returned as HTML per docs-1. Missing for 10: independent benchmark/proof of correctly rendering complex SPAs, and community notes it uses Puppeteer not Playwright with some limitations in certain modes.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
Context.dev supports browser actions (click/wait/scroll) before scraping, and screenshot rendering, implying JS execution via a real browser, and crawl/scrape guides return Markdown/HTML output — suggesting rendered SPA content is retrievable. However, there is no explicit statement that scraping fully executes JavaScript-heavy SPAs or waits for hydration/network-idle by default, and no independent/hands-on confirmation of SPA rendering fidelity. missing for 10: explicit documentation confirming full JS/SPA rendering (e.g., wait-for-network-idle, headless browser execution) as default behavior, and independent verification of rendered output correctness for JS-heavy sites.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
- [claimed-docs] “Render an exact URL or a resolved site page and return a viewport, full-page, or offset PNG capture.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
developerHave the API wait for a specific selector to appear before returning the rendered page
weight 2 · round to Context.devFirecrawlnone0/10No evidence pack item mentions waiting for a specific CSS selector before returning rendered content; only general mentions of scraping, interactive actions, and browser sandboxing are present without detail on selector-based wait conditions.
Docs describe browser actions supporting 'wait' among click/scroll before scraping or extracting a page, which directly matches waiting for content before returning rendered output, but there's no explicit mention of waiting for a CSS/DOM selector specifically (vs. fixed delays) nor independent confirmation of this behavior. missing for 10: explicit selector-based wait documentation, example showing selector syntax, independent/hands-on verification.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
Interactive automation
developerAccess a managed remote browser sandbox for interactive, manual browsing workflows
weight 2 · round to FirecrawlFirecrawl docs explicitly mention a 'Browser Sandbox' offering managed browser sessions for interactive workflows, plus 'scrape, then keep working with it: click, fill forms, extract dynamic content' — directly matching the story. However, this is only a single doc snippet with no detail on session persistence, remote access UI, or manual/human-driven browsing versus API-driven automation, and no independent/community corroboration of this specific feature. Missing for 10: detailed documentation on session duration/access model, evidence of true manual/interactive human use (vs agent-driven), and third-party confirmation.
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
developerKeep interacting with an already-scraped page, clicking and filling forms to reach content behind a login wall
weight 2 · round to FirecrawlFirecrawl's docs explicitly describe an interactive workflow — 'Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper' — plus a 'Browser Sandbox' for managed interactive browser sessions, directly matching the story. Missing for 10: independent/hands-on corroboration that clicking/filling forms actually reaches login-walled content, and more detail on session persistence across interactions.
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
Context.dev documents browser actions (click, wait, scroll) that can run before a scrape or extraction, which supports some interactive page manipulation, but there is no evidence of form-filling, typing credentials, or a persistent multi-step session capable of reaching authenticated/login-walled content. Missing for 10: explicit support for filling login forms/typing input, session/cookie persistence across interactions, and any documented login-wall use case or example.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
developerScript page interactions like clicking, filling inputs, and scrolling before content is returned
weight 3 · round to Context.devFirecrawl's docs explicitly describe scripting page interactions—click, fill forms, extract dynamic content, navigate deeper—after an initial scrape, and mention a managed Browser Sandbox for interactive workflows, directly matching the story of clicking/filling/scrolling before content is returned. Missing for 10: detailed API reference for the specific 'actions' parameter (e.g. scroll behavior), and independent/hands-on confirmation from community sources that these interaction primitives work reliably in practice.
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
Docs explicitly describe a browser-actions capability allowing click, wait, or scroll before scraping/extracting content, with success verification, directly matching the story. Missing for 10: independent/hands-on corroboration of scripted interactions beyond first-party docs, and no detail on filling form inputs specifically.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
Render configuration
developerControl the browser viewport width and height when rendering a page
weight 1 · round to Context.devFirecrawlnone0/10No evidence in the pack mentions viewport width/height, mobile emulation, or screen size configuration for rendering pages; the docs mention scraping, actions, and a browser sandbox but nothing about viewport control.
The screenshot guide mentions a 'viewport' capture mode alongside full-page and offset options, implying some viewport-based rendering, but no evidence specifies developer control over exact width/height dimensions. missing for 10: explicit API parameters for setting viewport width and height, documentation confirming custom viewport sizing, and any hands-on confirmation.
- [claimed-docs] “Render an exact URL or a resolved site page and return a viewport, full-page, or offset PNG capture.”
Session persistence
developerPass my own session cookies so the API fetches pages requiring authentication
weight 2 · round drawnFirecrawlnone0/10No evidence pack item mentions passing custom cookies, headers, or session/auth tokens to Firecrawl's scrape API; only generic scraping, crawling, and browser-sandbox features are documented.
developerReuse a persistent browser profile with saved cookies and login state across multiple requests
weight 2 · round drawnFirecrawlnone0/10The evidence mentions a 'Browser Sandbox' for managed sessions and interactive workflows, but nothing describes persisting cookies/login state or reusing a browser profile across multiple separate requests. No docs, SDK, or community evidence confirms this capability.
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
Context.devnone0/10No evidence of persistent browser profiles, saved cookies, or reusable login/session state across requests; browser-actions doc only covers click/wait/scroll per single request. Missing for 10: any mention of persistent sessions, cookie storage, authentication state reuse, or profile management across multiple API calls.
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to Context.devFirecrawl is fundamentally API-first — scrape, crawl, extract, search, and structured data features are all exposed via API/SDKs and docs, and there is no evidence of a rich standalone UI with capabilities withheld from the API. However, the evidence pack lacks a discoverable OpenAPI spec (probe found 404s) and does not explicitly confirm dashboard-only features (e.g., billing, team management, job monitoring) are also API-accessible. missing for 10: a published OpenAPI/swagger spec, explicit confirmation that all dashboard/UI-only functions (usage analytics, team/billing management, job history) are API-reachable, and independent verification of full UI/API parity.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Search the web and get full page content from results in one call.”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [github] “Crawl an entire website and get content from all pages.”
- [github] “Scrape thousands of URLs asynchronously”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.firecrawl.dev/openapi.json, https://docs.firecrawl.dev/swagger.json, https://docs.firec…”
- [probe] “official CLI documented at https://docs.firecrawl.dev/sdks/cli”
Context.dev is API-first: the product's core functions (crawl, extract, screenshot, monitor, brand data) are all documented as API endpoints with an OpenAPI spec, and the CLI/MCP/skill installs are just wrappers around that same API, implying no UI-exclusive functionality. missing for 10: explicit confirmation that the web UI itself exposes zero features unavailable via API (e.g., dashboard-only settings) and independent hands-on verification of full parity.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://docs.context.dev/install-cli”
ai-native userExport all of my data in open formats and leave
weight 3 · round to FirecrawlFirecrawl outputs are natively in open formats (markdown, HTML, structured JSON) and the core engine is open source (AGPL-3.0), letting a user self-host and avoid lock-in to the hosted service. However there's no explicit 'export all your account/config data' feature documented, and community notes only touch on forking rights, not a formal data-export path. Missing for 10: a documented account-data export/migration flow, evidence of exporting crawl history/settings, and independent confirmation users have actually migrated off the hosted service.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
- [community] “Finally, people starting to realize that AGPL means you can just fork and remove everything you don't like (including branding).”
Context.dev's outputs (Markdown, JSON, HTML) are inherently open, portable formats rather than proprietary lock-in formats, and structured extraction lets users get their scraped/monitored data in JSON Schema-conformant form (docs-1, docs-3, docs-4, docs-9). However there is no explicit account-level 'export all your data and leave' feature (e.g., bulk export of saved crawls, monitors, API key configs, or account deletion with data portability) documented anywhere in the evidence. Missing for 10: dedicated account/data export tooling, documentation of account deletion/data portability guarantees, and independent confirmation that historical crawl/monitor data can be bulk-exported.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
ai-native userRead the product's source under an open license
weight 2 · round to FirecrawlFirecrawl's GitHub repo confirms it is open source under the AGPL-3.0 license, with community discussion also confirming this (including implications of AGPL forking rights). Source is publicly readable on GitHub with an OSI-approved-family open license. Missing for 10: no evidence of clarity on which parts of the cloud-only features are excluded from the open license, and no independent audit of full repo completeness.
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
- [community] “Finally, people starting to realize that AGPL means you can just fork and remove everything you don't like (including branding).”
ai-native userSelf-host the core product
weight 3 · round to FirecrawlFirecrawl's GitHub repo confirms the core product is open source under AGPL-3.0 and can be self-hosted, with the hosted cloud version offering extra features (firecrawl-gh-6). However, community reports note self-hosted/simple versions lack key production features like proxy support and have functional limitations (e.g., daemon mode restrictions, no HTML return) compared to the cloud offering (firecrawl-comm-3, firecrawl-comm-4). Missing for 10: official self-hosting setup docs/guide in the evidence pack, and confirmation that self-hosted deployment achieves full feature parity with the hosted service.
- [github] “Firecrawl is open source under the AGPL-3.0 license. The cloud version at firecrawl.dev includes additional features”
- [community] “As I see, you use Puppeteer, not Playwright. Also, both Firecrawl and Firecrawl Simple are really simple, and most importantly don't have pr…”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Output formats — stories about output formats in this arenaOutput formats
Stories about output formats in this arena
Content formats
developerReceive scraped content as clean markdown instead of raw HTML
weight 3 · round to FirecrawlFirst-party docs explicitly state extraction as markdown (alongside HTML/JSON) and support converting local files to markdown, confirming clean markdown output is a core, well-documented feature. Missing for 10: independent hands-on confirmation specifically praising markdown output quality/cleanliness.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
First-party docs consistently describe scraping/crawling output as Markdown (sync and async crawl endpoints, single-page scrape, document parsing all return Markdown rather than raw HTML), and this is corroborated by a customer case study (SiteGPT) using it to build a knowledge base. Missing for 10: independent hands-on verification of markdown output quality/cleanliness and no explicit sample output shown.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Convert PDFs, Office documents, spreadsheets, and other files into Markdown. Recover scanned PDF pages with optional OCR.”
- [claimed-docs] “SiteGPT, the AI chatbot platform for customer support, switched from Firecrawl to Context.dev to scrape entire websites and turn them into t…”
developerChoose exactly which output format is returned, such as markdown, HTML, text, or frontmatter
weight 2 · round drawnDocs confirm output as markdown, HTML, or structured JSON (firecrawl-docs-1, firecrawl-docs-6), and a community comment notes a daemon-mode limitation where HTML return is unsupported in some contexts, suggesting partial reliability. No explicit mention of 'frontmatter' or 'text' formats, and no documentation snippet showing a format-selection parameter/API example. Missing for 10: explicit mention of frontmatter/text format options, and a documented parameter/example showing developers selecting formats.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Docs show explicit format choice for Markdown (sync/async crawl) and HTML (async crawl), plus JSON output via structured extraction, but no mention of plain 'text' or 'frontmatter' output options anywhere in the docs. missing for 10: explicit text output mode, frontmatter output mode, independent confirmation of format selection working in practice.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
developerReceive scraped content as structured JSON
weight 3 · round to FirecrawlFirecrawl docs explicitly support extracting content as structured JSON, including with a defined schema, alongside markdown/HTML options, and this extends to document formats like PDFs/DOCX as well. Missing for 10: independent hands-on confirmation of JSON output quality/schema fidelity beyond vendor docs and GitHub README.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [github] “Use a schema to get structured data:”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
Docs explicitly describe extracting structured JSON matching a user-supplied JSON Schema from crawled pages, with controls for grounding, coverage, and freshness, plus an OpenAPI spec confirming API-driven JSON responses and a CLI that returns JSON for scripting/CI. missing for 10: independent hands-on verification of JSON extraction accuracy/quality beyond vendor docs.
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [probe] “PROBE openapi: HTTP 200 at https://docs.context.dev/openapi.json — contains "openapi" key”
- [claimed-docs] “Call Context.dev from your terminal and use JSON responses in scripts or CI.”
Llm ready output
ai-native userGet clean LLM-ready text directly instead of dealing with blocking, rendering, and messy HTML myself
weight 3 · round drawnFirecrawl's core value proposition is turning any URL into clean markdown/structured JSON, handling rendering, JS-heavy pages, and blocking via a managed browser sandbox, explicitly for LLM/RAG use cases. Docs and GitHub confirm markdown/HTML/JSON extraction, PDF/DOCX conversion, and managed browser sessions abstracting away rendering complexity, though community comments note some limitations (e.g., proxy/anti-bot gaps, missing HTML in some modes). Missing for 10: independent benchmark of output cleanliness vs raw HTML scraping, and resolution of community-reported edge-case limitations (daemon mode HTML issue).
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Scrape a page, then keep working with it: click, fill forms, extract dynamic content, or navigate deeper.”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
- [claimed-docs] “Browser Sandbox Managed browser sessions for interactive workflows”
- [github] “Crawl an entire website and get content from all pages.”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Context.dev's core offering is scraping/crawling websites directly into clean Markdown (and JSON) for AI agents, handling rendering, browser actions, and document parsing so the user doesn't deal with raw HTML; this is corroborated by docs and a real-world migration story (SiteGPT switching from Firecrawl). missing for 10: independent hands-on benchmark of output cleanliness/quality versus alternatives, and no detail on how well it strips boilerplate/ads beyond doc claims.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Click, wait, or scroll before scraping or extracting a page, then check which interactions succeeded.”
- [claimed-docs] “Convert PDFs, Office documents, spreadsheets, and other files into Markdown. Recover scanned PDF pages with optional OCR.”
- [claimed-docs] “SiteGPT, the AI chatbot platform for customer support, switched from Firecrawl to Context.dev to scrape entire websites and turn them into t…”
ai-native userRequest semantically chunked output instead of one large content blob, so it feeds cleanly into a retrieval pipeline
weight 2 · round drawnFirecrawlnone0/10Firecrawl's evidence covers markdown/HTML/structured JSON extraction, crawling, and PDF/DOCX conversion, but nothing describes a semantic chunking feature or chunked output mode for retrieval pipelines. The axis applies (chunked output is a plausible feature for a scraping/RAG-prep tool) but no evidence shows it exists.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [claimed-docs] “Turn local PDFs, DOCX, XLSX, HTML, and more into Markdown or structured JSON”
- [github] “Use a schema to get structured data:”
Context.devnone0/10Context.dev's docs describe scraping/crawling into full-page Markdown, JSON extraction, and document parsing, but nowhere mention a chunking feature (e.g., configurable chunk size, semantic segmentation, or overlap controls) intended for retrieval pipelines. Output is delivered as whole-page Markdown/HTML/JSON blobs per page, not sub-page semantic chunks.
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Convert PDFs, Office documents, spreadsheets, and other files into Markdown. Recover scanned PDF pages with optional OCR.”
Visual capture
developerCapture a screenshot of a full page or a specific selected area
weight 2 · round to Context.devFirecrawlnone0/10The evidence pack lists output formats as markdown/HTML/JSON but never mentions screenshot capture, full-page or selector-based, as a capability. A community comment even raises it as an open question ('does it support screenshots?') without confirmation, so there's no evidence the capability exists.
- [claimed-docs] “Extract content from any URL as markdown, HTML, or structured JSON”
- [community] “It being vibe coded aside, does it support screenshots? I noticed the daemon mode has a lot of weird limitations too like not being able to …”
Docs explicitly describe rendering an exact URL or resolved page and returning a viewport, full-page, or offset PNG capture, directly matching the story of full-page or selected-area screenshots. Missing for 10: independent/hands-on corroboration of screenshot quality or selector-based area capture beyond viewport/offset options.
- [claimed-docs] “Render an exact URL or a resolved site page and return a viewport, full-page, or offset PNG capture.”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Cost optimization
developerLet the API automatically pick the cheapest configuration that still succeeds
weight 2 · round drawnFirecrawlnone0/10No evidence of automatic cost-optimal configuration selection; docs mention manual controls like reasoning effort but nothing about the API choosing cheapest successful config automatically.
developerBlock ads on the target page to speed up scraping requests
weight 1 · round drawnFirecrawlnone0/10No evidence pack item mentions ad-blocking or any option to strip ads/trackers on target pages to speed up scraping; only general scraping, crawling, and extraction features are documented.
Context.devnone0/10No evidence pack item mentions ad-blocking, resource blocking, or any performance optimization feature to skip ads/media during scraping; the docs cover crawling, extraction, screenshots, and browser actions but never ad-blocking specifically. Missing for 10: any documentation of an ad-block or resource-blocking option, any performance/speed benefit tied to blocking ads.
developerBlock images and CSS resources by default to reduce bandwidth and speed up requests
weight 1 · round drawnFirecrawlnone0/10No evidence pack mentions blocking images or CSS resources, resource-type filtering, or bandwidth-saving scrape options; only general scraping/crawling features are documented.
ai-native userSet how much reasoning effort an autonomous agent spends on a data-gathering task (low, medium, high)
weight 2 · round to FirecrawlGitHub README explicitly states the agent lets users 'set how much reasoning the agent spends on the task,' directly matching the story, but there's no detailed documentation confirming discrete low/medium/high levels or pricing-tied reasoning-effort controls. Missing for 10: first-party docs specifying the exact reasoning-effort parameter/levels, independent confirmation of how this affects cost/limits.
Cost transparency
developerWhether exceeding my plan's monthly credit or request quota triggers overage charges or a hard cutoff
weight 3 · round drawnFirecrawlnone0/10No evidence in the pack addresses billing behavior when a plan's credit/request quota is exceeded — nothing on overage charges vs. hard cutoffs. This is a fair pricing question for a paid API product, so absence of evidence yields none. Missing for 10: any pricing/billing docs describing quota overage policy, hard-stop vs auto-billing behavior, or community reports confirming either.
developerWhether failed, blocked, or empty-result requests still consume my billing quota
weight 2 · round to Context.devFirecrawlnone0/10No evidence pack items discuss billing/credit treatment for failed, blocked, or empty-result requests; documentation snippets cover features (scrape, crawl, MCP, webhooks) but not quota/credit consumption policy.
Docs explicitly state that in the timeout/return-partial flow, if no usable result exists the request 'fails without a charge,' directly addressing billing behavior on failure. However, there's no broader documentation covering all failure modes (e.g., blocked requests, empty-result extractions, rate-limited calls) confirming whether they also skip billing. Missing for 10: explicit policy for blocked requests, empty JSON extraction results, and general error responses beyond the timeout optimization guide; independent/community confirmation of billing behavior.
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
developerSet a spending cap or usage alert so proxy/credit consumption doesn't silently blow past my budget
weight 3 · round drawnFirecrawlnone0/10No evidence of spending caps, budget alerts, or usage-limit notifications; community comments even describe unexpectedly high consumption ('10gb of proxy gone in two days') with no mention of a cap/alert mechanism to prevent overage.
- [community] “same setup here for news pages. tier 3 is where my money went, 320 solves a day and 10gb of proxy gone in two days.”
- [community] “Quite useful. Currently we do overpay for the services [referring to Firecrawl-like scraping services].”
Performance tuning
developerTrade off latency against completeness by controlling exactly when content is returned
weight 1 · round to Context.devFirecrawl offers async webhooks for event delivery and an agent 'reasoning effort' setting that trades speed for thoroughness, plus async bulk scraping — all of which let a developer influence when/how much content comes back, but there's no explicit documented parameter (e.g., wait-time or completeness threshold) framed as a direct latency-vs-completeness control on the standard scrape/crawl endpoints. missing for 10: explicit sync-return timeout/partial-completeness parameter, independent benchmarking of latency vs completeness tradeoffs, and hands-on confirmation of the reasoning-effort knob's effect.
- [github] “Set how much reasoning the agent spends on the task”
- [claimed-docs] “Webhooks Async event delivery”
- [github] “Scrape thousands of URLs asynchronously”
Context.dev offers explicit controls that trade off latency vs completeness: synchronous small crawls (fast, limited to 500 pages) vs async background crawls up to 25,000 pages, plus a 'return-partial' timeout policy that returns usable completed work with a completion marker rather than waiting for full completion. This directly supports controlling when content is returned along a latency/completeness axis, though it's documented only in claimed-docs with no independent hands-on validation of the tradeoff behavior. Missing for 10: independent/community confirmation of the return-partial and sync/async tradeoff working as documented, and more granular mid-request streaming or partial-result controls beyond the two crawl modes and timeout policy.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
Plan scale limits
data-engineerThe maximum concurrent sessions or requests allowed on my pricing tier and the cost to raise that cap
weight 2 · round drawnFirecrawlnone0/10No evidence pack item documents rate limits, concurrency caps per pricing tier, or the cost to raise them; only unrelated product feature docs and community anecdotes about usage cost are present. missing for 10: documented per-tier concurrency/request limits, documented pricing to upgrade limits, any rate-limit or quota API reference.
Context.devnone0/10Docs mention rate-limit headers exist and per-minute limits apply, but there is no evidence of tier-specific concurrency/session caps or the cost to raise them. Missing for 10: documented tier limits table, concrete numeric caps per plan, and pricing/upgrade path to raise the cap.
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnFirecrawlnone0/10No evidence in the pack mentions data residency, regional storage options, or compliance controls for where scraped data is processed/stored; the open-source AGPL version could theoretically be self-hosted for residency control, but this is not documented anywhere in the evidence.
Context.devnone0/10No evidence anywhere in the pack mentions data residency, region selection, or storage location options for Context.dev; the product is a web-scraping/data API with no documented control over where data is stored. Missing for 10: any mention of regional hosting, data residency options, or compliance certifications tied to storage location.
ai-native userPrevent my data from being used to train AI models
weight 3 · round drawnFirecrawlnone0/10No evidence pack item mentions any data-training opt-out, privacy policy on model training use, or data retention/DPA controls for Firecrawl's scraped or user data; the only related community comment raises concerns about scraping others' data, not about protecting the user's own data from AI training use.
ai-native userControl data retention and deletion
weight 2 · round drawnFirecrawlnone0/10No evidence pack item mentions data retention policies, deletion controls, or privacy settings for stored crawl/scrape data; this is a fair question for a cloud scraping/data API but no documentation addresses it.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnFirecrawlnone0/10No evidence in the pack mentions telemetry, usage tracking, analytics collection, or an opt-out setting/flag for Firecrawl's CLI, SDK, or self-hosted deployment; while the open-source AGPL nature suggests self-hosting is possible, nothing documents a telemetry toggle or privacy control.
Scale reliability — behavior under load — scaling limits, uptime, failure handlingScale reliability
Behavior under load — scaling limits, uptime, failure handling
Ai driven crawling
ai-native userRely on adaptive crawling that automatically stops once enough information has been gathered to answer my query
weight 2 · round drawnFirecrawlnone0/10The evidence describes crawling, scraping, and AI agent search/reasoning controls (e.g., firecrawl-gh-1, firecrawl-gh-2), but nothing documents adaptive crawling that automatically halts once sufficient information has been gathered to answer a specific query — crawls appear to run to full site discovery or fixed limits rather than stopping based on information sufficiency.
Context.devnone0/10The docs describe crawling with fixed page caps (500 for sync, 25,000 for async) and extraction with 'coverage' controls, but there is no evidence of an adaptive mechanism that halts crawling once sufficient information for a query has been gathered.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
Batch processing
data-engineerBatch scrape thousands of URLs asynchronously
weight 3 · round to FirecrawlFirecrawl's GitHub docs explicitly advertise batch/async scraping of thousands of URLs, plus webhook-based async event delivery for pipeline integration, and crawl/map endpoints for URL discovery at scale, aligning well with the data-engineer scale story. Missing for 10: independent hands-on benchmarks proving reliability at thousands-of-URL scale and details on rate limits/retry/error handling under batch load.
- [github] “Scrape thousands of URLs asynchronously”
- [claimed-docs] “Webhooks Async event delivery”
- [github] “Crawl an entire website and get content from all pages.”
- [github] “Discover all URLs on a website instantly.”
Docs explicitly describe an async background crawl job handling up to 25,000 pages with progress tracking and retrieval on completion, plus rate-limit headers and partial-result timeout handling that support reliability at scale. However, this is framed as crawling one site rather than an arbitrary list of thousands of distinct URLs, and there is no independent/hands-on evidence confirming real-world throughput or reliability at that scale. Missing for 10: evidence of scraping an arbitrary batch/list of thousands of URLs (not just one site's crawl), independent benchmarks or user reports validating async batch reliability at scale.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
developerApply different crawl configurations to different URL patterns within a single batch job
weight 1 · round drawnFirecrawlnone0/10The evidence pack covers crawling, scraping, extraction, webhooks, and CLI/MCP features, but nothing describes per-URL-pattern configuration overrides within a single crawl/batch job (e.g., different scrape options for different path patterns). No docs or community evidence mention such rule-based configuration.
Context.devnone0/10The docs describe a single batch crawl job (up to 25,000 pages) with one set of settings, but there is no evidence of applying different crawl configurations to different URL patterns within the same job.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
Concurrency
data-engineerSpin up many concurrent scraping sessions to gather data at scale
weight 3 · round to FirecrawlFirecrawl explicitly supports scraping 'thousands of URLs asynchronously' and full-site crawling with async webhooks for event delivery, which supports scaling to many concurrent scrape jobs. However, there is no documentation of concurrency limits, session management, or dedicated infrastructure for spinning up many parallel sessions, and community feedback raises cost/efficiency concerns at scale (proxy usage, cost overpay) without directly disputing the concurrency capability itself. Missing for 10: explicit concurrency/rate-limit documentation, first-party benchmarks or case studies of large-scale concurrent scraping, and independent verification of scale claims.
- [github] “Scrape thousands of URLs asynchronously”
- [github] “Crawl an entire website and get content from all pages.”
- [claimed-docs] “Webhooks Async event delivery”
- [community] “same setup here for news pages. tier 3 is where my money went, 320 solves a day and 10gb of proxy gone in two days.”
- [community] “I made newsagents.app and I ended up using the extract API from kagi and falling back to cloudflare's browser API for problem pages. That lo…”
Context.dev supports large single crawls (up to 25,000 pages async) and exposes rate-limit headers, implying some capacity for scaled scraping, but there is no explicit documentation of running many concurrent scraping sessions or session-level concurrency controls. Community feedback also raises doubts about scaling to high-volume/high-value scraping due to lack of rotating/residential proxy support. missing for 10: explicit concurrency/session-limit documentation, evidence of parallel job orchestration, and independent benchmarks confirming multi-session scale.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
- [community] “Seems wildly expensive, furthermore not a single mention of "ip" on homepage? Not using rotating ip's, residential proxies? AKA unusable for…”
- [community] “Are you using residential proxies? How do you handle websites that don't want to be scraped. EG if I start passing in Linkedin pages what is…”
Crawl compliance
data-engineerConfigure the crawler to respect robots.txt rules and target-site rate limits automatically
weight 2 · round drawnFirecrawlnone0/10No documentation or evidence describes robots.txt compliance settings or automatic rate-limit throttling; the only related community comment (firecrawl-comm-8) suggests sites must proactively disallow the crawler, which doesn't confirm built-in respect for robots.txt as a configurable, automatic behavior.
- [community] “Excellent, another kind of copyright theft as a service that assumes your site is ripe for scraping unless you disallow yet another agent (F…”
Context.devnone0/10No documentation describes automatic robots.txt compliance or target-site rate-limiting; the only rate-limit doc (context-dev-docs-18) covers API-caller limits, not crawl politeness. Community evidence (context-dev-comm-4) even states the company relies on a manual opt-out blocklist rather than respecting robots.txt automatically, undercutting the story further.
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
- [community] “\"Websites can opt out of our service, and we respect these requests and add them to our block list.\" I.e: robots.txt already exists and is…”
Fault tolerance
data-engineerResume a crashed deep crawl from a saved checkpoint instead of restarting from scratch
weight 2 · round drawnFirecrawlnone0/10No evidence of checkpointing or resuming crawls from saved state; docs mention crawling, webhooks, and async scraping but nothing about crash recovery or resumable checkpoints.
Context.devnone0/10Evidence shows async batch crawling with progress tracking (up to 25,000 pages) but no mention of checkpointing or resuming a crashed crawl from a saved state; only completed-job retrieval or partial-result return on timeout is documented, not crash recovery/resume.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
Operational transparency
data-engineerCheck a public status page showing uptime history and past incident postmortems before committing to the service
weight 2 · round drawnFirecrawlnone0/10No evidence pack item mentions a public status page, uptime history, or incident postmortems for Firecrawl; the docs and community threads cover product features and complaints but nothing about SLA/uptime transparency.
Scheduling monitoring
data-engineerMonitor target pages for content changes, such as price or listing updates, and get notified as they happen
weight 2 · round to Context.devFirecrawlnone0/10The evidence pack shows scraping, crawling, extraction, and webhook-based async event delivery, but no dedicated change-tracking/monitoring feature (e.g., diffing pages over time, price/listing change alerts) is documented anywhere in the pack.
- [claimed-docs] “Webhooks Async event delivery”
- [github] “Crawl an entire website and get content from all pages.”
- [github] “Scrape thousands of URLs asynchronously”
Docs explicitly describe a monitoring feature that watches a page, sitemap, or dataset on a schedule and delivers signed change events, directly matching the story's core ask. However, there's no independent/hands-on corroboration of this feature working in practice, and no detail on notification channels (webhooks, email, etc.) or reliability at scale. Missing for 10: independent evidence of monitoring reliability, details on notification delivery mechanisms/channels, and evidence of scale/performance under continuous monitoring.
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
data-engineerMonitor job performance, validate data quality, and receive alerts when something fails
weight 2 · round to Context.devFirecrawlnone0/10Evidence shows webhooks for async event delivery but nothing about job performance dashboards, data quality validation, or failure alerting mechanisms for a data-engineering monitoring workflow.
Context.dev offers async crawl jobs with progress tracking (docs-3), some quality controls like grounding/coverage/freshness for extraction (docs-4), and scheduled change monitoring with signed events (docs-9), which loosely cover job status and alerting. However there is no dedicated job-performance dashboard, no explicit failure-alert/webhook system for scraping jobs, and no formal data-quality validation framework described. Missing for 10: job performance metrics/dashboard, explicit failure alerting (e.g. webhooks on job error), and structured data quality checks beyond extraction fidelity.
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “Crawl relevant pages and return an object that matches your JSON Schema, with controls for grounding, coverage, and freshness.”
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
- [claimed-docs] “`return-partial` | Return usable completed work with a completion marker. If no usable result exists, fail without a charge.”
- [claimed-docs] “Authenticated API responses expose these headers when a per-minute limit applies”
developerMonitor live system metrics and worker/browser pool status through a real-time dashboard
weight 1 · round drawnFirecrawlnone0/10No evidence of a real-time dashboard for monitoring system metrics, worker pool, or browser pool status; evidence only covers scraping/crawling features, CLI, MCP server, and community discussion unrelated to monitoring dashboards.
developerSchedule scraping jobs to run automatically at specific times
weight 2 · round to Context.devFirecrawlnone0/10No evidence of scheduled/cron-based scraping jobs; Firecrawl's evidence covers crawling, scraping, webhooks, and async batch scraping, but nothing about scheduling jobs to run at specific times.
Context.dev's monitor-website-changes feature watches a page, sitemap, or dataset "on a schedule" and emits change events, which functions as scheduled recurring scraping, but this is framed narrowly as change-detection rather than a general-purpose cron/scheduler for arbitrary scrape/crawl jobs. Missing for 10: explicit documentation of configurable schedule intervals/cron syntax, ability to schedule full crawl or extract jobs (not just change monitors), and any independent/hands-on confirmation of scheduling reliability.
- [claimed-docs] “Watch a page, sitemap, or structured dataset on a schedule and receive signed change events.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
Site crawling
data-engineerRun a deep crawl using a breadth-first strategy with a configurable maximum page limit
weight 2 · round to FirecrawlEvidence confirms Firecrawl can crawl an entire website and discover all URLs (firecrawl-gh-3, firecrawl-gh-4), which implies a crawl feature suitable for a data-engineer's bulk scraping needs, but nothing in the pack explicitly documents a breadth-first crawl strategy or a configurable maximum page limit parameter. Missing for 10: explicit mention of BFS traversal mode, documented maxPages/limit parameter, and independent confirmation that these controls work at scale.
Context.dev documents crawling with configurable maximum page limits (500 for sync, up to 25,000 for async batch crawls), satisfying the page-limit part of the story, but no evidence describes a selectable crawl strategy (e.g., breadth-first vs depth-first) as a configurable parameter. Missing for 10: explicit breadth-first strategy option/documentation, evidence of strategy configurability alongside the page limit.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
developerCrawl an entire website and get content from all its pages with one request
weight 3 · round to FirecrawlGitHub docs explicitly state 'Crawl an entire website and get content from all pages' with supporting features like URL discovery and async scraping of thousands of URLs, directly matching the story. Missing for 10: independent hands-on validation specifically of full-site crawl completeness/reliability at scale (community comments discuss cost/proxy issues but not crawl-completeness failures).
Docs describe a one-request crawl endpoint that returns page Markdown for a site (up to 500 pages synchronously) plus an async option for up to 25,000 pages, and a real customer (SiteGPT) is cited using it to scrape entire websites into a knowledge base. Missing for 10: independent hands-on verification of crawl completeness/accuracy at scale and no third-party benchmark of crawl reliability beyond vendor docs and one customer quote.
- [claimed-docs] “Crawl a small website section and return page Markdown in one response, with a maximum of 500 pages.”
- [claimed-docs] “Crawl up to 25,000 pages in a background batch, track progress, and retrieve Markdown or HTML when the job finishes.”
- [claimed-docs] “SiteGPT, the AI chatbot platform for customer support, switched from Firecrawl to Context.dev to scrape entire websites and turn them into t…”
- [claimed-docs] “Scrape websites into Markdown, crawl linked pages, and extract JSON for AI agents and applications.”
developerInstantly discover all URLs on a website without fully crawling it
weight 2 · round drawnFirecrawl explicitly offers a 'Map' capability described as 'Discover all URLs on a website instantly,' distinct from full crawling, directly matching the story. This is a first-party GitHub claim but lacks independent hands-on corroboration or detail on accuracy/limits at scale. missing for 10: independent/hands-on verification of speed and completeness, documentation of limits on very large sites.
Context.dev has a dedicated URL discovery endpoint that reads a site's public sitemaps and returns a filtered URL list "without rendering each page," explicitly avoiding a full crawl — directly matching the story. Missing for 10: independent/hands-on corroboration of discovery speed or scale beyond vendor docs.
- [claimed-docs] “Read a website's public sitemaps and return a filtered URL list without rendering each page.”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableFirecrawln/aFirecrawl is a web-scraping/crawling API/service that itself exposes an MCP server for other AI tools to consume (firecrawl-docs-5, firecrawl-probe-3); it is not an agent or orchestration platform designed to consume external MCP servers as a client. The evidence pack shows no capability for Firecrawl to import/plug in third-party MCP servers to extend its own tool use, and this is not a fair capability to expect of a scraping API — it's the reverse role.
- [claimed-docs] “MCP Server: Connect Firecrawl to any AI tool via the Model Context Protocol”
- [probe] “official MCP server documented at https://github.com/mendableai/firecrawl-mcp-server”
Context.devn/aContext.dev is a web-scraping/data-extraction API/service that itself exposes an MCP server (context-dev-docs-13, context-dev-probe-3) so that AI clients can call ITS tools — it is not an agentic product that would consume other MCP servers' tools. The 'plug MCP servers in' client-role story is a category error for this kind of product.
- [claimed-docs] “Connect your AI client to Context.dev tools for live web and company data.”
- [probe] “official MCP server documented at https://mcp.context.dev/mcp”
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableFirecrawlnone0/10Firecrawl is a web scraping/extraction API and toolset; there is no evidence of automation versioning, review workflows, or rollback capabilities for crawl/scrape configurations or workflows in any of the docs, GitHub, or community sources.