PublicWWW

Extract data from a cluster

extract_from_cluster

Pull values out of the page source of every website in a cluster: contacts, social profiles, analytics and tag ids, anything a regular expression can match. Easiest: name ready-made presets - email (email addresses from mailto: links), phone (phone numbers from tel: links and schema.org telephone), whatsapp (WhatsApp numbers (wa.me and click-to-chat links)), telegram (Telegram usernames (t.me and tg:// links)), viber (Viber numbers (viber:// links)), line (LINE account links (line.me)), facebook (facebook.com page links), instagram (instagram.com profile links), x (x.com and twitter.com profile links), linkedin (linkedin.com personal and company profile links), youtube (youtube.com channel links and video links (youtu.be, embed)), tiktok (tiktok.com profile links), pinterest (pinterest profile links), threads (threads profile links), bluesky (bsky.app profile links), discord (Discord server invite links), github (github.com user and organization profile links), google_play (Google Play app ids (package names)), app_store (App Store app ids). Or write regex: PCRE in slashes, the first capture group is the value (with no group, the whole match), e.g. /data-site-id="([0-9]+)"/i. Up to 10 expressions, one column each. Works through the cluster in parts of up to 100 domains: call again with offset = next_offset until it is null. Costs extraction points: each website found in the index costs as many points as values found, 0.1 if none; the account tool shows the daily allowance. It reads every indexed page of a website, not only the home page. Every call is paid for, a repeat of the same websites too: keep the answer and go on from next_offset. The REST API gives the same as a file (format=csv). A worked example, from a niche to contacts: the read_docs page clusters/example-contacts.

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": {
      "cluster": "<cluster>"
    },
    "name": "extract_from_cluster"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Domains to go through in this call.
`regex`	No	Your own expressions, e.g. ["/hjid['\"]?\\s[:=]\\s([0-9]+)/"].
`offset`	No	Where to start in the cluster; next_offset from the previous call.
`cluster`	Yes	Cluster id, from list_clusters or create_cluster.
`presets`	No	Ready-made expressions by name, e.g. ["email", "phone"]. Presets and regex together: up to 10.
`include_empty`	No	Also list websites where nothing matched.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 8, 2026

changedInput schema / properties / presets / description

Previous value: -"Ready-made expressions by name, e.g. [\"email\", \"phone\"]."New value: +"Ready-made expressions by name, e.g. [\"email\", \"phone\"]. Presets and regex together: up to 10."

addedInput schema / properties / presets / maxItems
```
Added value: +10
```
addedInput schema / properties / regex / maxItems
```
Added value: +10
```

First observedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations, which only declare openWorldHint=true and non-idempotent/non-readonly. The description discloses the metering model (points per site equal to values found, 0.1 if none), that repeat calls on the same sites are charged again, and that extraction covers every indexed page rather than just the homepage — exactly the cost and side-effect context an agent needs before invoking.

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

Conciseness3/5

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

Front-loaded with the purpose, but the 19-preset parenthetical block is a long wall of text that duplicates the schema enum names and pushes the critical cost and pagination warnings toward the end. Every sentence is informative, yet the layout makes the highest-stakes information (billing per call) easy to miss.

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 paid, paginated, open-world extraction tool with no output schema, the description still covers return shape (one column per expression, include_empty behaviour, next_offset), the paging contract, cost, and a pointer to a worked example and the CSV REST alternative. Nothing an agent needs in order to call it correctly is missing.

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 already 100%, so the baseline is 3, but the description adds real meaning: presets are explained by what each one actually matches (mailto:, tel:, wa.me, t.me, etc.), regex must be PCRE in slashes with the first capture group as the value, and the 10-expression/one-column limit is spelled out. Offset and limit semantics are restated rather than expanded, so it stops short of 5.

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 — 'Pull values out of the page source of every website in a cluster' — and enumerates the value classes (contacts, social profiles, analytics/tag ids). No sibling tool does extraction from cluster page source, so the boundary is unambiguous.

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?

Explicitly offers the two modes of use ('Easiest: name ready-made presets' vs 'Or write regex') with the selection heuristic implied, plus the pagination loop instruction ('call again with offset = next_offset until it is null'). It also warns against re-running the same sites. It does not contrast with siblings like search or build_signatures, which keeps it below a 5.

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

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