Summary
get_gmail_thread_content returns per-message headers for From, Date, Subject, Message-ID, In-Reply-To, and References, but not To or Cc. There is no way to determine a message's recipients from the returned content.
include_analysis=true returns a participants array, which looks like it should cover this, but in at least one case it did not include everyone actually on the thread.
Impact
An agent reading a thread cannot reliably answer "who is on this conversation?" This matters most when drafting a reply: without recipients, you cannot construct a correct reply-all, and the omission is silent. The formatted output looks complete, so there is no signal that recipients were dropped rather than absent.
In our case an agent drafted a reply that was missing two recipients who were visibly Cc'd in the Gmail web UI. The failure was not detectable from the tool output alone.
Observed
Thread with 5 messages, body_format="text", include_analysis=true:
- Zero lines in the ~55KB response begin with
To: or Cc:. (Occurrences of To: in the body text are quoted reply chains inside message bodies, not structured headers.)
analysis.participants returned 4 addresses. At least two additional recipients were present on the thread in Gmail's UI and did not appear in that list or anywhere in the response.
The sender was on Outlook, if that is relevant to how the headers were populated.
Suggested fix
- Include
To and Cc (and ideally Bcc where visible) in the per-message header block emitted by get_gmail_thread_content and get_gmail_message_content.
- Derive
analysis.participants from the union of From/To/Cc across all messages, so it is complete by construction.
- If a header is unavailable rather than empty, emit something explicit so a caller can distinguish "no recipients" from "recipients not retrieved."
Point 3 matters most for agent use. A silently incomplete projection is worse than a documented gap, because the caller has no way to know to go looking.
Workaround
Fetch the message with body_format="raw" and parse the MIME headers directly.
Summary
get_gmail_thread_contentreturns per-message headers forFrom,Date,Subject,Message-ID,In-Reply-To, andReferences, but notToorCc. There is no way to determine a message's recipients from the returned content.include_analysis=truereturns aparticipantsarray, which looks like it should cover this, but in at least one case it did not include everyone actually on the thread.Impact
An agent reading a thread cannot reliably answer "who is on this conversation?" This matters most when drafting a reply: without recipients, you cannot construct a correct reply-all, and the omission is silent. The formatted output looks complete, so there is no signal that recipients were dropped rather than absent.
In our case an agent drafted a reply that was missing two recipients who were visibly Cc'd in the Gmail web UI. The failure was not detectable from the tool output alone.
Observed
Thread with 5 messages,
body_format="text",include_analysis=true:To:orCc:. (Occurrences ofTo:in the body text are quoted reply chains inside message bodies, not structured headers.)analysis.participantsreturned 4 addresses. At least two additional recipients were present on the thread in Gmail's UI and did not appear in that list or anywhere in the response.The sender was on Outlook, if that is relevant to how the headers were populated.
Suggested fix
ToandCc(and ideallyBccwhere visible) in the per-message header block emitted byget_gmail_thread_contentandget_gmail_message_content.analysis.participantsfrom the union ofFrom/To/Ccacross all messages, so it is complete by construction.Point 3 matters most for agent use. A silently incomplete projection is worse than a documented gap, because the caller has no way to know to go looking.
Workaround
Fetch the message with
body_format="raw"and parse the MIME headers directly.