Integrations
Integration

Scrape live pages and manage website monitors from a Sazabi thread

By Sazabi Team

Last verified on Nov 8, 2026.

Some production problems are visible only from the outside. A deploy finished, every health check is green, and a customer still reports that the docs page shows last week's API reference. Your logs say the release shipped. Only a fetch of the live URL says what users actually receive.

Context.dev is a web data API that scrapes pages into Markdown, HTML, images or screenshots. Connected to the Sazabi agent, part of Sazabi's AI-native observability and security platform, it lets the agent check the live page during an investigation and put the result next to your deploy and request logs.

What the Sazabi agent can do with Context.dev

Sazabi offers two methods, and they suit different jobs.

MCP connector. Sazabi stores your Context.dev API key (ctxt_secret_...) and sends it as the x-context-dev-api-key header. Sazabi's docs describe a Code Mode scheme with two tools. search_docs queries the Context.dev SDK, and execute runs TypeScript the agent writes against that SDK in a sandbox, so a single call can chain a scrape, an extraction and a monitor change. Through it the agent can:

  • resolve brand data by name, domain, email, stock ticker or ISIN
  • scrape and crawl websites into Markdown, HTML or images
  • extract structured data, styleguides and product catalogs
  • create, update, run and inspect website-change monitors

Sandbox CLI. The context-dev CLI is installed in the agent's sandbox and authenticated with CONTEXT_DEV_API_KEY. Sazabi's page lists brand lookups, web scraping and screenshots. Context.dev documents JSON output for the CLI, which is easy for the agent to filter with ordinary shell tools.

Context.dev's own MCP docs describe a separate hosted server with OAuth, api.read and api.write scopes, and tool responses capped at 80,000 characters. They also warn that website content is untrusted input, and recommend keeping approvals on for crawls and monitor changes. That advice applies here too.

Questions it answers

  • What does this URL actually serve right now, as text?
  • Does the version string on the live docs page match the release that shipped?
  • Which image URLs does this landing page reference, and on which host?
  • Which company is behind this domain that keeps calling our API?
  • Is there a monitor already watching this page, and what has it recorded?

A worked example: the docs page that did not update

A release tagged v2.14.0 went out at 11

UTC, and your deploy job logged success. Support says https://docs.example.com/api/reference still shows v2.13.2. You ask:

Fetch https://docs.example.com/api/reference as Markdown and tell me which
version string it shows. Compare it with the release tag in the docs-site
deploy logs from 11:00 UTC. If they differ, also take a screenshot.

The agent reads the deploy logs for the tag and the finish time. It then calls the Context.dev scrape for the URL, which returns Markdown. With the connector that happens through execute, after search_docs has told it which SDK call to use. With the CLI it runs context-dev in the sandbox and filters the output for the version line. If the strings differ, it captures a screenshot to attach to the thread and points at the likely step: a CDN serving a cached copy, a build that published to the wrong bucket, or a rollout that has not reached every region.

The scrape shows what a fetch received at one moment, from one location. If it shows the old version, ask the agent to fetch again after a cache purge and compare. A final useful step is a website-change monitor on that URL, created and inspected with the connector, so the next time the page changes you have a record rather than a guess. Because a monitor changes state in your Context.dev account, approve it explicitly.

How it fits with other integrations

Context.dev fetches one page you name; Exa is the one to use when you do not yet know which page to fetch, and DeepWiki covers repository questions. If the page is served through a CDN, the Cloudflare page covers that side, and Vercel covers builds. The coding agents category lists tools that act on what you find, and the integrations index shows every method.

Ways to connect

  • Context.dev (MCP connector): Give the Sazabi agent tools to resolve brand data, scrape and crawl websites into LLM-ready Markdown, extract structured data, and manage website-change monitors.

Frequently Asked Questions

Which tools does the Sazabi connector expose?

Sazabi's docs describe a Code Mode scheme with two tools. search_docs queries the Context.dev SDK, and execute runs TypeScript written by the agent against that SDK in a sandbox, so one call can combine a scrape, an extraction and a monitor change. Context.dev's own docs describe a separate hosted server with per-operation tools, so read the tool list Sazabi discovers.

When should I use the CLI instead of the MCP connector?

The CLI runs in the agent sandbox with a CONTEXT_DEV_API_KEY and suits one-off scrapes and screenshots whose output the agent then processes with other sandbox tools. The connector is better when you want the agent to compose several operations or manage monitors through the SDK.

Is scraped content safe to act on?

Treat it as untrusted input. Context.dev recommends keeping approvals on for operations that start work or change state, and not letting page content authorize follow-up tool calls. Use the read-only toggle if you only need lookups.

Does Context.dev send data to Sazabi on its own?

No. The agent calls it during an investigation. For continuous telemetry from your services, use OpenTelemetry.

Sources

  1. Context.dev has two Sazabi methods: an MCP connector and a sandbox CLI (accessed Nov 8, 2026)
  2. Code Mode tool scheme with search_docs and execute, API key sent as x-context-dev-api-key, brand data, scraping and crawling to Markdown, structured extraction, website-change monitors (accessed Nov 8, 2026)
  3. The context-dev CLI is available in the agent sandbox for brand lookups, scraping and screenshots, authenticated with CONTEXT_DEV_API_KEY (accessed Nov 8, 2026)
  4. Context.dev's own hosted MCP server uses OAuth with api.read and api.write scopes, tool responses are capped at 80,000 characters, and website content is untrusted input so approvals should stay on for crawls and monitor changes (accessed Nov 8, 2026)
  5. Scrape endpoints return Markdown, HTML, images, screenshots and bytes from one URL, with monitors and batches built in, plus a context-dev CLI with JSON output (accessed Nov 8, 2026)