Skip to main content
Glama

web_search

Read-only

Search the web via multiple engines, get links with source corroboration and page content. Use min_engines to require independent confirmation.

Instructions

Web search through our own metasearch layer over several independent search engines. Returns links together with information about WHO found them and how far that source can be trusted.

WHEN TO CALL. You need fresh information from the web; you need to find an organisation or a person by name. For the second and third page of results, use the same call with page=1, 2 and so on; pages are numbered from zero.

TO CHECK A FACT AGAINST INDEPENDENT SOURCES, ASK FOR IT. By default the sweep STOPS at the first engine that gave enough links — that is the cheap path, and one engine is one witness. min_engines: 3 (or corroborate: true) keeps asking, and only then do corroborated_by_url and corroborated_by_domain count anything. It costs several times the outbound requests.

IT READS BY DEFAULT. The top three links are fetched and their text arrives in the same answer in the content field — no second call is needed for the content. If you only need an overview, set read=false and the call again costs a fraction of a second.

WHEN NOT TO CALL. You need the text of a KNOWN page (you already have the address) — that is web_read, which reads up to five addresses and offers a cursor over a long document. You need a finished ANSWER across several sources rather than material — that is web_deep_search. Not suitable for searching inside a known document or repository.

HOW IT DIFFERS FROM web_deep_search. Here there is ONE pass: what was found is what was read, and you compose the answer yourself from content. There the tool composes the queries itself, goes in waves and returns a DIGESTED ANSWER together with what it failed to find. This one hands you material, that one hands you a judgement.

WHAT IT RETURNS. results[] with title, url, snippet, domain, content (the page text for the ones that were read), chars, read_status; pages_read, pages_empty, pages_failed — how many pages were paid for and how many of them turned out to be a block; timing_ms split into search and reading; via — which engines found this particular link; corroborated_by_url and corroborated_by_domain — by how many engines the page and the site are independently corroborated; search_aborted is non-empty if the metasearch stopped answering MID-SWEEP, in which case the results are incomplete by no decision of ours and the engines that were missed are named in engines_unasked.

HOW TO READ THE ANSWER — five things that are easy to get wrong.

  1. AN EMPTY LIST IS A SUCCESS, not a failure: we looked and found nothing. A failure arrives separately, with ok=false and a reason. Do not repeat the query because the list was empty — repeat it rephrased.

  2. engines_skipped means "not asked" (the rate limit applied), NOT "asked and stayed silent". The silent ones are in unresponsive_engines, the ones that answered a different question are in engines_irrelevant.

  3. CORROBORATION IS NOT CORRECTNESS. corroborated_by_url means "this many independent engines found this same link" and does NOT mean "this answer is truer". On an ambiguous query the most corroboration goes to the best-indexed namesake rather than to the subject asked about: one name can belong to a retailer, an investigations platform, a maker of enclosures and a maker of portable power supplies at once, and all of them are real. If the sources describe DIFFERENT subjects under one name, the correct answer is "there are several, here they are", not a choice by the number of corroborations.

  4. engines_trust labels each engine: clean — checked against references and does not substitute the subject; substitutes — has answered about a namesake; not checked or unavailable — there is no information. If all_engines_clean is false, the results are worth verifying against features of the subject sought: an engine may have answered about a different company of the same name. The label candidate means "no misses yet, but fewer than three observations" — not "clean".

  5. A RESULT WITH text_source="not_recognised (scan)" IS A DOCUMENT WE DID NOT READ, not a page without text. It is a scanned PDF: search does not pay for a vision model on a link it merely found. If you need it, call web_read on that address — reading recognises it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNothe result page, from zero; default 0. A second page is for when the first did not contain what you sought, not for collecting more links at once
readNoTRUE by default — the tool reads the top pages and returns their content. Set false when you only need an overview of the results: the call then costs a fraction of a second instead of seconds, but there will be no content
queryYesthe search query, in any language; a non-Latin script switches the results to that language
read_topNohow many top links to read, 1..8; default 3. This is the main cost of the call: every page is a separate download
per_engineNohow many links to take from EACH engine; 0 means however many are still missing from max_results
corroborateNoa deprecated name for min_engines=3. Kept for older callers; in new code set min_engines as a number
max_resultsNohow many links to return, 1..50, default 6. The more you ask for, the more engines have to be queried — that is, dearer and slower
min_enginesNoquery AT LEAST this many engines, however many links were collected earlier. 0 (the default) means stop as soon as max_results are collected. Set 3 or more when you need independence of sources: `via` and corroborated_by_url will then name different witnesses. THE PRICE: as many times more outbound requests

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.2.1

TDQS

A5/5.0
Behavior5/5

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

The description is exceptionally transparent about failure semantics (empty list is success), engine statuses, corroboration limits, scanned documents, mid-sweep aborts, and cost behavior. Annotations readOnlyHint=true and destructiveHint=false are consistent; no contradiction.

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

Conciseness5/5

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

The description is long but highly structured with clear headers and numbered caveats. Every section addresses a distinct operational concern and earns its place; the front-loaded summary immediately conveys what the tool does and how it differs from siblings.

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?

Despite having no output schema, the description fully details the return shape (results[], pages_read, timing, via, corroboration fields) and provides the five easy-to-miss interpretation rules. The tool's complex behavior is covered completely enough for correct invocation and result handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description enriches every parameter with practical meaning: cost implications, deprecation of corroborate, page semantics, read_top limits, min_engines witness independence, and default behaviors. This goes well beyond the schema alone.

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?

The description states a specific verb and resource: a metasearch over several independent engines returning links and content. It explicitly contrasts with sibling tools web_deep_search and web_read, making the tool's unique role unmistakable.

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?

WHEN TO CALL, WHEN NOT TO CALL, and HOW IT DIFFERS give explicit conditions and name the alternatives (web_read, web_deep_search). Includes clear guidance on when to set min_engines, when to set read=false, and how to interpret empty results.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AG-Bureau/mcp-search'

If you have feedback or need assistance with the MCP directory API, please join our Discord server