# Reported issues for gdocs-mcp Pod holds 20 of 37 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [gdocs-mcp](/mcp/gdocs-mcp). ## Most discussed ### Collapse the Drive tools onto filesystem vocabulary (ls/find/mkdir/cp/mv) ## The idea Reduce the tool surface by leaning on vocabulary the model already has, rather than inventing parameters it must be taught. Instead of five Drive tools with bespoke names, one tool speaking a filesystem it knows cold. This is not a new pattern here. The project already does it twice: `read_doc`/`overwrite_doc` borrow markdown, `edit_doc` borrows the `old_string`/`new_string` file-edit idiom, and 0.3.0 put text styling on CSS. ## When the trick works Three conditions have to hold [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/44) · 2026-08-16 · open · 2 comments ### Markdown parser misreads long underscore runs (signature blank lines) as bold delimiters ### Summary Signature blocks in lease documents commonly use long runs of plain underscores as blank lines to sign on (e.g. `_______________________`). When such a run appears in markdown passed to the doc-writing tools, the parser appears to misinterpret parts of the run as bold (`**`) emphasis delimiters, injecting stray `**` into the rendered document instead of leaving the underscores as literal blank-line characters. ### Repro While reformatting a lease document to match the signature-bloc [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/15) · 2026-07-13 · closed · 2 comments ### create_doc silently drops/merges text when content is a long, repetitive document ### Summary `create_doc`'s `content` parameter is a raw string with no file-passthrough option (`baseDir` only resolves relative *image* paths, not the document body). This means the calling model has to fully regenerate long documents as text rather than passing them through mechanically. For long, repetitive text — legal documents in particular, full of near-duplicate clauses like "Tenant shall..." / "Landlord shall..." — that regeneration step can silently drop or fuse substrings, with no err [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/14) · 2026-07-13 · closed · 2 comments ### Table and image insertion have split feature sets between the tool path and the markdown path ## What's wrong Tables and images can each be inserted two ways, and the two paths support different features. Which capabilities you get depends on which entry point you happened to use. ### Tables | | `insert_table` tool (`objects.ts:insertTable`) | markdown renderer (`document.ts:insertTableAt`) | |---|---|---| | per-column alignment | no | **yes** (`:---:` / `---:`) | | inline markdown in cells | no (plain text) | **yes** (`parseInline`) | | `columnWidths` | **yes** | no | | `headerShade` [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/29) · 2026-08-16 · closed · 1 comment ### feat: surface parent folder(s) in search_drive/list_folder results No tool can answer "what folder is this file/folder inside?" `search_drive` and `list_folder` results omit the `parents` field entirely, so there's no way to trace a folder's location upward — only top-down browsing from an id you already have. **Repro case:** found the "Legal" folder via `search_drive`, needed to know its parent to create an "Onboarding" folder as a sibling. No tool exposes that. **Why this is a quick fix, not a Drive API gap:** the code already fetches `parents` internally — [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/26) · 2026-08-05 · closed · 1 comment ### feat: create_folder — create a Drive folder No tool creates a Drive folder. `list_folder` lists contents of an existing folder, but nothing in the current set (`create_doc`, `update_doc`, `list_folder`, etc.) can create one. **Repro case:** wanted a new "Onboarding" folder alongside existing Beta/Legal folders to hold Pour5-branded team material (Connector Guide doc + PDF) that isn't legal. Had to create it manually in the Drive UI before any tool could move docs into it. **Why this is fixable:** Drive API has a plain `files.create` cal [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/25) · 2026-08-05 · closed · 1 comment ### feat: copy_doc — duplicate a Doc via Drive files.copy No tool duplicates an existing Doc. Current toolset has `create_doc` (new doc from markdown), `update_doc` (rename/move), `overwrite_doc` (replace body), but nothing that clones a Drive file the way "Make a copy" does in the Docs UI. **Repro case:** wanted to reuse a Pour5 letterhead template (which has a correctly-sized logo in the page header — see #23) for a new document. The only path was recreating it from markdown via `create_doc`, which can't reach header content, can't size body images [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/24) · 2026-08-03 · closed · 1 comment ### feat: read (and eventually write) document headers/footers No tool reads or writes a Doc's headers/footers — `read_doc`'s transformer only walks `body.content`; there is no reference anywhere in the codebase to `document.headers`, `firstPageHeaderId`, or `defaultHeaderId`. Content placed in a header (or footer) is completely invisible to every current tool. **Repro case:** compared a Pour5 letterhead template against a newly-created doc to see why an inserted logo looked oversized. `read_doc` on the template returned markdown with *no image reference a [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/23) · 2026-08-03 · closed · 1 comment ## Most recent ### Destructive commands in the Drive shell: wait for elicitation, and for someone to ask Deferred out of #44. The filesystem shell (`ls`/`find`/`mkdir`/`cp`/`mv`) ships with **no destructive command** — no `rm`, no `rmdir`. This records why, and what would have to change to revisit it. ## Nothing is being removed There is no destructive Drive tool in the surface today. No `delete_doc`, no `rmdir`. `unshare_doc` is sharing (deliberately out of #44's scope) and `delete_tab` is tabs. So deferring `rm` collapses nothing and loses no capability — it only declines to *add* one. That is [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/47) · 2026-08-21 · open · 0 comments ### Orphaned files are invisible: findable only if you already know they exist ## What's wrong A Drive file can end up with no parent. It still exists, still opens, still turns up in a search — but it is in no folder, so nothing that browses the tree will ever show it. You only find it if you already remember it is there, which is precisely what nobody does. On this account, 4 of 55 visible files are in that state: ``` MASTER_Colorado Pinball Pub… ownedByMe=false sharedWithMe=true Roof ownedByMe=true sharedWithMe=false Appliances [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/46) · 2026-08-16 · open · 0 comments ### set_style and edit_doc now overlap, and neither says which to use ## What's wrong Since 0.3.0, `` round-trips — the reader emits it and the writer parses it. That was the point of #30, and it had a side effect nobody recorded: there are now two ways to style existing text. ``` set_style({from: "the sentence"}, {color: "#1a73e8"}) edit_doc(old_string: "the sentence", new_string: 'the sentence') ``` Both work. Neither tool's description mentions the other. ## Why i [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/45) · 2026-08-16 · closed · 0 comments ### unshare_doc has no guard, and it is the one operation with no undo ## What's wrong Every other sensitive operation in the surface makes the caller echo back a fact they had to fetch first. `unshare_doc` takes nothing: ```ts inputSchema: { documentId: z.string(), email: z.string(), ...accountArg } ``` | tool | guard | required | |---|---|---| | `apply_suggestions` | `expectedChange`, `documentTitle` | yes | | `delete_tab` | `expectTitle` | yes | | `overwrite_doc` | `expectTitle`, `force` | no | | `update_doc` | `expectTitle` | no | | `resolve_comment` | `expe [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/43) · 2026-08-16 · closed · 0 comments ### list_permissions drops domain and allowFileDiscovery, so grants render as null ## What's wrong `src/drive/sharing.ts` requests only: ```ts const FIELDS = 'permissions(id,type,role,emailAddress,displayName)'; ``` `domain` and `allowFileDiscovery` are never asked for, so a domain-wide grant comes back with nothing identifying it: ```json { "id": "…", "type": "domain", "role": "reader", "email": null, "displayName": null } ``` Rendered, that reads as `null:reader`. ## Why it matters `list_permissions` exists to answer "who can see this". For the grant that is on **ever [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/42) · 2026-08-16 · closed · 0 comments ### A domain or group grant can be seen but never revoked ## What's wrong `unshare_doc` matches permissions by email: ```ts const perm = (await listPermissions(clients, fileId)).find((p) => p.email === email); ``` A `type: domain` or `type: group` permission has no `emailAddress`, so it can never match. `share_doc(role: "none")` is not an escape hatch either — `setLinkAccess` only ever touches `type === 'anyone'`. | permission type | can the surface revoke it? | |---|---| | `user` | yes, `unshare_doc` | | `anyone` (link) | yes, `share_doc(role: "no [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/41) · 2026-08-16 · closed · 0 comments ### Table styling (column widths, header shading, borders) is invisible on read and can't round-trip ## The goal A table's column widths and header shading — and its borders and padding — survive in the document but vanish the moment you read it. You cannot see them, preserve them while rewriting, or reproduce a table you already have. Live: a table built with 140pt/70pt columns, grey header shading, a 2pt red border, 12pt left padding and pinned header rows reads back as ``` | H1 | H2 | | --- | --- | | a | b | ``` Identical to a plain table. ## Correction to docs/limitations.md That page [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/33) · 2026-08-16 · closed · 0 comments ### overwrite_doc silently inherits the replaced text's styling ## What's wrong Google's `insertText` inherits the character formatting at the insertion point. `overwriteDoc` deletes the body and inserts the rendered markdown at the start of the (now empty) body — so the new content picks up whatever formatting the old first character had, even though the markdown asked for none. ## Repro (live) ``` seed a doc, then style its body bold + red "plain seed\n" {bold:true, color:{red:1}} overwrite_doc with completely plain markdown: "totally plain replac [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/32) · 2026-08-16 · closed · 0 comments ### read→write round-trip corrupts nested inline styles (bold+underline, bold+link) ## What's wrong `transformer.ts:renderRun` nests inline markup — it wraps a run in markdown and HTML in layers. `inline.ts:parseInline` is deliberately one level only: a container pattern captures its inner text and uses it **verbatim**, never re-parsing it. So anything the reader nests, the writer flattens into literal characters. ``` parseInline('**bold underlined**') -> [{ text: "**bold underlined**", underline: true }] // bold lost, asterisks literal parseInline('**[bold l [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/31) · 2026-08-16 · closed · 0 comments ### read_doc never emits color/font/size — the inline-HTML escape hatch is write-only ## What's wrong `DESIGN.md` §2 makes inline HTML the escape hatch for everything markdown can't say: > **Docs-only formatting** markdown can't express (alignment/justify, color, > font, size, spacing, indent, image dimensions) → inline HTML > (`

