get_thread
Fetch an email thread by ID with headers, bodies, attachment metadata and SPF/DKIM/DMARC authentication; trim HTML, quoted replies or message count to keep long threads manageable.
Instructions
Fetch a thread by ID: headers, plaintext + HTML bodies, and attachment metadata. WHEN A THREAD IS LONG OR HTML-HEAVY, shrink the answer instead of skipping content: bodies: "text" drops htmlBody and keeps plaintextBody (an HTML-only mail is reduced to text and marked bodyFromHtml: true); bodies: "new" is text without the quoted history at the end of a reply (the trailing > block with its 'On ... wrote:' line, or an Outlook 'Original Message' block) and marks a cut message quotedStripped: true — inline answers between quoted lines, answers below a quote and forwarded messages (recognised by a forwarded-message line or a Fwd/FW/WG subject) are kept whole, except an answer below an Outlook plain-text From/Sent/Subject block, which goes with it; bodies: "none" drops both bodies and keeps everything else, INCLUDING the real attachment list; lastN: 2 returns only the newest two messages, afterMessageId only the messages after one you have already read (both compose: after X, then the last N). The quota cost is the same whatever you keep — Gmail hands over the whole thread, these options only decide how much of it you read. messageCount is always the whole thread and omittedMessages how many the selection left out, so a partial view never passes for the whole; bodies is echoed when it is not full. full defaults to true and should stay true whenever content matters. full: false is a headers-and-labels fetch that does NOT fetch bodies or attachment metadata — the result then omits plaintextBody, htmlBody and attachments entirely and sets metadataOnly: true. full: false together with any bodies is rejected as invalid_input rather than silently ignored. full: false is kept for compatibility but DEPRECATED: use bodies: "none" instead, which costs the same quota and keeps the real attachment list. The fields are omitted rather than empty on purpose: an empty attachment list from a request that never looked is indistinguishable from a message that truly has none, and treating it as 'no attachment' has already nearly caused an invoice to be archived as attachment-less. If search reported hasAttachments: true, or the sender matters, use full: true (any bodies). EVERY MESSAGE CARRIES authentication — SPF/DKIM/DMARC as the RECEIVING server reported them, for answering 'is this mail really from who it says?'. That holds on a full: false fetch too — the metadata request asks for Authentication-Results by name, so checking whether a mail is really from who it says never costs a body. Read dmarc first: it is the only one of the three that ties a passing check to the visible From domain, so spf: pass alone proves nothing about the sender the user sees (a lookalike domain gets that trivially). signedBy/mailedBy/headerFrom name the domains each check actually validated. They do NOT have to match each other or the From address, and a mismatch is not by itself suspicious: a forwarded message legitimately shows the forwarder in mailedBy and returnPath (the envelope sender is rewritten in transit), while headerFrom still names the original sender — which is exactly why dmarc is the result that carries meaning. Read those three as the explanation of a result, not as a test of their own. A message often carries several DKIM signatures (a forwarder or the sender's mail provider re-signs in transit): signedBy is the passing one aligned with the From domain wherever there is one — the one DMARC can pass on — and alsoSignedBy names the other domains whose signature also passed, which is where a forwarder shows. dkimAligned says whether that reported signature belongs to the From domain or a parent or child of it, so false means NO passing signature did; it is absent when that cannot be told without a public-suffix list (two sibling subdomains), so a missing field is not a mismatch. authservId says WHO asserts all this: a message can carry forged Authentication-Results headers of its own, and only Gmail's own report (mx.google.com) is ever read; otherReports counts the reports that were NOT read, and alsoReported lists results that disagree with the ones above. unchecked: true means the message carried no report from Gmail — that is 'nobody looked', NOT 'nothing wrong'; unauthenticated does not imply forged, and authenticated does not imply honest (a phisher can hold a passing DMARC on his own lookalike domain). USE WHEN: reading a thread's content after finding it via search. DO NOT USE: with a message ID — this takes thread IDs. SIDE EFFECTS: none (does not mark as read).
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"threadId": "<threadId>"
},
"name": "get_thread"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| lastN | No | ||
| bodies | No | ||
| threadId | Yes | ||
| afterMessageId | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| bodies | No | ||
| messages | Yes | ||
| threadId | Yes | ||
| messageCount | Yes | ||
| metadataOnly | No | ||
| omittedMessages | Yes |