Skip to main content
Glama

gemini_research

Read-only

Research live web questions and get cited-source answers for current facts, releases, prices, docs, or comparisons newer than your training data.

Instructions

Research a question on the live web with Gemini and Google Search, and get an answer that cites its sources. Use it for current facts, releases, prices, docs or comparisons that may be newer than your training data.

    Runs through the Antigravity CLI on the user's Google AI Pro plan: no API
    cost, uses the plan's limits. Read-only. Gemini prefers official sources,
    cross-checks key facts and says when sources disagree. Usually takes about
    a minute. For questions about local files use gemini_ask instead.

    Args:
        question: What to find out, with context that narrows it, e.g.
            "What changed in Flutter 3.47 for Android builds?".
        model: Model id from gemini_models, e.g. "gemini-4-argon-high";
            omit for agy's default (or GEMINI_PRO_AGY_MODEL).
        effort: Reasoning effort: "low", "medium", "high", "xhigh" or "max".

    Returns:
        The answer followed by a "Sources" list of URLs, and a conversation_id;
        pass it to gemini_ask to ask follow-up questions in the same chat.
    

Input Schema

NameRequiredDescriptionDefault
modelNo
effortNo
questionYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: it discloses the execution path (Antigravity CLI), the billing model (no API cost, consumes the user's Google AI Pro limits), latency (~a minute), and the answer's sourcing behavior (prefers official sources, cross-checks, flags disagreement). The conversation_id handoff to gemini_ask is an extra behavioral fact an agent could not infer.

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 purpose, then cost/latency/safety, then the sibling pointer, so the most decision-relevant content comes first. The Args/Returns block is standard and tight, though the 'Returns' prose partly restates what the existing output schema already provides.

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?

For a three-parameter open-world research tool with an output schema and full annotations, nothing material is missing: cost, runtime, trustworthiness of sources, follow-up chaining, and the alternative tool are all covered.

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?

With 0% schema description coverage, the description fully compensates: it explains that 'question' should include narrowing context and gives a concrete example, that 'model' expects an id from gemini_models with a documented default fallback, and what 'effort' controls.

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 concrete verb and resource: 'Research a question on the live web with Gemini and Google Search, and get an answer that cites its sources.' It also distinguishes itself from siblings by naming gemini_ask for local files and gemini_models as the source of model ids.

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 explicit when-to-use conditions ('current facts, releases, prices, docs or comparisons that may be newer than your training data') and an explicit exclusion routing local-file questions to gemini_ask. The model parameter even points at gemini_models for valid ids.

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