The recurring job

An agent checks one public domain, keeps the resulting source list, then runs the same check later. The useful comparison starts with an identical query, result count, and recency window. That leaves changes in the returned pages visible instead of mixing a new search shape into the result.

search-site takes that exact request shape. It returns ranked titles, URLs, snippets, and domains for $0.006 USDC on Base after the x402 payment. 

curl -X POST https://x402.agentutility.ai/search-site \
  -H "Content-Type: application/json" \
  -d '{"query":"site:docs.cloud.coinbase.com x402","num_results":10,"recency":"week"}'

The first response states the payment requirement. After payment, save the request with the returned results, source, and degraded fields.

Run the same check from the CLI

Use one saved JSON body for the first call and every later check. The CLI checks the current price before it pays; --max-price 0.006 keeps this job within its listed per-call price. 

agentutility price search-site
agentutility call search-site \
  --data '{"query":"site:docs.cloud.coinbase.com x402","num_results":10,"recency":"week"}' \
  --max-price 0.006

Save the response beside that JSON body. On the next run, send the unchanged body again and compare only the returned URLs from responses with the same source label.

Diff two matching checks

Keep the request body in request.json, then save each paid response with its date. This small script refuses to compare a live result with a fallback or stale-cache result, so a provider incident does not look like a page change. 

mkdir -p site-check
cat > site-check/request.json <<'JSON'
{"query":"site:docs.cloud.coinbase.com x402","num_results":10,"recency":"week"}
JSON

agentutility call search-site \
  --data "$(cat site-check/request.json)" \
  --max-price 0.006 > site-check/baseline.json

first=site-check/baseline.json
current=site-check/current.json
if [ "$(jq -r '.source' "$first")" = "$(jq -r '.source' "$current")" ]; then
  diff -u \
    <(jq -r '.results[].url' "$first" | sort -u) \
    <(jq -r '.results[].url' "$current" | sort -u)
else
  printf 'Different source labels. Save this check and retry for a like-for-like diff.\n'
fi

On the next paid run, save the response as site-check/current.json, then run the comparison section. The diff output shows only added and removed URLs, which is the piece a monitor needs to carry forward.

Keep a comparable record

Use the same JSON body for the next check. The source field identifies the primary path, a current cache response, a public-news fallback, or a prior exact result marked stale cache during an outage.

Those labels matter. Compare two result lists only when their source fields match. A degraded or stale result is still useful for retaining the last known pages while the next live result is pending. 

{
  "query": "site:docs.cloud.coinbase.com x402",
  "num_results": 10,
  "recency": "week"
}

Choose the next call by the needed output

search-site fits a domain-scoped source list. Use search-content when the next step needs cleaned page text for each result. Use answer-web when the next deliverable is a written answer with citations. Each route has a different response shape and price, so choose before the x402 payment.

The MCP version

Agents that already use MCP can call the same route from the web-probe server. The tool name is search-site, and it accepts the same query, num_results, and recency fields. 

{
  "mcpServers": {
    "agentutility-web-probe": {
      "command": "npx",
      "args": ["-y", "@agentutility/mcp-web-probe"],
      "env": { "X402_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY_HEX" }
    }
  }
}

Keep the prior request and source list beside the monitoring task. The next agent can reuse them without guessing which domain, time window, or result count produced the earlier record.