Skip to main content
Glama
Sign In
machinemates-ai

Gemini Research MCP Server

by machinemates-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Export Research Session

export_research_session
Read-onlyIdempotent

Save a completed or interrupted research session as Word, Markdown, or JSON, so you can recover the report or share it as a DOCX document.

Instructions

Save (export, download, archive) a completed research session to a file on disk — Word (.docx), Markdown (.md), or JSON. Use this to recover your report after a research_deep run completes or is interrupted, and to convert reports into a shareable Word document.

Disk-first contract. The file is always written to disk, and the absolute path is returned on the first line of the response as Saved to: <path>. When output_path is omitted the file lands in GEMINI_RESEARCH_EXPORT_DIR (default ~/.gemini-research/exports/). An EmbeddedResource is still attached so GUI hosts can expose their native "Save As" affordance.

Similar to Google's Deep Research export feature, the DOCX output is a professional Word document suitable for sharing, archiving, or further editing.

Supported formats:

  • docx: Word document with headings, lists, and table of contents

  • markdown: Clean .md file with full report and citations

  • json: Machine-readable, all metadata preserved

Typical recovery flow:

  1. research_deep(...) completes (or is resumed via resume_research).

  2. export_research_session(format="docx") — no other arguments needed; the path on disk is returned in the response text.

Input Schema

NameRequiredDescriptionDefault
queryNoOptional: search for a session by query text instead of interaction_id
formatNoExport format: 'markdown' (.md), 'json' (.json), or 'docx' (Word document)markdown
output_pathNoFilesystem path to save the exported file to. Absolute or relative to the MCP server's working directory. If omitted, the file is automatically written to GEMINI_RESEARCH_EXPORT_DIR (default ~/.gemini-research/exports/) and the resolved path is returned in the response. Parent directory must already exist when an explicit path is supplied.
interaction_idNoInteraction ID of the session to export. If not provided, exports the most recent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior2/5

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

The description is behaviorally rich — disk-first contract, default export directory, mandatory return of 'Saved to: <path>', parent-directory requirement — which goes well beyond the annotations. But it explicitly says the file 'is always written to disk', which conflicts with readOnlyHint=true; the description rescues the agent from being misled, yet the definition still contains an internal inconsistency an agent must resolve.

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-loaded with the purpose and the disk-first guarantee, and the recovery flow is scannable. It runs long for a four-parameter tool — the 'Similar to Google's Deep Research' sentence and part of the recovery flow restate usage that was already established.

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?

No output schema exists, and the description compensates fully by specifying the response shape (absolute path on the first line as 'Saved to: <path>') and the attached EmbeddedResource for GUI hosts. An agent knows what it will get back before calling.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: what each format actually produces (docx with headings/lists/TOC, markdown with citations, json with metadata) and the fallback behavior and location when output_path is omitted. This lets an agent choose a format without guessing.

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?

Specific verb set (save/export/download/archive), specific resource (a completed research session), and enumerated output formats. An agent can immediately distinguish it from research_deep or resume_research, which produce or resume the session rather than persist it.

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?

States exactly when to reach for it ('to recover your report after a research_deep run completes or is interrupted') and provides a numbered recovery flow showing the preceding sibling call and that no other arguments are required. Nothing about when-not or prerequisites is left to inference.

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

Deploy Server

Other Tools