[FEATURE] Gmail connector: opt-in access to the Spam folder (e.g. includeSpam), matching the existing includeTrash

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

First, genuine thanks for the Gmail connector — the rich search operators, thread tools, and reversible label operations make real email-triage workflows with Claude genuinely workable. It's become part of a recurring routine for me.

What's missing: there is no way to read the Spam folder.

• search_threads with in:spam returns {} (no error, no signal)
• label:SPAM returns {}
• in:anywhere omits spam-classified threads
• The tool exposes an includeTrash parameter, but no spam equivalent

Repro (2026-07-12, consumer gmail.com account, Cowork desktop macOS): Gmail UI showed 33 threads in Spam; every query above returned empty. Trash, by contrast, is fully queryable with includeTrash: true.

Proposed Solution

An opt-in includeSpam parameter on search_threads (or honoring in:spam / label:SPAM), mirroring the existing includeTrash. Once threads are visible, the connector's own label tools (unlabel_thread SPAM + label_thread INBOX) already handle false-positive rescue perfectly.

Alternative Solutions

Browser automation (navigating the logged-in Gmail web UI and scraping the Spam list) — works but is fragile and much slower than the connector, and it can't use the connector's clean thread IDs/label operations.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Periodic spam triage: every few days, review Spam for false positives before Gmail's 30-day auto-delete destroys them. In the run that surfaced this, a real 1:1 email from a newsletter reader was sitting in Spam and would have auto-deleted unseen.

Additional Context

Related: #68959 documents what looks like the same underlying spam-classification exclusion hiding even Inbox messages in a Workspace-override case; this issue asks for the explicit opt-in.