# Reported issues for gmail-mcp Pod holds 10 of 10 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 [gmail-mcp](/mcp/gmail-mcp). ## Most discussed ### Notes from a production deployment First, thank you for this project. We needed exactly one thing that Anthropic's built-in Gmail connector doesn't do — return the *contents* of an attachment — and `gmail-mcp` was the only self-hostable option we found that treats the Google credential as something the operator keeps. The commit history was a large part of why we chose it: `spend a one-time state when it is read, not after it is checked` and `drop a client-supplied grant header at the boundary` are not the commits of someone who [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/11) · 2026-08-29 · open · external user · 0 comments ### Decide when to adopt the 2026-07-28 MCP specification The 2026-07-28 revision makes the protocol stateless: the `initialize` handshake and the `Mcp-Session-Id` header are retired, each request carries its own identity and capabilities in `_meta`, method and tool names move into `Mcp-Method` and `Mcp-Name` headers, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. The session model is load-bearing here. The Durable Object is addressed as `streamable-http:${sessionId}`, and the owner claim in its storage, `isOw [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/9) · 2026-07-29 · open · 0 comments ### list_drafts sends metadataHeaders to an endpoint that has no such parameter `list_drafts` requests `format=metadata` with `metadataHeaders=To&metadataHeaders=Cc&…`. The `users.drafts.get` method accepts only `format`, `id` and `userId`; Google's frontend ignores unknown query parameters rather than rejecting them, so the call returns every header instead of the four intended. Nothing fails. Draft header blocks are small, so the cost is a little wasted payload per draft. Removing the parameters is near-zero risk and buys correspondingly little. [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/8) · 2026-07-29 · open · 0 comments ### inlinePart has no Content-ID length guard `filePart` measures its assembled header lines and refuses a filename that cannot fit. `inlinePart` validates the shape of a Content-ID but not its length, so a cid above roughly 985 characters produces a header line past 998 octets. The value is caller-supplied and nothing plausible writes one that long. Gmail refuses the send either way, so the outcome is an error with a less useful message. [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/7) · 2026-07-29 · open · 0 comments ### create_draft refuses a subject carrying a line break `assertHeaderSafe` rejects any header value containing CR or LF, and a test pins that `subject: "s\nX-Evil: 1"` throws. That is deliberate: refusing an injection attempt in a caller-supplied subject is the safe answer. It also blocks an ordinary flow. Gmail returns some notification subjects with a trailing newline — Search Console and Google Store both do — so a model that reads a subject with `get_message` and passes it to `create_draft`, `send_message` or `update_draft` gets a hard error nam [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/6) · 2026-07-29 · open · 0 comments ### reply_all sends threadId without In-Reply-To when a message has no usable Message-ID `reply_all` drops the threading headers when the original's `Message-ID` fails `normalizeMessageId`, and still sends `threadId` on the request. Google documents that adding a message to a thread requires the thread id, `References` and `In-Reply-To` set per RFC 2822, and a matching subject. This request meets the first and not the second. What Gmail actually does with it is unverified: it may accept the message, deliver it as a separate conversation, or refuse the request. Each outcome implies [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/5) · 2026-07-29 · open · 0 comments ### A claimed session cold-woken by another account answers 500, not 403 When a session object is cold and a request arrives carrying a different account's grant, `init()` refuses through `ownerProps()` and the exception propagates out of `getAgentByName`. The caller receives a 500, and the `isOwnedBy` branch a line below — written to answer 403 for exactly this case — is never reached. Access is denied either way, the object recovers for its owner on the next request, and reaching the path at all requires the victim's session id. The warm-object case does return t [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/4) · 2026-07-29 · open · 0 comments ### get_thread's oversize fallback counts a failed fetch as omitted In the fallback, `kept` filters out any message whose individual fetch failed, and `omitted = all.length - kept.length` absorbs the loss. The reply reports a count with fewer messages in it and no indication which are missing or why. The rest of the server does the opposite: `search_messages` and `list_drafts` pass `{error}` items through in place, and the second map in `get_thread` itself lets them through on the normal path. The failure is incompleteness, never wrong content, and it only occ [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/3) · 2026-07-29 · open · 0 comments ## Most recent ### get_thread's oversize fallback retains maxMessages × 6 MB The normal `get_thread` path bounds a whole thread to one 6 MB response. When that response is refused, the fallback lists message ids and fetches a window individually, each capped at 6 MB, and holds every parsed message before the character budget trims anything at `src/index.ts:485`. Measured through the handler: a fallback over 24 messages, each carrying a 1,000,000-character encoded body, fetched and retained all 24 and grew process RSS by 286,212,096 bytes. Cloudflare allows [128 MB per i [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/2) · 2026-07-29 · open · 0 comments ### fitsHeaderLine measures characters against a limit that means octets `MAX_HEADER_RUN` (900) exists to keep a header line inside RFC 5322's 998-**octet** cap, but `fitsHeaderLine` in `src/gmail.ts` compares `run.length`, which counts UTF-16 code units. A run outside ASCII therefore passes a check it should fail. Two entry points reach it: - A bare address of roughly 330+ CJK characters. - `In-Reply-To` / `References`: a 606-character multibyte message id survives `normalizeMessageId` and produces a 1,205-octet line. The outcome is a refusal from Gmail rather th [Read the thread](https://github.com/mkpoli/gmail-mcp/issues/1) · 2026-07-29 · open · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/mkpoli/gmail-mcp/issues).