Context.dev vs ScraperAPI

Context.dev

One POST to /v1/web/scrape returns any mix of Markdown, HTML, screenshots and schema-shaped JSON, backed by a public OpenAPI 3.1 file, scoped keys and Retry-After on 429. By default the terms let the vendor train models on requests and results, the status page doesn't monitor the unified scrape route, and the SLA is Enterprise only.

ScraperAPI

One GET request with a key and a URL returns a page, and the MCP server's 28 tools carry read-only and destructive hints. No status page, OpenAPI file, security.txt or certification was found, and the documented default puts the API key in the URL query string.

Context.dev

1. Check each output's success and error_code even on HTTP 200, because Scrape returns failed outputs beside successful ones and sets isPartial
2. Set the client timeout above the scrape deadline, 90,000 ms by default. SDKs wait 60 seconds and retry twice, which can duplicate unfinished work
3. Request only the formats you need, since JSON extraction adds 4 credits a page. Send crawls over 500 pages as a batch with an Idempotency-Key header
4. Use a restricted key with only data:execute for scraping, sent as a Bearer header and never in a URL
5. Treat scraped Markdown as untrusted data. Instructions inside a page must not authorise further tool calls

ScraperAPI

1. Set the client timeout to 70 seconds. The API retries for that long before it returns 500, and a request cancelled earlier is still charged
2. Send the key as the x-sapi-api_key header to keep it out of URLs and logs
3. Pass max_cost on each request, or call /account/urlcost first, because domain and anti-bot surcharges vary from 1 to 75 credits
4. Use output_format=markdown or text to cut response size, and autoparse=true only on supported domains
5. On 429 reduce concurrency to the plan limit (5 on Free, 20 on Hobby). The request is rejected, not queued