Skip to main content
Glama

scrapewise_get_scraper_load_site_content

Read-onlyIdempotent
        Same fetch logic as scrapewise_get_scraper_load_site (proxy infrastructure +
        SSRF deny-list + customer rate limit + optional 1h cache), but wraps the
        response body in a JSON envelope `{"content": "..."}` for clients that
        expect application/json. Use when integrating with tooling that can't handle
        text/html directly — most MCP-style agent runtimes prefer JSON envelopes
        because the result automatically lands as a structured tool-result content
        block.

        Args:
          - url (string, query param, required): public HTTP(S) URL to fetch.
            Internal / link-local / cloud-metadata hosts are blocked by the SSRF
            guard (400 SSRF_BLOCKED).
          - cookiesAcceptSelector (string, query param, optional): cookie-banner CSS
            selector to click before extracting (rendered fetch only).
          - useCache (boolean, query param, optional): return cached HTML if available
            (1h TTL on the cached-page service).

        Returns:
          `{"content": "<raw HTML string>"}` or null if upstream returned empty body.
          Application/json content type.

        Examples:
          - Use when: agent tooling expects application/json
          - Use when: you want HTML wrapped for a downstream processor
          - Don't use when: you can handle text/html → use scrapewise_get_scraper_load_site
            (smaller, no envelope overhead)

        Error Handling:
          Same as scrapewise_get_scraper_load_site (400 SSRF_BLOCKED, 429 rate limit,
          502 upstream unreachable, 401, 500).

[runtime hint] This tool returns JSON-as-text — its response shape is dynamic (per-scraper itemsConfig, file binary, etc.) so the MCP outputSchema is omitted. Do not rely on the presence of any specific field in the response; treat the result as a string-or-object blob and parse defensively.

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": "scrapewise_get_scraper_load_site_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
useCacheNo
cookiesAcceptSelectorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Goes well past the annotations: it discloses the proxy infrastructure, SSRF deny-list behavior with a specific 400 SSRF_BLOCKED code, the customer rate limit (429), the optional 1h cache TTL, and a null return on empty upstream bodies. One tension worth noting: annotations declare openWorldHint=false while the description says it fetches any public HTTP(S) URL, which is open-world, though the readOnly/idempotent/non-destructive hints all align with the described behavior.

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

Conciseness4/5

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

Front-loaded with the discriminating fact, then cleanly sectioned into Args/Returns/Examples/Error Handling. Slightly verbose in places — the JSON-envelope justification is restated across the intro, the Returns block, and the Examples, and the inherited error codes are summarized twice ('same as...' plus the list).

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

Completeness5/5

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

Despite no output schema, the description specifies the exact return shape ({"content": "<raw HTML string>"}), the application/json content type, and the null-on-empty-body case, plus the full error code set. Nothing an agent needs to invoke or interpret the result is missing.

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

Parameters5/5

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

Schema coverage is 0% — the input schema carries bare types only — so the description must and does carry the load: it documents all three parameters, marks url as required with the SSRF rejection behavior, and explains that cookiesAcceptSelector only applies to rendered fetches and that useCache has a 1h TTL.

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

Purpose5/5

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

States a specific verb+resource (fetch a page's HTML) and immediately names the differentiator: identical fetch logic to scrapewise_get_scraper_load_site but the body is wrapped in a {"content": "..."} JSON envelope. The opening sentence alone lets an agent separate this from the sibling that returns raw text/html.

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

Usage Guidelines5/5

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

Gives an explicit 'Use when' rationale (client/tooling expects application/json, downstream processor wants an envelope) and an explicit 'Don't use when' routing to scrapewise_get_scraper_load_site for clients that can handle text/html. Alternatives and selection conditions are both spelled out.

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.