Skip to main content
Glama

Deep research (Google)

deep_research_google
Read-only

Runs multi-term Google research by searching each query, re-ranking and de-duplicating results locally, then fetching top pages as text; falls back to metasearch if Google blocks.

Instructions

Deep research using only Google: each term is searched, re-ranked locally, de-duplicated and the best pages fetched as text. Google often blocks scrapers. If it returns nothing, the terms are retried with ddgs "auto" metasearch and a warning is sent.

Input Schema

NameRequiredDescriptionDefault
include_urlsNoWhether to include each page's source URL.
search_termsYes2-5 specific, related search queries.
top_k_per_termNoNumber of top-ranked results to keep per search term.
num_results_per_termNoNumber of results to rank per search term.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • changedInput schema / properties / include_urls / description
      Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."
    • changedInput schema / properties / num_results_per_term / description
      Previous value: -"Number of results to fetch per search term."New value: +"Number of results to rank per search term."
    • changedInput schema / properties / search_terms / description
      Previous value: -"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."New value: +"2-5 specific, related search queries."
    • changedInput schema / properties / top_k_per_term / description
      Previous value: -"Number of top scored results to keep per search term."New value: +"Number of top-ranked results to keep per search term."
  2. Changed4 schema fields changedv1.0.4
    • addedInput schema / properties / include_urls / description
      Added value: +"Whether to include URLs in the results."
    • addedInput schema / properties / num_results_per_term / description
      Added value: +"Number of results to fetch per search term."
    • addedInput schema / properties / search_terms / description
      Added value: +"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."
    • addedInput schema / properties / top_k_per_term / description
      Added value: +"Number of top scored results to keep per search term."
  3. Addedv1.0.1

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses real behavioral facts: Google blocks scrapers, the pipeline re-ranks and de-duplicates locally, pages are converted to text, and a ddgs fallback fires with a warning when nothing is returned. That failure-mode and fallback disclosure is genuinely useful for an agent interpreting empty or warned results.

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?

Three tight sentences, front-loaded with what the tool does and followed by the failure mode and fallback. No filler, though the trailing fallback clause could be trimmed or merged for clarity.

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?

An output schema exists so return-format explanation is unnecessary, and annotations cover the safety profile; the description supplies the pipeline, the scraping risk, and the fallback. What remains missing is guidance on choosing this over deep_research_ddgs or rag_search_google.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description loosely explains the rank-then-keep pipeline that underlies num_results_per_term versus top_k_per_term, but it never ties that pipeline to the parameter names, so it adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete pipeline: each term is searched, re-ranked locally, de-duplicated, and the best pages fetched as text. The 'using only Google' scoping gives a rough handle against the ddgs siblings, but the added note that it falls back to ddgs 'auto' metasearch blurs how it differs from deep_research_ddgs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this is the Google-flavored deep research option versus deep_research_ddgs, but no alternative is named and no when-not condition is stated. The fallback sentence describes internal behavior rather than telling the caller when to pick this tool.

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