Google Workspace MCP Server

Overview Schema Source Related Servers Discussions Admin

import_to_google_doc

Convert Markdown, DOCX, TXT, HTML, RTF, or ODT files into a new Google Doc, preserving formatting. Provide content directly, a local file path, or a remote URL to create the document.

Instructions

Imports a file (Markdown, DOCX, TXT, HTML, RTF, ODT) into Google Docs format with automatic conversion.

Google Drive automatically converts the source file to native Google Docs format, preserving formatting like headings, lists, bold, italic, etc.

Args: user_google_email (str): The user's Google email address. Required. file_name (str): The name for the new Google Doc (extension will be ignored). content (Optional[str]): Text content for text-based formats (MD, TXT, HTML). file_path (Optional[str]): Local file path for binary formats (DOCX, ODT). Supports file:// URLs. file_url (Optional[str]): Remote URL to fetch the file from (http/https). source_format (Optional[str]): Source format hint ('md', 'markdown', 'docx', 'txt', 'html', 'rtf', 'odt'). Auto-detected from file_name extension if not provided. folder_id (str): The ID of the parent folder. Defaults to 'root'.

Returns: str: Confirmation message with the new Google Doc link.

Examples: # Import markdown content directly import_to_google_doc(file_name="My Doc.md", content="# Title\n\nHello world")

# Import a local DOCX file
import_to_google_doc(file_name="Report", file_path="/path/to/report.docx")

# Import from URL
import_to_google_doc(file_name="Remote Doc", file_url="https://example.com/doc.md")

Input Schema

TableJSON Schema

Name	Required	Default
`content`	No
`file_url`	No
`file_name`	Yes
`file_path`	No
`folder_id`	No	root
`source_format`	No
`user_google_email`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.14.3Sep 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose key behavior: Google Drive converts the source, formatting is preserved, the extension is ignored, folder_id defaults to root, and the tool returns a confirmation message with a link. It does not mention authentication prerequisites or precedence if multiple sources are supplied, but the main side effect (creating a new Google Doc) is clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The structure is well organized: a one-line purpose, a brief conversion note, a detailed but necessary Args section, a Returns line, and three illustrative examples. Given the parameter count and zero schema descriptions, every section earns its place with little redundancy.

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?

The description is largely complete for a 7-parameter import tool: all parameters, defaults, format handling, and return value are covered. Minor gaps remain, such as not explicitly stating that only one of content/file_path/file_url should be provided and not mentioning whether prior Google authentication is required.

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?

Schema description coverage is 0%, so the description fully compensates: every one of the 7 parameters is explained with type, required/optional status, supported formats, defaults, and special behavior (e.g., source_format auto-detection, file_path accepting file:// URLs). The examples make parameter combinations concrete.

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 opens with a specific verb ('Imports'), a concrete resource (files in Markdown/DOCX/TXT/HTML/RTF/ODT), and a distinct outcome (conversion into Google Docs format). This clearly differentiates it from sibling tools like create_doc or create_drive_file, which create blank or generic Drive files.

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

Usage Guidelines4/5

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

The description gives clear context by naming supported formats, explaining auto-conversion, and showing three usage patterns (inline content, local file, remote URL). It does not explicitly name alternatives or state when not to use it, but the usage context is unambiguous enough for an agent to select this tool over blank-doc creation tools.

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

Deploy Server