`, ``, > ``) …and states the point of the format is that formatting is **"visible in the read"**, so the agent can perceive *and verify* style changes. For colour, font and si [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/30) · 2026-08-16 · closed · 0 comments ### Tables and suggestions can't reach headers/footers (segment support gap) ## What's wrong §23 gave the doc a shared segment primitive: `resolveSegmentTarget` in `src/docs/segments.ts`, threaded as `segment`/`page` args. `edit_doc`, `set_style`, `get_style`, `read_doc`, `insert_image` and `insert_content` all route through it. Two whole tool families never got it. They call `contentOf(doc, tabId)` with no `segmentId`, so they only ever see the body: | Area | Call site | Tools affected | |---|---|---| | Tables | `src/docs/objects.ts` — `locateTable`, `tableOp`, `inse [Read the thread](https://github.com/dasasian/gdocs-mcp/issues/28) · 2026-08-16 · closed · 0 comments ### edit_doc: stripMarkdown disagrees with parseInline on `__` (intraword / underscore runs) ## What's wrong `edit_doc` matches `old_string` against the doc by first running it through `stripMarkdown` (`src/docs/edit.ts:27`). That function hand-rolls a *second* copy of the markdown grammar that `inline.ts`'s `PATTERNS` (`src/docs/inline.ts:54`) already encodes for the writer. The two have diverged on `__`: - `inline.ts` guards underscore-bold with CommonMark word boundaries — `/(?