PublicWWW

Create a cluster

create_cluster

Save a list of websites as a cluster, to extract data from them or combine with other clusters. From a search: pass 'query' (PublicWWW syntax, as in the search tool) - the cluster takes the results up to the plan's limit, and it costs one search. With like: that is the plan's maximum, so pass limit. From a list: pass 'domains' - names or urls; only sites in the index are kept (a www. name missing from the index is looked up without the www), nothing is spent; if none is in the index, no cluster is created. 'dropped' in the answer counts what was left out: not_a_domain, duplicate, not_in_index, over_limit. The plan caps the size of a cluster. To keep only some of a cluster's sites, make a new one from those domains: it costs nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_cluster"
  }
}

Input Schema

Name	Required	Description
`name`	No	Optional name; by default the query, or 'Upload'.
`limit`	No	With query: take only the first N websites, in the search's own order (popularity, or similarity for like:). By default - up to the plan's limit. With depth: several pages of one website make one domain, and N counts domains.
`query`	No	Search whose results become the cluster, e.g. "googletagmanager.com/gtm.js".
`domains`	No	Domains (or urls) to put into the cluster. Use either this or query.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / limit / description

Previous value: -"With query: take only the first N results, in the search's own order (popularity, or similarity for like:). By default - up to the plan's limit. With depth: it counts pages before they fold into websites, so the cluster can hold fewer than N."New value: +"With query: take only the first N websites, in the search's own order (popularity, or similarity for like:). By default - up to the plan's limit. With depth: several pages of one website make one domain, and N counts domains."

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / limit / description

Previous value: -"With query: take only the first N results, in the search's own order (popularity, or similarity for like:). By default - up to the plan's limit."New value: +"With query: take only the first N results, in the search's own order (popularity, or similarity for like:). By default - up to the plan's limit. With depth: it counts pages before they fold into websites, so the cluster can hold fewer than N."

First observedNov 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only tell the agent this is a non-read-only, non-destructive, non-idempotent, open-world write; the description adds the substantive behavior the annotations cannot: the credit cost of each mode, that the plan caps cluster size, that no cluster is created when no domain is indexed, the www-stripping lookup fallback, and the enumerated 'dropped' reasons (not_a_domain, duplicate, not_in_index, over_limit). That is exactly the extra context this dimension rewards.

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?

The content is dense and almost every clause carries information, but the phrasing is telegraphic ('With like: that is the plan's maximum, so pass limit.', 'From a search: ...') and the parenthetical chains make it harder to parse than necessary. Purpose is front-loaded, yet the middle sentences require re-reading.

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?

With no output schema, the description does the valuable work of explaining the 'dropped' field in the answer and the failure case where no cluster is created, plus cost and plan-cap behavior. It leaves the rest of the response shape (e.g. the new cluster's identifier) unstated, so it is strong but not fully complete.

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 the baseline is 3, and the description earns above baseline by adding meaning the schema does not carry: 'query' uses PublicWWW syntax as in the search tool, and with a 'like:' query the plan maximum applies so 'limit' should be passed. 'domains' accepting names or urls and the index-only retention rule are also reinforced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Save a list of websites as a cluster') and immediately frames the two creation modes (from a search, from a list). It never explicitly names a sibling such as combine_clusters or list_clusters as the alternative, so sibling routing is only implied, which keeps it below a 5.

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?

It clearly states the two usage paths and their conditions: pass 'query' for search results and pay one search credit, pass 'domains' for a free list. It also gives a useful workaround ('To keep only some of a cluster's sites, make a new one from those domains: it costs nothing'). It does not name an explicit alternative tool or a when-not-to-use case.

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.