Skip to main content
Glama

serper_scrape

Read-only

Fetches a web page via Serper's scraper.

⚠️ JS rendering is not guaranteed. A client-side rendered site returns HTTP 200 and an almost empty body, without any error: a very short body therefore does NOT prove the page is empty. Check its length before drawing a fact about the company from it.

⚠️ A call waits at most 15 seconds, then returns a refusal that says so — even on a domain that does not exist. A timeout is a NORMAL failure, not an outage. Start from a URL you have observed, and do not retry the same one.

⚠️ Obfuscated addresses do not survive rendering (mailto: in HTML entities, base64, Cloudflare protection): an address READABLE in the HTML is INVISIBLE in the markdown. A motifs_obfuscation without addresses means "there is a contact here, not decoded": retry with format="html".

Returns the content in ONE representation (markdown by default) + JSON-LD + metadata. More robust than a raw fetch against rudimentary anti-bot measures. Images included as base64 are removed from the content (a trace gives their type and size, images_base64_retirees counts them); format="html" keeps them.

On the measured calls, half of the timeouts were on addresses made up from a company name: it is not the slowness that costs, it is what it carries away — while you wait, your own context gets re-billed. When the served page shows no address, the tool re-reads the HTML itself and returns adresses_obfusquees — it appends the same thing at the bottom of the content; sonde_obfuscation says why the re-read concluded nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "serper_scrape"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesURL of the page to fetch — refused if it falls under the project's `excluded_url_prefixes`.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
formatNo"markdown" (default, the LLM-readable representation) | "text" (raw) | "both" (only if you really need to compare) | "html" (the page's RAW HTML, through our own request, without the scraper and without credit — to check yourself what a rendering may have lost; capped, the total is given in `html_caracteres`).markdown
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
timeout_sNoseconds to wait, 1 to 60 (default 15). Tighten it when you chain many dubious pages; an out-of-bounds value is clamped inside, never refused.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses the hard 15-second cap, that timeouts are a normal failure even on nonexistent domains, that client-side rendering can return HTTP 200 with an almost-empty body, that base64 images are stripped and counted, and that html output is capped. These are exactly the failure modes an agent needs in order not to draw a false conclusion from an empty page.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The warning-block structure with the three ⚠️ markers is effective and front-loaded, but the prose is loose and occasionally editorial ('it is not the slowness that costs, it is what it carries away'), and the obfuscation re-read explanation is harder to parse than it needs to be. Several sentences could be tightened without losing substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does its job by naming the return representation (markdown by default plus JSON-LD and metadata) and calling out specific output fields such as adresses_obfusquees, sonde_obfuscation, and images_base64_retirees. Padding behavior and error differentiation are covered; a little more on what the metadata block contains would close the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains the four format values in operational terms (html as a self-check channel that skips the scraper and preserves images, both only for comparison) and ties them to observable outputs like html_caracteres and images_base64_retirees. It does not add anything for the _org/_group/_run_id/_project/_instance bookkeeping parameters, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ('Fetches a web page via Serper's scraper') and it later differentiates itself generically from a 'raw fetch' by being more robust against anti-bot measures. However, it never names the siblings it competes with (web_read, http_get, apify_website_crawl), so the agent must infer the boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is real operational guidance - start from a URL you have observed, do not retry the same timed-out URL, retry with format="html" when obfuscated addresses are suspected, tighten timeout_s when chaining dubious pages. What is missing is selection guidance: no explicit statement of when to prefer this over web_read or http_get, so usage is implied rather than decided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources