Loading ToolBench
MCP server for Google Gemini Deep Research Agent via Interactions API
Server has 4 tools with explicit definitions and input schemas. Tool naming follows verb-noun convention (start_, get_, research_, list_). Descriptions are present but vary widely in quality and length. Parameter descriptions are minimal. Output schemas are not documented. Error handling returns error objects but lacks recovery guidance. This is a fair-quality server with significant gaps typical of community implementations.
check the status and retrieve results of a research task. IMPORTANT: research takes 2-20 minutes. do NOT poll continuously. if status is "in_progress", wait for user to ask again later or do other tasks first. only call this when user explicitly asks to check the research status.
list available research models and agents
quick research using google search grounding (returns in seconds). use this for fast queries that don't need deep investigation. for comprehensive research, use start_research instead.
start a deep research task using google's official deep research agent. powered by gemini 3 pro, performs multi-step web research with citations. returns immediately with a task_id - use get_research_status to check results. research typically takes 2-20 minutes.
Output schemas not documented for any tool. Tools return structured objects (task_id, status, result, sources, error) but the MCP tool definitions contain no 'outputSchema' field. Agents cannot statically plan downstream calls or parse responses without runtime discovery.
start_research and research_with_sources are functionally similar (both research tasks) but differ only in async vs sync behavior. Names do not distinguish them clearly. An agent reading names alone cannot confidently pick one. Recommendation: rename to 'start_deep_research' and 'quick_search' or similar.
Parameter descriptions are minimal or missing context. 'query' is described as 'the research question or topic to investigate' (good) but no guidance on length, format, or how to rephrase unclear user requests. 'task_id' has no format hint (UUID? string? opaque?). PROJ)' vs 'The project key', these descriptions are closer to the latter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Error handling returns error objects but lacks recovery guidance. Example: 'failed to start research: <error>' is a raw error message that tells the LLM nothing actionable. Per pattern:recovery-guide, errors should say 'User not found. Try search_users() with a partial name.' Here, a failed research start should suggest 'Check query syntax or try research_with_sources for a faster alternative.'
Does not explain return structure or when to call it. Agents may not understand why this tool exists or what to do with the results.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Per MCP spec 2026-07-28, tools should declare their safety properties. All 4 tools are READ_ONLY (no state mutation), but this is not declared in the tool definitions, only inferred from docstrings. Agents may not know these are safe to retry.
No validation or constraint documentation. 'query' parameter has no length limit documented. Research tasks support queries up to a certain size (unknown from this code); LLMs may pass huge, token-wasting queries.