Skip to main content
Glama

URLpipe

by dev.urlpipe
OverviewDiscussionsAdmin

Several results from one page visit

scrape_url
Idempotent

Exposes POST /scrape. Runs any subset of the other operations in one request, served from a single page visit where possible. Each operation is billed and stored exactly as the individual call would be, so this is not a discount — with one exception, and it is the reason to use it: a residential exit is charged per page VISIT, so several results off one visit pay the surcharge once.

Answers with one object keyed by operation, each entry carrying its own success and result, so a partial failure still returns everything that worked.

lighthouse does not share the visit — it runs its own audit on its own engine — so including it means two page fetches, and two surcharges when residential is on. So does a screenshot whose screenshot_options set viewport_width, viewport_height, device_scale_factor, dark_mode or block_ads: those change how the page loads, so the screenshot gets a visit of its own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to fetch. Must be a public http(s) URL.
syncNoWait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
deviceNoLighthouse only, when it is among the operations. Default mobile.
labelsNoYour own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
max_ageNoHow fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
report_toNoAsync only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
operationsYesWhich operations to run off this page.
project_idYesWhich project this request belongs to. From list_projects.
residentialNoFetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
page_optionsNoWhat to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too.
include_auditsNoLighthouse only: include the full per-audit detail. Default false.
idempotency_keyNoMakes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.
screenshot_optionsNoScreenshot only, when it is among the operations: how to take it, exactly as capture_screenshot takes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses billing semantics ('billed and stored exactly as the individual call would be'), the partial-failure response shape, and the visit-sharing exceptions. The idempotent and non-destructive hints are not contradicted, and the extra context materially improves the agent's model of the call.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and each paragraph earns its place: behavior, response shape, and cost caveats. The length is justified by the number of interacting options, and there is no redundant wording.

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 tool with no output schema, it describes the response structure explicitly. It also covers the important edge cases around residential surcharging, lighthouse, screenshot options, and partial failures, making the tool safely callable without needing to infer behavior from the schema alone.

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?

The input schema documents all 13 parameters, so the baseline is 3. The description adds cross-parameter meaning by clarifying how operations and certain screenshot_options affect page-visit sharing and cost, which is not evident from reading the schema alone.

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 states a specific verb and resource: 'Exposes POST /scrape' and 'Runs any subset of the other operations in one request.' This makes the batching behavior clear and differentiates it from the individual sibling tools such as fetch_html, capture_screenshot, and lighthouse_audit.

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?

It explicitly explains when to prefer this tool: with a residential exit, several results from one page visit pay the surcharge once, while noting this is not a discount. It also gives when-not guidance by calling out lighthouse and screenshot options that force separate page fetches and therefore do not share the visit.

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

All URLpipe toolsInspect
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.

Resources