Summary
Add the capability to retrieve a full Gmail thread, including all its messages, via both the gwsa CLI and the MCP server.
This addresses the need to view the entire context of a conversation, which is not possible with the current gwsa mail read command that only fetches a single message.
Context: Distinguishing Message vs. Thread IDs
It is critical that the implemented solution clearly addresses the distinction between Gmail message_id and thread_id at a glance, both in output and API design. MCP clients (like the Gemini CLI) need to reliably identify which type of ID they are being given when asked about an email. If necessary, build error messaging into the MCP tools or make them versatile enough to handle either type of ID gracefully.
Acceptance Criteria
-
SDK Layer (gwsa/sdk/mail/read.py):
- A new function
get_thread(thread_id: str) should be created.
- This function must call the
service.users().threads().get() method of the Gmail API.
- The function should process the raw API response to return a simplified list of messages within the thread, including essential headers like
id, subject, from, to, date, and snippet for each message.
- The
from key in the message dictionary must be correctly handled as it's a Python reserved keyword (e.g., by quoting it: {"from": ...}).
-
CLI Layer (gwsa command):
- A new CLI command
gwsa mail threads get <thread_id> should be created.
- This command should be implemented in a new file:
gwsa/cli/mail/threads.py.
- It must call the
gwsa.sdk.mail.read.get_thread() function.
- The output should be the full thread object, formatted as a pretty-printed JSON string.
- The new
threads subcommand must be correctly wired into the main mail command group in gwsa/cli/__main__.py.
-
MCP Tool Layer (gwsa-mcp):
- A new MCP tool named
get_email_thread(thread_id: str) should be added to gwsa/mcp/server.py.
- The tool should have a clear docstring explaining its purpose and arguments.
- It must call the
gwsa.sdk.mail.read.get_thread() function and return the resulting dictionary.
Implementation Notes
- Logic should be centralized in the SDK layer.
- Follow existing patterns for SDK functions, CLI commands (
click), and MCP tool definitions.
- Ensure appropriate error handling is in place for all layers.
Gmail API Reference
Summary
Add the capability to retrieve a full Gmail thread, including all its messages, via both the
gwsaCLI and the MCP server.This addresses the need to view the entire context of a conversation, which is not possible with the current
gwsa mail readcommand that only fetches a single message.Context: Distinguishing Message vs. Thread IDs
It is critical that the implemented solution clearly addresses the distinction between Gmail
message_idandthread_idat a glance, both in output and API design. MCP clients (like the Gemini CLI) need to reliably identify which type of ID they are being given when asked about an email. If necessary, build error messaging into the MCP tools or make them versatile enough to handle either type of ID gracefully.Acceptance Criteria
SDK Layer (
gwsa/sdk/mail/read.py):get_thread(thread_id: str)should be created.service.users().threads().get()method of the Gmail API.id,subject,from,to,date, andsnippetfor each message.fromkey in the message dictionary must be correctly handled as it's a Python reserved keyword (e.g., by quoting it:{"from": ...}).CLI Layer (
gwsacommand):gwsa mail threads get <thread_id>should be created.gwsa/cli/mail/threads.py.gwsa.sdk.mail.read.get_thread()function.threadssubcommand must be correctly wired into the mainmailcommand group ingwsa/cli/__main__.py.MCP Tool Layer (
gwsa-mcp):get_email_thread(thread_id: str)should be added togwsa/mcp/server.py.gwsa.sdk.mail.read.get_thread()function and return the resulting dictionary.Implementation Notes
click), and MCP tool definitions.Gmail API Reference