Skip to main content
Glama
taylorwilsdon

Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

by taylorwilsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Doc as Markdown

get_doc_as_markdown
Read-onlyIdempotent

Convert any Google Doc to Markdown preserving headings, bold, italic, links, lists, and tables. Optionally include comment anchor text for discussion context.

Instructions

Reads a Google Doc and returns it as clean Markdown with optional comment context.

Unlike get_doc_content which returns plain text, this tool preserves document formatting as Markdown: headings, bold/italic/strikethrough, links, code spans, ordered/unordered lists with nesting, and tables.

When comments are included (the default), each comment's anchor text — the specific text the comment was attached to — is preserved, giving full context for the discussion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tab_idNoOptional ID of a single tab to read (from inspect_doc_structure). When given, only that tab's content is rendered, without its child tabs and without a tab heading. When omitted, every tab is rendered.
document_idYesID of the Google Doc (or full URL)
comment_modeNoHow to display comments: - "inline": Footnote-style references placed at the anchor text location (default) - "appendix": All comments grouped at the bottom with blockquoted anchor text - "none": No comments includedinline
include_commentsNoWhether to include comments (default: True)
include_resolvedNoWhether to include resolved comments (default: False)
user_google_emailYesUser's Google email address
suggestions_view_modeNoHow to render suggestions in the returned content: - "DEFAULT_FOR_CURRENT_ACCESS": Default based on user's access level - "SUGGESTIONS_INLINE": Suggested changes appear inline in the document - "PREVIEW_SUGGESTIONS_ACCEPTED": Preview as if all suggestions were accepted - "PREVIEW_WITHOUT_SUGGESTIONS": Preview as if all suggestions were rejectedDEFAULT_FOR_CURRENT_ACCESS

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.26.0
    • addedInput schema / properties / tab_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional ID of a single tab to read (from inspect_doc_structure).\nWhen given, only that tab's content is rendered, without its child tabs\nand without a tab heading. When omitted, every tab is rendered."
+}
  2. Addedv1.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds valuable behavioral detail beyond that: Markdown constructs preserved, comments included by default, and anchor text retained for comment context. There is no contradiction with the annotations.

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?

Three focused paragraphs: core function, sibling differentiation, and comment behavior. Each sentence earns its place and the most important information is front-loaded.

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 read-only tool with rich schema descriptions, an output schema, and safety annotations, the description supplies the missing high-level context: Markdown conversion, differentiation from get_doc_content, and comment anchoring. Nothing needed for correct invocation is missing.

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?

The input schema already has 100% description coverage with detailed parameter docs, so the baseline is 3. The description adds meaningful context about comment anchoring and default comment inclusion, though it appropriately leaves tab/suggestion-mode specifics to the schema.

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 ('Reads'), a clear resource ('Google Doc'), and a concrete output ('clean Markdown'), and immediately distinguishes itself from get_doc_content's plain-text output. An agent can identify what this tool does and which sibling it complements without opening the schema.

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?

It explicitly names get_doc_content as the alternative and contrasts plain text vs. Markdown, giving a clear selection criterion. The comment-context sentence further clarifies a distinctive use case for this tool over the plain-text sibling.

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