MCP tools

The remote server exposes four tools. web_access_search is read-only. web_access_fetch can run browser actions that modify destination data, web_access_request sends POST, PUT and PATCH requests, and web_access_sitemap creates and manages billed crawl jobs.

The self-hosted source includes five tools; the published package may lag these docs. It has no web_access_request, and its web_access_fetch still takes a method, so it sends POST, PUT and PATCH directly while advertising a read-only hint. Prompt on it the way you would on web_access_request. It also has web_access_product_help and web_access_report, which the remote server does not.

web_access_fetch

Fetch any webpage and get clean, LLM-ready Markdown back. The common case is passing only a url.

The direct HTTP path issues a GET. To send a direct POST, PUT, or PATCH with a body, use web_access_request. Browser actions can still modify destination data or submit forms.

A header name given twice is an error; send one value per header name. headers together with executeJS is refused before anything is sent, since a rendered fetch cannot carry them.

Returns: Markdown by default; the verbatim body or a JSON envelope when format is set accordingly.

{ "url": "https://example.com/article" }

Browser actions

Pass actions when the content you want does not exist in the document until something happens to the page — a click past a consent gate, a search form submitted, a "load more" button, or rows that render only once scrolled into view. The sequence runs in a real browser session, and the page is captured after the last step.

Treat the remote tool as mutating and potentially destructive: browser actions can change destination data or submit a form, even though a URL-only call just reads a page.

Escalate in this order, cheapest first:

1. Plain url — always try this first.
2. executeJS: true — the page renders client-side but needs no interaction.
3. actions — the content requires interaction. Takes tens of seconds and holds a browser session.

If the data is missing at every rung, it is probably not in the HTML at all. Look for the JSON API the page itself calls and fetch that endpoint directly — it is faster and returns exact values.

{
  "url": "https://example.com/listings",
  "actions": [
    { "type": "wait", "selector": ".card", "timeout": 20000 },
    { "type": "scroll", "direction": "down" },
    { "type": "wait", "milliseconds": 1500 },
    { "type": "scroll", "direction": "down" },
    { "type": "wait", "milliseconds": 1500 }
  ]
}

Waiting on a selector rather than a fixed duration continues as soon as the content is there, so prefer it wherever you can name one. Up to 50 actions per request, one screenshot at most, and 30s caps any single wait. The full step vocabulary is in Browser actions.

Returns with actions: a JSON object — data (the final page, Markdown by default), finalUrl, statusCode, and screenshot when the sequence took one. A failed step still returns successfully, carrying error and failedActionIndex (0-based, into your actions array) with data holding the page as it stood at that point.

actions cannot be combined with headers, format: "raw" or solveCaptcha: false; the call fails before anything is sent, with an error naming the field. A browser session is always a GET.

web_access_request

Send a POST, PUT, or PATCH with a body to a URL you supply, over the same path web_access_fetch uses. Plenty of those calls only read: a GraphQL query, a search backend that takes a body, a JSON API that refuses GET. It is a separate tool because method and body do not exist on web_access_fetch at all: requests with a body get their own schema and their own warning. The split is about request shape, not safety — browser actions make web_access_fetch mutating too.

executeJS and actions are not available here — both run a browser session, which is always a GET.

Returns: a { statusCode, headers, data } envelope by default.

{
  "url": "https://example.com/api/items",
  "method": "POST",
  "body": { "name": "widget" }
}

web_access_search

Search the web from a query and get ranked organic results back, plus every surface Google rendered around them. Set format to raw for the Google results page as HTML, one page per call.

page, dateRange, sortBy, format, searchType and the filters apply to Google results only and are rejected with aiMode. dateRange, sortBy and verbatim apply to the web, videos and forums tabs; format: "raw" and aiOverview to web only.

With format: "raw", the response is html, the Google results page as HTML, in place of results and the surfaces, with htmlBytes and htmlTruncated. Ask for page N with page, one call per page, each billed as one search; a raw call with searchCount is rejected. See Raw HTML.

The tool sends at most 60,000 bytes of HTML per call. A page cut short has htmlTruncated: true, and htmlBytes is the size of the whole page. For the whole page, call POST /search with "format": "raw". Prefer the default structured results unless you need HTML.

Returns: results, the ranked organic documents, each with position (its place in this response), rank (its Google rank; Google only), title, url (the link to fetch; absent when the destination is not known, and the result is still returned), snippet, displayUrl (Google's displayed URL line, empty when Google shows none, as on Reddit and YouTube results), displayText (the source line Google shows under the title, verbatim: a URL, engagement counts such as 20+ comments · 3 months ago, or other text), source when Google names the site (such as Reddit · r/buildapc), and a timestamp when the engine dated the result; and zeroResults, true when the engine itself reported that nothing matched. Every other field is a surface Google rendered around the documents. Each is present only when the page carried it, is never merged into results, and only Google returns it — the same shape as POST /search:

A query naming a single business often comes back with results empty and the answer in entity or places, so read those before treating an empty results as no answer. A snippet is the engine's description of the page, not the page itself, and an overview is a summary, not a source — fetch the url with web_access_fetch to read it.

{ "query": "latest developments in AI agents 2026" }

{ "query": "construction consulting firms Ohio", "searchCount": 30 }

{ "query": "heat pump grants", "format": "raw" }

{ "query": "plumbers near me", "location": "Austin,Texas,United States" }

{ "query": "how does a heat pump work", "aiMode": true }

{ "query": "what is the weather today", "aiMode": true, "location": "London" }

{ "query": "best bakeries near me", "aiMode": true, "coordinates": { "latitude": 48.8566, "longitude": 2.3522 } }

web_access_sitemap

Crawl a whole site and map its URLs. Starting from one URL the crawler follows same-domain links breadth-first (optionally seeded from the site's /sitemap.xml) and records every URL it reaches with fetch status, depth, and parent. Crawls run asynchronously as sitemap jobs: one tool drives the whole quote → approve → poll → read lifecycle through its action parameter, and nothing is crawled or billed until the quote is explicitly approved.

A bound outside its range, 0 included, is an error rather than being replaced by the default. Omit the field to get the default.

Returns: the JSON envelope for the chosen action (quote, status, URL page, or job list) alongside a one-line summary.

{ "action": "submit", "url": "https://example.com", "maxPages": 200, "maxDepth": 3 }

Recommended workflow

1. Call web_access_search to find relevant pages for a query.
2. Call web_access_fetch on the most relevant URLs to pull their full content.

To cover a whole site instead of single pages, run web_access_sitemap first (submit → approve → poll → results) to build the URL list, then web_access_fetch the pages you need.