Riveter vs Context.dev
Context.dev wins · 16–29 (48 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.devRiveternone0/10Direct probes show llms.txt returns 404 and no OpenAPI spec is discoverable at any standard path, and no evidence pack item claims an agent-oriented docs format exists; while MCP integration is mentioned, that's a separate capability from machine-readable docs for pointing an agent at.
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.devRiveter exposes a full API with SDKs (Go example shown), webhooks for async completion, dry_run/max_credits safety controls, and scheduling for recurring automation — all of which support headless, non-interactive use in a pipeline. However, there is no explicit CI/CD example, GitHub Actions integration, or CLI documentation demonstrating a documented headless workflow. Missing for 10: explicit CI/CD or pipeline integration guide, CLI headless invocation docs, independent confirmation of automated/scripted runs.
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
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 to Context.devDocs explicitly describe connecting Riveter to Claude, ChatGPT, Cursor, or any MCP-compatible assistant via two connection methods, including a local Node.js-based server option, indicating an official MCP server offering. Missing for 10: no independent/hands-on corroboration of the MCP server working, and no detail on the remote/hosted connection method's implementation.
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
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 Context.devRiveternone0/10Evidence shows SDKs (Go), a local MCP server requiring Node.js, and REST API features, but no mention of an official CLI tool for running enrichments or managing the product. The docs and probes (llms.txt, openapi) surface no CLI reference, so this applicable axis is unmet.
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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.devDocs describe concrete API mechanics (webhook_url, dry_run, max_credits, SDK auth/retry/pagination handling, Go SDK code sample) showing a real documented public API surface for driving runs programmatically, and MCP/remote-server integration is documented. However, probes for a formal machine-readable spec (openapi.json/swagger.json) and llms.txt all returned 404, so there's no discoverable canonical API reference, undermining full 'documented public API' claims. missing for 10: a public OpenAPI/swagger spec or llms.txt confirming a fully machine-readable API contract, independent third-party confirmation of API usage.
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”
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.devRiveternone0/10Riveter's evidence covers a single API key model, credit caps, and dry-run cost estimation, but there is no mention of scoped or least-privilege credentials, per-agent tokens, or permission scoping for agents. missing for 10: scoped/least-privilege credential issuance, per-agent API key scoping, role/permission-based access control.
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 RiveterRiveter ships an official Go SDK (riveterhq/riveter-go) with documented client code (riveter.EnrichParams), and docs describe SDK-level handling of auth, retries, long-polling, and pagination, indicating a first-party SDK layer built for AI-native workflows. Missing for 10: confirmation of additional language SDKs (e.g., Python/JS) beyond Go, and independent/hands-on corroboration of SDK reliability.
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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 RiveterRiveter supports webhooks by passing a webhook_url when starting a run, with Riveter POSTing results back on run.completed, run.stopped, and run.finished events — a real event-notification mechanism for agentic workflows. However this is scoped to a single run's lifecycle rather than a general subscription model (no persistent webhook registration/management endpoint, no broader event catalog, no signature/security details). Missing for 10: a dedicated webhook subscription/management API, documentation of additional event types beyond run lifecycle, and payload signing/verification details.
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
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 to RiveterRiveter's core enrichment feature fills columns using AI agents, web search/scrape, and other tools to generate insights directly on user data, and search_agent provides ad hoc AI-researched answers within the product. missing for 10: independent/hands-on corroboration of insight quality, no example of proactive/unprompted suggestions (only prompt-driven enrichment), and no dashboard-level 'insights' UI evidence beyond API/SDK docs.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
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 drawnRiveter supports scheduling projects to run on a cadence ('every minute' for fast-moving data) and webhook notifications on run completion, which enables autonomous background execution without manual triggering. However, there's no evidence of broader automation orchestration (e.g., conditional triggers, chaining multiple actions, or a dedicated automation/workflow builder) beyond scheduled data refresh. Missing for 10: evidence of multi-step autonomous workflows beyond scheduled enrichment refresh, independent/hands-on confirmation that scheduling works reliably in production, and any automation trigger types beyond time-based schedules.
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
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 RiveterRiveter ships an internal 'agent loop' (search_agent, enrichment AI) that autonomously researches, scrapes, and fills data on request, which functions as a built-in AI assistant for delegated research tasks rather than a conversational general-purpose assistant. Missing for 10: evidence of a general chat/task interface for arbitrary delegation, independent hands-on validation, and clarity on how broadly the agent can handle tasks beyond enrichment/search/scrape.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
ai-native userOperate the product with natural-language commands
weight 2 · round to RiveterRiveter explicitly supports building enrichments from natural-language prompts (riveter-docs-2), offers a search_agent that answers questions in natural language without setup (riveter-docs-5), and can be operated via MCP-compatible AI assistants like Claude, ChatGPT, and Cursor (riveter-docs-9), which is the core mechanism for natural-language control. Missing for 10: independent/hands-on confirmation of NL command reliability, and no evidence of a broader NL command surface beyond enrichment/search (e.g., NL-driven scheduling or config changes).
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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 drawnRiveternone0/10Riveter offers enrichment, search_agent, and scrape tools with structured outputs, but there is no evidence of a preset/template configuration specifically tuned for research agents or citable output formatting; missing for 10: a named preset or template targeting research-agent workflows, citation/source-attribution formatting in outputs, and any documentation referencing 'research agent' presets.
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 drawnRiveternone0/10No evidence of an interactive API reference or runnable examples; probes for llms.txt and OpenAPI/Swagger specs both returned 404s, and docs snippets are static text/code examples only, not interactive/runnable.
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.devRiveternone0/10Probes for llms.txt and OpenAPI/swagger spec files all returned 404s, and no documentation mentions a downloadable machine-readable API spec despite having a REST API and SDKs.
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 to RiveterRiveter offers a dry_run mode that validates a request and returns a credit estimate without creating or charging anything, and a max_credits cap that blocks runs before they execute — both function like a lightweight 'test without side effects' capability. However, there's no explicit documentation of a separate sandbox environment or synthetic/test dataset distinct from production data sources (Riveter always operates against live web/data sources when actually run). Missing for 10: a documented sandbox/staging environment, sample or mock datasets, and explicit guidance on testing enrichments without touching real production data sources.
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnRiveternone0/10No evidence of API versioning scheme or a documented deprecation policy; probes for OpenAPI/spec discovery returned 404s, and docs mention SDKs/features but nothing about version numbers or deprecation guarantees. Missing for 10: versioned endpoint scheme (e.g., /v1/), a published deprecation/sunset policy, changelog or migration guides.
data-engineerThe documented rate limit (requests per second or minute) enforced on my API key before throttling kicks in
weight 3 · round to Context.devRiveternone0/10There is a mention of SDKs handling retries on 429s, implying rate limiting exists, but no documented numeric rate limit (requests per second/minute) is given anywhere in the evidence pack, and probes for API spec/docs return 404s.
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”
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 drawnRiveternone0/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 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 drawnRiveternone0/10No evidence of proxy rotation, IP chaining, or anti-bot-specific retry logic; only generic SDK retries for 429s/transient failures are mentioned, which is unrelated to proxy chaining against anti-bot blocks.
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 drawnRiveternone0/10No evidence mentions undetected browser mode, bot-detection bypass, proxies, or stealth automation features; Riveter's evidence only covers enrichment, scraping, and search tooling. Missing for 10: any mention of anti-bot/stealth browser capabilities, CAPTCHA handling, or evasion of bot detection.
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 drawnRiveternone0/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/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 drawnRiveternone0/10No evidence mentions proxy support (residential or datacenter) or IP rotation for anti-bot bypass; the docs describe scraping and AI agent interpretation but never address proxy infrastructure.
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 drawnRiveternone0/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/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 drawnRiveternone0/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/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 RiveterRiveter's core enrichment model operates on many rows at once (bulk input data with AI-filled columns), supports batch generation from a prompt/spec, scheduling for ongoing refresh, and examples like pulling every dentist from every practice in a city in one request. Missing for 10: independent/hands-on verification of large-scale bulk runs and no explicit documentation of per-run item limits or throughput benchmarks.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
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.devRiveter supports scheduled refresh of projects (time-based automation) and webhook events (run.completed/stopped/finished) that can notify external systems, giving some automation-on-events capability, but there is no evidence of a rules/condition engine that lets users define arbitrary triggers (e.g., 'if data matches X, then do Y') beyond scheduling and run-completion notifications. missing for 10: conditional rule definitions, event-driven branching logic, multi-condition triggers, and any UI/API for building custom automations beyond schedule+webhook.
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
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 RiveterDocs state you can 'schedule any project to monitor for changes and keep your data fresh' and refresh as often as every minute, indicating recurring job/workflow scheduling support. However, details are thin — no documentation on schedule configuration (cron-like syntax, timezone, pause/resume), no UI/API endpoint specifics for managing schedules, and no independent or hands-on corroboration. Missing for 10: scheduling API/UI details, configuration options, independent verification of reliability at scale.
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
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 drawnRiveternone0/10No evidence pack items mention team sharing, organizations, workspaces, or role-based access control for Riveter; all evidence covers scraping/enrichment functionality and API mechanics only. Missing for 10: any mention of teams, org management, invites, or RBAC/permissions.
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 to RiveterRiveter's docs show fully managed, serverless-style capabilities (enrichments, scrapes, quick_search, search_agent) that developers configure via natural-language prompts or structured specs and trigger via API/SDK/webhooks with no server management (riveter-docs-1,2,3,4,5,6,11,12). However, this is closer to configuring built-in AI-driven tools than deploying arbitrary custom scraping code/scripts — there's no evidence of a code-upload or custom-script execution environment. Missing for 10: evidence of arbitrary custom code/script deployment (vs. prompt/spec-based enrichment configuration), and independent confirmation of the serverless execution model.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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 drawnRiveternone0/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.)
developerSelf-host an open-source version of the scraper instead of relying on a hosted cloud service
weight 2 · round drawnRiveternone0/10Riveter is presented as a hosted API/service (with a local MCP connector for client access to the remote service), but there is no evidence of an open-source, self-hostable version of the scraper itself; docs only describe running a local MCP bridge that still relies on the remote API key.
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
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 drawnRiveternone0/10No evidence of a prebuilt n8n or Zapier connector; only webhook support and MCP/AI-assistant integrations are documented, which are not no-code automation platform connectors.
Library compatibility
developerBuild scrapers using popular open-source automation libraries like Playwright, Puppeteer, Selenium, or Scrapy
weight 2 · round drawnRiveternone0/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.)
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 drawnRiveternone0/10No evidence of any export/portability feature for scraped data or job configs, nor any mention of migration support or standard/open config formats; API docs focus on running enrichments, webhooks, and SDKs, not data portability.
Quickstart
developerPublish my custom scraper to a public marketplace and earn revenue when others use it
weight 1 · round drawnRiveternone0/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 drawnRiveternone0/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'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 drawnRiveternone0/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.)
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 drawnRiveter's core enrichment feature lets developers build extraction jobs from a natural-language prompt with target attributes instead of writing selectors, and AI agents interpret pages semantically so configs survive redesigns, directly matching the story. missing for 10: independent/hands-on verification of extraction accuracy and no live API schema (openapi/llms.txt probes 404) to confirm behavior beyond vendor docs.
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
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 to Context.devRiveter lets you define enrichments via a natural-language prompt or a 'structured spec' with named attributes/columns (riveter-docs-2, riveter-docs-12), which produces structured output, but there is no documented mechanism for passing an arbitrary JSON Schema that the API validates/returns against. missing for 10: explicit JSON Schema input parameter, schema validation of output, and any example showing schema-conformant responses.
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
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 to RiveterDocs describe enrichments where AI agents interpret pages and fill arbitrary attribute columns from a natural-language prompt or structured spec (no selectors), with scraping/search tools feeding an AI agent loop that adapts to page structure and redesigns. This directly matches the story of an LLM reading a page and deciding what fields to extract without pre-written selectors. Missing for 10: independent hands-on verification of extraction accuracy and no example showing the LLM's field-selection reasoning in practice.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
- [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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 drawnRiveternone0/10No evidence anywhere in the docs suggests Riveter allows swapping in a local or self-hosted LLM as the extraction engine; the product is presented as a cloud-only enrichment/extraction service with API keys, credits, and hosted agents. Missing for 10: any mention of local model support, self-hosted backend configuration, or BYO-model options.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
Basic scraping
developerScrape a web page with a single API call and get its raw HTML back
weight 3 · round to Context.devRiveternone0/10Riveter's scrape endpoint explicitly returns 'easily parseable text' from a URL, not raw HTML — the opposite of what this story asks for, and no evidence shows an option to retrieve unprocessed HTML.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
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 drawnRiveternone0/10No evidence anywhere in the pack mentions PII detection, filtering, redaction, or compliance controls for scraped/enriched data; Riveter's documented features cover scraping, enrichment, search, and workflow orchestration but nothing about identifying or removing personal data before storage.
Document extraction
data-engineerExtract text content from PDFs, Word, Excel, and PowerPoint files without hosting them myself
weight 2 · round to Context.devRiveter is delivered as a hosted API/SaaS (no self-hosting required) and docs state it 'reads PDFs and images' as part of enrichment workflows, but there is no evidence it extracts text from Word, Excel, or PowerPoint files specifically. missing for 10: explicit support for .docx/.xlsx/.pptx extraction, any extraction-quality benchmarks or examples for Office file formats.
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
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 to RiveterRiveter's docs mention it 'reads PDFs and images' and combines results with web data (riveter-docs-18), implying some visual-content ingestion, but there is no explicit description of generating captions or text descriptions of images for downstream reasoning by a text-only model. Missing for 10: explicit captioning/description output format, example enrichment showing image-to-text extraction, and any confirmation this text is usable standalone by a text-only model.
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
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 drawnRiveternone0/10Riveter's quick_search explicitly returns only urls, titles, and snippets (not full page content), and its scrape tool requires a specific URL rather than combining search+content in one call. search_agent returns a single synthesized answer, not full page content per search result, so no evidenced single-call capability matches the story's exact requirement.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
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 drawnRiveternone0/10Riveter's docs describe AI-driven page interpretation and scraping (turning URLs into parseable text, agents reading pages 'the way a person would') rather than CSS/XPath selector rules; no evidence pack item mentions selector-based extraction at all, and one item explicitly frames the AI approach as an alternative to fragile configuration that would break on redesign, which is the kind of setup selectors typically require.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
Structured data handling
data-engineerExtract data from very large tables using intelligent chunking so it fits within processing limits
weight 1 · round drawnRiveternone0/10Riveter's evidence covers enrichment, scraping, search, and workflow automation, but there is no mention of chunking large tables, row batching, pagination for extraction limits, or handling of very large datasets to fit processing constraints. missing for 10: any mention of chunking strategy, table size limits, batching large extractions, or row-splitting logic.
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 Context.devRiveternone0/10Riveter is a data-enrichment/scraping/AI-agent tool focused on turning URLs into text and filling data columns; there is no evidence it renders JS-heavy SPAs into fully rendered HTML (e.g., headless browser rendering, DOM snapshot output). The 'scrape' feature converts URLs to 'easily parseable text', not full rendered HTML, so this capability is unevidenced.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
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.devRiveternone0/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.)
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 drawnRiveternone0/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.)
developerKeep interacting with an already-scraped page, clicking and filling forms to reach content behind a login wall
weight 2 · round to Context.devRiveternone0/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.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.devRiveternone0/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.)
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.devRiveternone0/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.)
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 drawnRiveternone0/10No evidence in the pack mentions passing custom session cookies, auth headers, or cookie jars for scraping/enrichment requests; the docs describe scrapes, quick_search, and enrichments but not authenticated-page access via user-supplied cookies.
developerReuse a persistent browser profile with saved cookies and login state across multiple requests
weight 2 · round drawnRiveternone0/10No evidence Riveter offers persistent browser profiles, saved cookies, or login-state reuse across requests; its scraping is described as AI-agent page interpretation, not a session/profile management feature.
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.devDocs show many core capabilities (building enrichments via prompt/spec, scraping, quick_search, search_agent, webhooks, dry_run) are all API-accessible, suggesting broad parity, but there is no explicit statement of full UI/API parity and some UI-highlighted features like scheduling refresh (riveter-docs-13, riveter-docs-17) aren't confirmed as API-exposed. Additionally, probes show no discoverable OpenAPI spec (riveter-probe-2) or llms.txt (riveter-probe-1), undermining confidence that the API surface is fully documented/openly specified. missing for 10: explicit parity statement, API access to scheduling/monitoring feature, published OpenAPI spec for verification.
- [claimed-docs] “You can build one from a natural-language prompt or a structured spec, and Riveter will generate the rows for you.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
- [probe] “PROBE llms.txt: HTTP 404 at https://docs.riveterhq.com/llms.txt”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.riveterhq.com/openapi.json, https://docs.riveterhq.com/swagger.json, https://docs.rivet…”
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 Context.devRiveternone0/10No evidence of any data export feature or open-format export capability; the evidence only covers enrichment, scraping, search, and API integration features, with no mention of exporting data or portability guarantees. missing for 10: export functionality documentation, supported open formats (CSV/JSON/etc), any data-portability or account-closure workflow.
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 drawnRiveternone0/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 userSelf-host the core product
weight 3 · round drawnRiveternone0/10Riveter is presented as a hosted API/SaaS product (with local MCP server option only for connecting AI clients, not for self-hosting the core enrichment engine); no evidence of open-source code, self-hosting instructions, or a downloadable core product exists in the pack.
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
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 Context.devDocs state a scrape 'turns a URL into easily parseable text,' implying cleaned output rather than raw HTML, but there's no explicit mention of markdown formatting or output schema. Missing for 10: explicit confirmation that scrape output is markdown-formatted, example output showing markdown structure, independent verification of output cleanliness.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
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 to Context.devRiveternone0/10Riveter's evidence pack covers enrichment, scraping, search, webhooks, and credit controls but never mentions selectable output formats like markdown, HTML, text, or frontmatter for returned data.
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 Context.devRiveter's enrichments and scrapes explicitly return structured, parseable data (columns, urls/titles/snippets, webhook payloads of 'full results'), and SDK examples show structured attribute objects returned from calls, indicating outputs are consumable as structured JSON rather than raw text. missing for 10: an explicit statement of JSON schema/response format in docs, and independent/hands-on confirmation of the JSON structure (API docs endpoints 404 in probes).
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “run, err := client.Enrich(ctx, riveter.EnrichParams{ Prompt: "Research each company", Attributes: []string{"CEO", "Employee Count"},”
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 to Context.devDocs claim a scrape converts any URL into 'easily parseable text' and that AI agents interpret pages 'the way a person would', directly addressing the ask for clean, LLM-ready text instead of raw HTML. However, all evidence is vendor documentation with no independent hands-on verification of output cleanliness, no example output shown, and no explicit mention of handling JS rendering/blocking obstacles beyond the general claim. Missing for 10: independent corroboration of scrape text quality, concrete example output, and explicit handling of anti-bot/rendering blockers.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “Riveter uses AI agents that interpret pages the way a person would, so the same configuration keeps working after a redesign.”
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
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 drawnRiveternone0/10Riveter's evidence describes enrichments, scrapes, searches, and structured row outputs, but nothing indicates a semantic-chunking output mode designed for retrieval pipelines (e.g., configurable chunk size/overlap, chunk metadata). Structured rows/columns are not the same as semantic chunking for RAG ingestion, and no such feature is documented.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
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.devRiveternone0/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.)
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 drawnRiveternone0/10Riveter offers cost controls like dry_run estimates and max_credits caps that refuse overpriced requests, but there is no evidence the API automatically searches for or selects the cheapest configuration that still succeeds — it only estimates/caps, it doesn't auto-optimize. Missing for 10: any documentation of automatic configuration search/optimization for cost, fallback logic that retries cheaper options, or an API parameter that lets Riveter choose the minimal successful config itself.
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
developerBlock ads on the target page to speed up scraping requests
weight 1 · round drawnRiveternone0/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/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 drawnRiveternone0/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 userSet how much reasoning effort an autonomous agent spends on a data-gathering task (low, medium, high)
weight 2 · round drawnRiveternone0/10No evidence anywhere in the pack of a control that lets users set reasoning effort (low/medium/high) for an agent's data-gathering task; only credit caps and dry-run cost estimation are documented, which are cost controls, not reasoning-effort controls.
Cost transparency
developerWhether exceeding my plan's monthly credit or request quota triggers overage charges or a hard cutoff
weight 3 · round drawnRiveternone0/10The evidence describes credit estimation, dry_run, and max_credits cap that refuses requests at 422 before charging, but there is no mention of plan-level monthly credit/request quotas, nor whether exceeding them triggers overage billing or a hard cutoff. missing for 10: any documentation of monthly plan quotas, overage billing policy, or hard-cutoff behavior when a subscription limit is exceeded.
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
developerWhether failed, blocked, or empty-result requests still consume my billing quota
weight 2 · round to Context.devRiveternone0/10The docs describe dry_run cost estimation and max_credits caps that prevent overage, but nothing states whether a failed, blocked, or empty-result run still consumes credits. Missing for 10: explicit policy on billing for failed/empty/blocked runs, any refund or non-charge guarantee for zero-result enrichments.
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
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 to RiveterRiveter offers per-request cost control via dry_run (credit estimate before charging) and max_credits (hard ceiling that returns 422 credit_cap_exceeded with nothing charged), which directly prevents a single run from blowing past a set budget. However, there's no evidence of an account-wide spending cap, recurring usage alerts, or a dashboard/notification system for cumulative consumption across runs. Missing for 10: account/org-level budget cap, proactive usage alerts/notifications, historical spend tracking dashboard.
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
Performance tuning
developerTrade off latency against completeness by controlling exactly when content is returned
weight 1 · round to RiveterRiveter explicitly exposes multiple latency/completeness tradeoffs: quick_search returns fast synchronous structured snippets, search_agent runs a fuller AI research loop for one question, and full enrichments can be tracked via wait_for_result long-polling or async webhook callbacks — giving a developer direct control over when and how complete the returned content is. missing for 10: no independent/hands-on benchmarks or third-party confirmation of actual latency differences between these modes.
- [claimed-docs] “A quick_search lets you quickly web search a query, and pull structured results with urls, titles, and snippets — synchronously, in one requ…”
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
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 drawnRiveternone0/10No evidence pack items mention pricing tiers, concurrency/rate limits, or the cost to raise such caps; only credit-cap controls (max_credits) and dry-run estimates are documented, which address per-request cost, not concurrent session limits or tier-based upgrade pricing.
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 drawnRiveternone0/10No evidence in the pack mentions data residency, regional storage options, or compliance controls for where data is stored; the docs focus entirely on enrichment features and API mechanics. Missing for 10: any mention of region selection, data residency options, or storage location controls.
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 userControl data retention and deletion
weight 2 · round drawnRiveternone0/10No evidence in the pack addresses data retention policies, deletion controls, or data lifecycle management for Riveter's stored enrichment data, run results, or scraped content.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnRiveternone0/10No evidence pack item mentions telemetry, usage tracking, analytics collection, or any opt-out mechanism for Riveter; the docs focus entirely on enrichment, scraping, and API features. Missing for 10: any mention of telemetry practices, privacy policy, or opt-out settings.
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 to RiveterRiveter's search_agent and enrichment agent loop imply some autonomous research process that fills a cell with an AI-researched answer, suggesting the agent decides when it has enough data, but there is no explicit documentation of stopping criteria or adaptive crawling behavior tied to query sufficiency. missing for 10: explicit description of adaptive stopping/crawling logic, evidence of how the agent determines 'enough information', independent confirmation of this behavior in practice.
- [claimed-docs] “A search_agent call asks one question and gets one AI-researched answer back — the same agent loop that fills a single enrichment cell, with…”
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
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 Context.devRiveter's enrichment engine explicitly processes rows of URLs with scraping, runs asynchronously (webhook_url on completion), and SDKs handle retries, long-polling, and pagination — all core pieces for async batch scraping. However, there's no explicit documentation of scale limits, concurrency handling, or a tested example at thousands-of-URLs volume. Missing for 10: explicit large-scale (thousands of URLs) benchmarks or case studies, concurrency/rate-limit guidance for very large batches.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
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 drawnRiveternone0/10No evidence describes applying different crawl configurations per URL pattern within one batch/enrichment job; docs mention scraping, searching, and enrichment generally but not per-pattern configuration rules. missing for 10: any mention of per-URL-pattern rules or configuration scoping within a single job, examples or docs showing mixed crawl settings in one batch.
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 drawnRiveter's enrichment engine processes many rows in a single run and can chain scrapes/searches (e.g., finding every dental practice then every dentist in one request), implying built-in batch/bulk scraping at scale, and SDKs handle retries/pagination for large jobs. However, there is no explicit documentation of concurrency limits, parallel session management, or throughput guarantees for scraping specifically. Missing for 10: explicit concurrency/session limits, performance benchmarks, and independent evidence of scaling to many simultaneous scrape sessions.
- [claimed-docs] “An enrichment takes rows of input data and fills in new columns using AI, web searches, web scrapes, and other tools.”
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
- [claimed-docs] “the SDKs handle auth, retries (429s and transient GET failures), the wait long-poll, polling until a run finishes (wait_for_result), and pag…”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
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 drawnRiveternone0/10No evidence anywhere in the docs mentions robots.txt compliance or rate-limit configuration; the pack only covers scraping features, retries, credits, and MCP integration. This is a fair axis for a web-scraping/crawling product, but absence of evidence means it cannot be credited as delivered.
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 drawnRiveternone0/10No evidence describes checkpointing or resuming a crashed deep crawl; the docs mention webhooks, dry runs, and credit caps but nothing about saving/resuming crawl state after a crash.
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 drawnRiveternone0/10No evidence of a public status page, uptime history, or incident postmortems anywhere in the evidence pack; only product feature docs and API references are present.
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 RiveterRiveter explicitly supports scheduling projects to monitor for changes, refreshing as often as every minute, and can POST results to a webhook_url when a run finishes, which together deliver change-monitoring plus notification. However, the webhook fires on run completion rather than a dedicated 'content changed' diff event, and there's no independent/hands-on evidence of this workflow in production. Missing for 10: independent corroboration of the schedule+webhook pipeline in practice, and explicit diff/change-detection logic distinguishing 'changed' vs 'unchanged' pages.
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
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 RiveterRiveter supports webhook alerts on run completion/stop/finish events and scheduled monitoring for data freshness, giving some job-status alerting and monitoring capability, but there is no explicit data-quality validation feature (e.g., schema/anomaly checks) or job performance dashboards described. missing for 10: explicit data quality validation tooling, job performance metrics/dashboard, and independent confirmation of alerting reliability.
- [claimed-docs] “Pass webhook_url in the JSON body when starting a run and Riveter POSTs the full results to your URL when it finishes (events: run.completed…”
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “dry_run: true — validate the request and return a credit estimate without creating or charging anything.”
- [claimed-docs] “max_credits — a ceiling. When the estimate's maximum exceeds it, the request is refused with 422 credit_cap_exceeded and nothing is charged.”
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 drawnRiveternone0/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.)
developerSchedule scraping jobs to run automatically at specific times
weight 2 · round drawnRiveter supports scheduling projects to monitor for changes and refresh data as often as every minute, which implies automatic recurring scraping jobs, but there's no detail on specifying exact times/cron-like scheduling, timezone control, or a documented scheduling API/UI. missing for 10: explicit scheduling configuration details (time-of-day, cron syntax, timezone), independent/hands-on confirmation of scheduling reliability, and API endpoint documentation for creating/managing schedules.
- [claimed-docs] “Schedule any project to monitor for changes and keep your data fresh.”
- [claimed-docs] “For fast moving data like scores or election results, you can refresh as often as every minute.”
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 Context.devRiveternone0/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.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 Context.devRiveter's docs describe single-URL 'scrape' and 'quick_search' calls, but the marketing example of finding every dental practice in a city and pulling data from each one in a single request shows it can aggregate content across multiple pages/sources in one enrichment run, which approximates whole-site crawling. There is no explicit sitemap-style 'crawl entire website' feature or evidence of full-domain page enumeration. missing for 10: explicit full-site/sitemap crawl feature, evidence of automatically discovering and traversing all pages of a single domain, independent confirmation of multi-page crawl behavior.
- [claimed-docs] “A scrape lets you turn a URL into easily parseable text.”
- [claimed-docs] “It can find every dental practice in a city, then pull every dentist from each one, in a single request.”
- [claimed-docs] “It reads PDFs and images, calls third party APIs as part of a workflow, and combines those results with data pulled from the web in a single…”
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 to Context.devRiveternone0/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.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 comparableRiveternone0/10All MCP-related evidence describes Riveter acting as an MCP *server* that other AI assistants (Claude, ChatGPT, Cursor) connect to, not Riveter acting as a client that can plug in and consume external MCP servers' tools. No evidence shows Riveter itself importing/connecting to third-party MCP servers to extend its own tool use.
- [claimed-docs] “Use Riveter from Claude, ChatGPT, Cursor, or any MCP-compatible AI assistant. Pick one of the two ways to connect.”
- [claimed-docs] “Runs on your machine and needs Node.js and an API key. Use it when your client cannot reach remote servers.”
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 comparableRiveternone0/10No evidence of version history, review workflows, or rollback capability for automations/enrichments; the pack only covers run execution, credit control, and data enrichment features. Missing for 10: versioning of automation configs, review/approval workflow, rollback/undo mechanism.
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableRivetern/aRiveter is a data enrichment/web-scraping tool, not an AI model provider or chat assistant whose data usage/training policies would be relevant here; the evidence contains no mention of AI training data policy or opt-out controls, and this axis is a category error for the product type.