Skip to main content
Glama

web_deep_search

Read-only

Researches complex questions across multiple sources, automatically composing queries and reading pages, then returns a synthesized answer with citations and source verification.

Instructions

Deep search: find, read and DIGEST AN ANSWER. The fifth tool of the module and the only one that answers a question rather than handing back material.

WHEN TO CALL. The question requires several sources to be brought together: what is happening with something, how one thing differs from another, what the figures of a specific organisation are. The tool composes the queries itself, reads the pages and writes an answer with references to the sources.

WHEN NOT TO CALL. You need a list of links — web_search is tens of times cheaper. You need the text of a known page — web_read. This tool spends a model and minutes; call it on a question, not on a query.

WHAT IT RETURNS. answer — the digested answer with [1]-style references; sources[] — the pages that were read; markers — the features used to check that the pages are about THE SUBJECT ASKED ABOUT; timing_ms — where the time went (searching, reading, the model); usage.by_model — tokens per model, with money left to whoever holds the price registry.

HOW TO READ THE ANSWER — five things.

  1. THE MAIN FIELD IS outcome, NOT answer. Five values: found — the markers met on a page; ambiguous — the sources hold SEVERAL DIFFERENT subjects under this name, and they are listed in ambiguity.variants; off_target — material was found but about ANOTHER subject (a namesake, a different city); not_found — there are no sources; unknown — there were no markers, so there was nothing to check with. On off_target the answer looks convincing and is about the wrong thing. On ambiguous the answer applies to THE LARGEST GROUP and not to all of them: the other variants are real, and if one of them is wanted, ask the person or refine the question rather than choosing yourself.

  2. summarised_from_on_target says whether the answer was digested from verified pages or from whatever was found. False means read the answer as a draft.

  3. stopped_because and waves_done show HOW MUCH work was done. A full answer and a short one look alike; this is the only place they can be told apart.

  4. THREE NUMBERS ABOUT SOURCES, AND THEY ARE DIFFERENT. sources_total — how many were found; sources_with_content — how many could be read (a block returns zero characters and stays in the list); sources_on_target — on how many the markers met. The answer stands on the third number and sounds weighty because of the first.

  5. sources_confirmed_2plus and confirmed_by_engines count INDEPENDENCE, not correctness: how many different engines found the same link. On an ambiguous name the most corroboration goes to the best-indexed namesake. If the answer looks confident while the question admits several different subjects under one name, look at outcome first: ambiguous means the tool composed exactly that answer — the variants are in ambiguity.variants, and the digest applies to the largest group only. Corroboration counts do NOT decide between them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wavesNoat most this many search waves, default 3. A wave stops by itself as soon as the markers meet — the ceiling bounds the worst case, not the ordinary one
questionYesthe whole question, in your own words. Not a search query: the tool composes the queries itself

Schema Changelog

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

  1. First observedv0.2.1

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations by explaining nuanced behaviors: outcome values like ambiguous, off_target, and not_found; the meaning of summarised_from_on_target; how stopped_because and waves_done reveal work done; and how corroboration counts indicate independence rather than correctness. It also warns about misleadingly confident answers on ambiguous names. This is exceptionally transparent.

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?

The description is long and highly detailed, but it is well-structured with clear sections and a numbered list. Some points are repeated for emphasis (e.g., the ambiguity caveat appears both in the outcome list and later in the corroboration section), which adds length but also reinforces critical guidance. Overall, the structure justifies the length given the tool's complexity.

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?

With no output schema, the description carries the full burden of explaining return values and interpretation. It thoroughly covers the fields outcome, summarised_from_on_target, stopped_because, waves_done, sources_total, sources_with_content, sources_on_target, sources_confirmed_2plus, confirmed_by_engines, and ambiguity.variants, and explains how to distinguish a full answer from a short one. Nothing essential 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?

The schema already documents both parameters with descriptions, but the tool description adds valuable usage nuance: the question should be in the agent's own words rather than a search query because the tool composes queries itself, and the waves parameter bounds the worst case rather than the typical case. This meaningfully supplements the schema.

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 clearly states the tool's purpose: deep search that finds, reads, and digests an answer to a question rather than returning raw material. It explicitly distinguishes itself from sibling tools like web_search and web_read, making its unique role unambiguous.

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?

The description provides explicit WHEN TO CALL and WHEN NOT TO CALL guidance. It states to use this tool when a question requires synthesizing several sources, and to use web_search for lists of links or web_read for known page text. This gives the agent clear decision rules and mentions the alternatives by name.

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