Skip to main content
Glama

Search the web

search_web

Search the web for a query and return the ranked results, each with its title, url and snippet. The results are read from Google's results page, or Bing's when Google refuses. Use it to find pages whose URLs you do not know. It searches the web, unlike list_pages with q, which searches inside a project's stored run. For URLs you already have use scrape_urls; scrape_urls with full=true reads one result in full. Inputs: query as typed into a search engine, e.g. 'python http client'. scrape=true also fetches each result's page as markdown in the same call. include_domains=['python.org'] keeps the search to those sites; exclude_domains drops sites, and an exclude wins. Cost: Google's results page is read with a browser, 4 credits or more where it needs the stealth tier; Bing's, used when Google refuses, is a plain fetch at 1. A results page the engines refused is free. An equal search (same query, country, lang, freshness and domains) within an hour of a finished one comes from cache with no charge for the results page. Scraped pages are charged, cached or not. Timing: it waits for the results. If a search outlasts the connection's time limit, a job comes back for get_job; a scraping search whose pages are still landing returns its results with a job for the pages. Needs write access; a read-only connection is refused with code 'read_only'.

Input Schema

NameRequiredDescriptionDefault
langNoA language code for the results, e.g. 'en'; omit for the default.
limitNoHow many results to return, 1 to 10 (default 10).
queryYesWhat to search the web for, 1 to 400 characters, as it would be typed into a search engine.
scrapeNotrue also fetches each result's page as markdown; each page costs credits. false (default) returns the results only.
countryNoA 2-letter country code to search from, e.g. 'us' or 'de'; omit for the default.
freshnessNoOnly results from the last hour, day, week, month or year; omit for any time.
exclude_domainsNoUp to 20 sites to leave out of the results, e.g. ['pinterest.com']; an exclude wins over an include.
include_domainsNoUp to 20 sites to search within, e.g. ['python.org']; omit for the whole web.

Output Schema

NameRequiredDescriptionDefault
idNoThe search's id: for get_job with kind 'search'.
jobNoWhile it is still going: {kind: 'search', id} for get_job. A scraping search can carry its results and a job for the pages still landing.
codeNoOnly on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.
noteNoThe cache rule, and what to do next when it is still going.
errorNoOnly when the call failed: what went wrong, in words an assistant can act on.
queryNoThe query as searched.
cachedNotrue when an equal search within the hour answered it, with no charge for the results page.
detailNoOnly on a failure: the API's own wording, when the error was rephrased.
engineNoThe engine whose results page answered, e.g. 'google' or 'bing'.
statusNo'done'; 'blocked' when every engine refused the results page (nothing charged); 'running' with a `job` while it goes on. On an error, the HTTP status code.
resultsNoUp to 10, as ranked, each {position, title, url, snippet, source, engine}; when scraped also `page`, {url, title, words, status, links (a count), markdown excerpt}, the excerpts sharing 60,000 characters.
attemptsNoBlocked only: each engine tried, and why it was refused.
creditsUsedNoCredits this search spent, scraped pages included.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations give readOnlyHint=false, openWorldHint=true, destructiveHint=false, but the description adds substantial behavior beyond them: engine fallback order (Google then Bing), per-engine credit costs, free-refused-page rule, one-hour cache semantics, scraped-page charging, job/timeout behavior, and an explicit write-access requirement with the 'read_only' refusal code. This is unusually rich disclosure for a network-bound tool.

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?

Dense but well-structured into Inputs / Cost / Timing / Access blocks with the core purpose front-loaded. Every sentence carries operational information, though the cost and caching detail is long enough that it slightly overshoots what a routing decision needs.

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?

Given an output schema exists, return values need no explanation, and the description instead covers the things structured fields cannot: engine fallback, cost model, job handoff for long searches, and auth requirements. Nothing an agent needs to invoke 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 100%, so the baseline is 3, but the description adds real meaning: example query syntax, that scrape=true fetches pages in the same call, that include/exclude_domains take up to 20 sites, and that an exclude wins over an include. It does not cover lang, country, freshness, or limit (those rest entirely on the schema), which keeps it off a 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+resource ('Search the web for a query') and immediately describes the shape of the return (ranked results with title, url, snippet). It explicitly distinguishes itself from list_pages and scrape_urls by name, so an agent can route without opening any schema.

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 when-to-use ('find pages whose URLs you do not know'), when-not ('for URLs you already have use scrape_urls'), and names the sibling alternatives with the condition that selects each. Nothing is left to inference.

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.