Skip to main content
Glama

Search page source

search
Read-onlyIdempotent

Find websites whose page source (HTML, JavaScript, CSS) contains a string: a library name, a script url, a tracking or widget id, a meta tag, any code fragment. Results are ranked by site popularity. Look a technology up by its ready-made query on the examples pages (read_docs: the Technologies pages listed in its table of contents), not by its name. Query syntax: quote an exact phrase ("angular.min.js"); several words must all appear; a leading minus excludes a word (-wordpress); | means OR; site:de limits to a top-level domain, site:example.com lists the pages of one site, -site:com or -site:example.com leaves them out; depth:all searches inner pages too (by default only home pages, one per site) - then total counts pages, and sites counts the distinct websites among them (a lower bound when sites_exact is false; without depth: there is no sites). Websites about a topic or like a given one, most similar first instead of by popularity: like:"a few words" - websites about that topic, in any language, by meaning rather than the exact words (site:de keeps only that domain zone); like:example.com - websites about the same thing as that one (it compares home pages: when a shop or landing page has too little text there, the search finds nothing - describe the topic in words instead); with words, like: orders their results. like: is the topic of a site, not its code: websites that share code with given ones are found by build_signatures on a cluster of them. With like:, total counts everything the filters let through: read the first rows rather than total. rank is the place by popularity, 1 being the most popular, an estimate with no guarantees. More operators are in read_docs. Searches count against the account's daily allowance. At most 10 calls a minute of search and the cluster tools, shared with the REST API; account and read_docs do not count. On too_many_requests wait retry_after seconds. Ask for a small number of rows first.

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": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number; page * rows cannot exceed the plan's rows per query.
rowsNoResults per page, 20 by default. The plan caps it; larger pages are long - 100 is plenty for a model.
queryYesWhat to search for, in PublicWWW query syntax.
snippetsNoAlso return up to 3 short fragments of page source around the match for each result. It spends a snippet search. A query with no phrase to match (like: or site: alone) gets the page title instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, yet the description still adds substantial operational context: a daily allowance, a 10-calls-per-minute cap shared with the REST API (with account and read_docs exempt), the too_many_requests/retry_after protocol, and the meaning of total vs sites counters. The only gap is the exact result shape, which is partly covered by the rank/popularity discussion.

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 purpose is front-loaded and nearly every sentence carries real operator semantics, but the body is a single dense paragraph of semicolon-chained clauses that is hard to scan. It is long for a description, and the operator reference would be far more usable as a short structured list or pushed into read_docs.

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 search tool with no output schema, the description covers what an agent needs: query grammar, result ordering, the meaning of total/sites/rank, the snippets fallback to page titles, and rate-limit recovery. Nothing essential to calling it correctly or interpreting its output 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 100%, so the baseline is 3, but the description goes well past the schema's bare "PublicWWW query syntax" by documenting quoting, implicit AND, leading minus, | OR, site:/depth: modifiers, and the dual meaning of like:. Page, rows, and snippets get only marginal added meaning (the "ask for a small number of rows" hint) since the schema already explains them.

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?

Opens with a specific verb and resource: "Find websites whose page source (HTML, JavaScript, CSS) contains a string," then enumerates the kinds of strings (library name, script url, tracking id, meta tag, code fragment). It also distinguishes itself from siblings by name, pointing to read_docs for technology queries and build_signatures for shared-code lookups.

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?

Gives explicit when-to-use routing: look up technologies via the ready-made queries on the examples pages rather than by name, use like:"words" for topic similarity, and use build_signatures (not like:) to find sites sharing code. It also names the negative cases (like:example.com returns nothing for thin shop/landing pages) and advises starting with a small row count.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.