Give the Sazabi agent live web search and page fetch with Exa

Last verified on Nov 8, 2026.

Most production problems have an outside half. A vendor deprecates an endpoint, a library publishes a security advisory, a cloud provider posts a status note, or someone else already filed the exact stack trace you are staring at. Your logs say what broke. The web often says why.

Exa is a web search service that hosts its own MCP server. Connected to the Sazabi agent, part of Sazabi's AI-native observability and security platform, it lets the agent fetch that outside context in the same thread where it is reading your logs, rather than leaving you to paste links back in.

What the Sazabi agent can do with Exa

The connector points at Exa's hosted server, https://mcp.exa.ai/mcp. Sazabi stores your Exa API key and sends it as x-api-key. Exa's documentation lists four tools:

• web_search_exa searches the web and returns ready-to-use content. It is on by default.
• web_fetch_exa reads clean content from one or more URLs you already know, such as a changelog entry or an advisory page. It is on by default.
• web_search_advanced_exa adds category and domain filters, date ranges, text constraints, summaries, highlights and subpage crawling. Exa makes it opt-in with a tools parameter on the server URL.
• agent_run runs multi-step research, list-building and enrichment with structured output. Exa requires OAuth or an API key for it because runs are usage-based.

Sazabi's connector page describes the same capabilities in its own words: searches with content retrieval, company research, crawling known URLs, similar-link lookup and deep research tasks. Open the connection page after you connect to see exactly which tools Exa advertised to your key.

Questions it answers

• Did this vendor change or retire the API call that started returning errors today?
• Is there a published advisory or issue for the library version in this stack trace?
• What does the upstream status page or incident post say about the time window I am looking at?
• Which of our dependencies mention this error string in their issue trackers?
• Who is this third-party service, and what does it say its rate limits are?

A worked example: an upstream call starts failing after a deploy

Requests to a payments partner begin failing with 410 responses. The calls come from billing-worker, and nothing changed in your code. In a Sazabi thread you ask:

billing-worker has returned 410 from api.example-pay.com/v1/charges since
09:12 UTC. Search for a deprecation or changelog note about that endpoint
from the last 30 days, fetch the page, and tell me what replaced it.

The agent first reads the failing requests from your logs to pin the start time and the exact path. It then calls web_search_exa with a query built from the partner name, the path and the status code. If web_search_advanced_exa is available it can restrict the search to the partner's own domain and a date range. For the best hit it calls web_fetch_exa to read the full page, rather than guessing from a snippet.

Treat the answer as a lead with a source attached. Ask the agent to quote the sentence and the URL, then confirm against the vendor's page before you change code. If the deprecation is real, a follow-up such as "which of our services call that path?" goes back to your own logs. For a bigger question, like comparing three vendors' migration paths, agent_run can take the job. If it reports a running status, the agent calls it again with the returned run ID.

How it fits with other integrations

Exa covers the open web. For questions about open-source internals, the DeepWiki page covers repository-level answers, and Context.dev is the better fit for scraping one specific page or watching it for changes. For code on your side, see the GitHub integration and the coding agents category. Browse the integrations index for every method, or pricing for Sazabi plans.