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.

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 · 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 · 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 · 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

Read the thread · 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 · 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 · 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 · 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 · 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 · 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, `<span style="color:…;font-size:…pt;font-family:…">` 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 }

Read the thread · 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:

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:

{ "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 · 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:

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'.

Read the thread · 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 · 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 · 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 (<p style="text-align: justify">, <span style="color:#1a73e8">, <img width="400">)

…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 · 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:

Read the thread · 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 — /(?<!\w)__([^_]+)__(?!\w)/ — added so intraword emphasis and signature blank lines (____ ____ from so

Read the thread · 2026-08-16 · closed · 0 comments

The remaining reports are on the project's issue tracker.