Scrapewise

scrapewise_preview_scraper_from_curl

Read-onlyIdempotent

        Same idea as scrapewise_preview_scraper_from_url but the input is a `curl`
        invocation rather than a bare URL. Use this when the target endpoint needs
        custom request shape — cookies, headers, an authentication bearer, or a POST
        body — that wouldn't survive a plain GET. The service parses the curl line,
        replays the request as instructed, then runs every applicable detection
        strategy on the response. Gated by the API feature flag: only customers
        whose plan includes API access can use this entry point. Like
        scrapewise_preview_scraper_from_url, this is a preview / discovery endpoint:
        nothing persists. Pick a candidate, then call scrapewise_create_scraper.

        Args:
          - body (SimpleModeWithCurlDTO, required): the curl-based descriptor.
              - id (string, optional): existing scraper id if previewing changes
              - name (string, required): display name for the future scraper
              - groupId (string, required): owning group's MongoDB ObjectId
              - curl (string, required): a full curl command (single-line or with
                line continuations); supports -X / -H / -d / --cookie / etc.

        Returns:
          `Set<ScraperSampleDataDTO>` — one entry per detection strategy that
          produced data. Each carries the candidate `scraperDTO` (ready to persist
          via scrapewise_create_scraper), `sampleData` rows, and `executionTimeSec`.
          Empty set means no strategy succeeded.

        Examples:
          - Use when: "scrape this paginated GraphQL endpoint" — paste the curl
            from DevTools → preview shows which detector handles the response shape
          - Use when: "the page only loads behind a session cookie" — curl carries
            the cookie, the preview replays it
          - Don't use when: a plain GET to a public URL works → use
            scrapewise_preview_scraper_from_url (cheaper, no curl parsing)
          - Don't use when: the customer's plan lacks the API feature → call would
            402; check plan first via the customer/plan tools

        Error Handling:
          - 200 with empty Set if no strategy produced data from the response.
          - 400 if the curl string is malformed (parser rejects).
          - 401 Unauthorized if no Firebase JWT or API key.
          - 402 if the customer's plan does not include the API feature.
          - 500 INTERNAL with `correlationId` if a detector or downstream proxy
            crashes mid-pass.

[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": {
      "body": "<body>"
    },
    "name": "scrapewise_preview_scraper_from_curl"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description still adds real value: 'nothing persists' (preview/discovery only), curl parsing and replay semantics, plan-based access gating, and a full error taxonomy (200 empty set, 400 malformed curl, 401, 402, 500 with correlationId). One minor tension is that replaying an arbitrary curl to an external endpoint reads as open-world behavior while openWorldHint is false; this is more an annotation nuance than a description contradiction.

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 purpose and the sibling distinction, then cleanly sectioned into Args/Returns/Examples/Error Handling. It is long, but nearly every section earns its place for a nested-payload tool; the prose leading paragraph could be tightened slightly.

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?

For a single-parameter-but-nested tool with no output schema, the definition covers input meaning, return shape (Set<ScraperSampleDataDTO> with scraperDTO, sampleData, executionTimeSec, and what an empty set means), access prerequisites, and failure modes. Nothing an agent needs to invoke it correctly 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 description coverage is 0%, so the description carries the full burden — and it does: each nested field is explained (id = existing scraper id when previewing changes, name = display name for the future scraper, groupId = owning group's MongoDB ObjectId, curl = full curl command supporting -X/-H/-d/--cookie). This adds meaning well beyond bare string types.

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?

The description opens with a specific verb+resource ('preview a scraper from a curl invocation') and immediately anchors it against the sibling: 'Same idea as scrapewise_preview_scraper_from_url but the input is a curl invocation rather than a bare URL.' It also names the concrete differentiator (custom request shape — cookies, headers, bearer auth, POST body), so an agent can pick it apart from the URL-based sibling without opening either schema.

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?

There are explicit 'Use when' and 'Don't use when' blocks, including the direct alternative route (plain GET to a public URL → use scrapewise_preview_scraper_from_url) and a prerequisite check (plan must include API feature, else 402). The workflow follow-on ('Pick a candidate, then call scrapewise_create_scraper') is also stated.

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

All Scrapewise tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.