Riveter MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Scrape

scrape

Fetch a webpage and return its text content synchronously, with optional country proxy routing or cache bypass for fresh results.

Instructions

scrape

Scrape a webpage and return the text content synchronously — the only endpoint here that doesn't return a run to poll. Unchanged from the legacy API (response uses the legacy request_status format).

Quick example

  curl -X POST https://api.riveterhq.com/v1/scrape \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

Credit costs

With proxy: 0.30 credits
Without proxy: 0.10 credits
From cache: 0.01 credits

Proxy usage

Scraping is not guaranteed to succeed without a proxy. Some websites may block requests or require specific geographic locations. To use a proxy, include proxy_country_code with a two-character country code (e.g. 'us', 'gb', 'de').

Caching

Recently scraped pages are cached to save credits (0.01 credits on a cache hit). Set skip_cache: true to always fetch fresh content.

Input Schema

Name	Required	Description
`url`	Yes	The URL to scrape
`skip_cache`	No	Set to true to bypass cache and always fetch fresh content
`max_credits`	No	Credit ceiling. Refused with 422 credit_cap_exceeded (nothing charged) when the estimate's maximum exceeds it.
`estimate_cost`	No	Validate and price the request without running or charging anything; the 200 response is the credit estimate (EstimateCostResult).
`proxy_country_code`	No	Optional two-character country code for proxy (e.g. 'us', 'gb', 'de')

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.5Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag openWorldHint and non-idempotency, and the description layers on context they cannot carry: synchronous versus run-polling semantics, per-call credit pricing tiers (0.30/0.10/0.01), proxy blocking risk, cache-hit behavior, and the fact that the response uses the legacy request_status format.

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-loads the core synchronous-distinction sentence, then organizes secondary detail into labeled sections (example, credits, proxy, caching) that are easy to scan. The embedded curl example is useful for an HTTP-style API but adds length that a strict reader could call excess.

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?

Covers the operational essentials: sync execution, credit costs, proxy necessity, caching, and the legacy response format. Since there is no output schema, a brief note on the returned fields beyond 'legacy request_status format' would have closed the last 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 baseline is 3, but the description adds real meaning beyond the schema for proxy_country_code (why you need it, with example codes) and skip_cache (tied to credit savings), plus cost implications for the request overall. max_credits and estimate_cost are left entirely to the schema.

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 and resource ('Scrape a webpage and return the text content') and explicitly differentiates from every run-based sibling by calling itself 'the only endpoint here that doesn't return a run to poll.' An agent can immediately tell this apart from run_extraction, get_run, or get_run_result.

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

Usage Guidelines4/5

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

Gives clear conditional guidance inside the tool: use a proxy when the target may block or require geo, set skip_cache when freshness matters. It does not name alternative tools (e.g. run_extraction for structured extraction or quick_search) as the path to choose when scraping is not the right call, leaving that inference to the agent.

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