Skip to main content
Glama

URLpipe

by dev.urlpipe
OverviewDiscussionsAdmin

Summarize a page

summarize_page
Idempotent

Exposes POST /summarize. Returns a concise Markdown summary of the page's main content, with the navigation, ads and boilerplate left out.

The most expensive operation we sell, at 17 credits, because it runs a language model over the page. If YOU are the model that will read it, fetch_markdown gives you the whole page for 1 credit and you can summarize it yourself — this tool is for when the summary is the artefact being produced, not a step on the way to one.

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.
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.
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.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations, the description reveals that this is the most expensive operation at 17 credits, that it runs a language model over the page, and that the output strips boilerplate. This gives the agent important cost and behavior context that annotations do not convey.

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 compact and front-loaded, with the core behavior in the first sentence and the cost/usage guidance in the second. Every sentence earns its place, and the alternative-tool guidance is integrated without verbosity.

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?

The description, combined with the complete parameter schema and annotations, gives the agent enough to select and invoke the tool correctly. It explains cost, output format, and when to prefer a sibling. It does not detail the async return behavior, but the schema's sync parameter and sibling get_result already cover that path.

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

Parameters3/5

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

All 9 parameters are already fully described in the schema, so the description does not need to repeat them. The high-level description correctly orients the agent toward the resource and result, but it adds no parameter-specific detail beyond 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?

The description names the exact endpoint ('POST /summarize'), states the output ('concise Markdown summary of the page's main content'), and specifies what is excluded ('navigation, ads and boilerplate'). It clearly separates this tool from cheaper page-fetching siblings like fetch_markdown by emphasizing that the summary itself is the product.

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?

The description gives explicit decision guidance: it is the most expensive option at 17 credits, and if the model is reading the page for itself, fetch_markdown is cheaper at 1 credit. It closes by stating the exact condition for using this tool: 'when the summary is the artefact being produced, not a step on the way to one.'

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