Skip to main content
Glama

Web search and read the top pages

web_search_read
Read-only

Answers a research question in one call: searches the web, then reads the top results (up to 3) as clean Markdown with the same reader as scrape_markdown (main content, tables kept, PDFs supported), so an agent gets the sources' text instead of just links. A page that cannot be read (bot check, error) is skipped and the next result read instead, and listed in skipped. Also returns all results, a direct answer when there is one and related searches. Country, language and recency filters; characters per page are adjustable. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.012 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
readNoHow many of the top results to read as Markdown (1-3, default 3). Pages that cannot be read are skipped for the next result.
queryYesWhat to search for, e.g. "best open-source vector database 2026" or "site:sec.gov Apple 10-K".
countryNoTwo-letter country for local results, e.g. us, gb, de. Default: us.
languageNoTwo-letter language code, e.g. en, de, fr.
time_rangeNoOnly results from the past day, week, month or year (news, recent events).
max_chars_per_pageNoMarkdown characters per page (500-20000, default 8,000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: unreadable pages (bot checks, errors) are skipped into `skipped`, results/all-results/direct-answer/related-searches are returned, and the cost model is spelled out ($0.012 USDC via x402, charged only when a result returns, 400 and 4xx/5xx not settled). None of this is derivable from the readOnly/openWorld/idempotent hints.

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

Conciseness4/5

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

Front-loads the core behavior (search + read as Markdown) before secondary details, and every clause earns its place. It is dense and long, but the density is warranted by the billing and skip semantics.

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?

For a paid, complex tool with no output schema, it discloses the salient return fields (`skipped`, all results, direct answer, related searches) and the charging conditions. It stops short of describing the full response shape, but an agent has enough to call it correctly.

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; the description still adds routing value by grouping the filter parameters (country, language, recency) and the adjustable characters-per-page, reinforcing intent beyond the per-field schema text.

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 compound verb+resource ('searches the web, then reads the top results up to 3 as clean Markdown') and explicitly ties the reading behavior to scrape_markdown, so an agent can distinguish it from web_search and the raw scrape tools.

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?

Frames the use case clearly ('answers a research question in one call' and 'gets sources' text instead of just links'), which implies when to pick it over a link-only search. It names scrape_markdown as sharing the reader, but never gives an explicit when-not or direct routing rule against web_search or scrape_batch.

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.

Resources