Get email content
get_email_contentReads up to 10 emails from local copy, returning headers, plain-text body, attachment info, optional sanitized HTML and download links. Accepts email IDs or a thread ID.
Instructions
Reads up to 10 emails already synchronized into MailFathom's local mailbox copy, in one call: for each one its normalized headers, the plain-text body, optionally a sanitized HTML body, and every attachment it carries described by file name, media type, and size. Name what to read in exactly one of two ways — storedEmailIds for particular emails, or threadId for a whole conversation, which returns its messages in the conversation's own order and names any it could not carry in unreadThreadMessages. A call naming both, or neither, is refused. Every email returned also carries the conversation it belongs to, with the other messages in it named rather than reproduced. Reads the local copy only: it never contacts a mail server, never downloads mail, and never marks mail as read. Each email is answered for separately, so one this deployment cannot serve does not discard the others. Bodies are bounded per email and by a budget shared across the whole call, and a scanned deployment bounds what it analyzes as well; each body says which of those bounds cut it in truncatedBy, and only readCharacterBudget is the one that returns more when fewer emails are named at once. No response ever carries an attachment's bytes: set includeAttachmentDownloadLinks to receive, for each file, a short-lived URL in downloadUrl that fetches it over HTTP with no credential attached, and downloadState says why one was not issued when it was not. Where the deployment scans mail for sensitive content, what a message's author wrote is scanned on every call and returned with each detection replaced by a [redacted:category] marker: the marker means material of that kind stood there and was withheld, it is never message text, and asking again returns the same marker. Nothing stored is rewritten by it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | No | The threadId a listing, a search, or an earlier read returned, to read that whole conversation instead of naming its messages. Its messages come back in the conversation's own order, bounded to 10 per call, and unreadThreadMessages names the rest so a second call asks for them directly. Omit it entirely when naming storedEmailIds instead. | |
| storedEmailIds | No | The storedEmailIds a listing or a search returned, at most 10, each named at most once. Each is a UUID and does not change when the mail server renumbers or moves the message. Results come back in the order given, and the call is refused rather than truncated when it names more than 10. Omit it entirely when naming threadId instead. | |
| includeSanitizedHtml | No | Whether to also return the sanitized HTML body of each email. Omit it unless the markup itself matters: the plain text is the representation to read from, HTML costs a sanitization pass, and it draws on the same character budget as the plain text. An email carrying no HTML part returns none either way. | |
| includeAttachmentDownloadLinks | No | Whether to mint a link for fetching each attachment, rather than only describing it. Omitted still returns every attachment's file name, media type, and size, which is what an ordinary read needs to decide whether a file is worth fetching. Each link is a bearer capability: it names one file, it expires within minutes, and anyone holding the URL can fetch that file without a credential — so ask for links only when the files are what you are after, and do not store or log what comes back. The response size is the same either way. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | One entry per email the call named, in the same order. An email named once appears once: the call is refused rather than served twice when an identifier is repeated. A call that named a thread is answered with that thread's messages in the thread's own order instead. | |
| unreadThreadMessages | Yes | For a call that named a thread longer than one read serves: the storedEmailIds of that thread's remaining messages, in the thread's own order. Ask for them directly in a second call. Empty for every call that named its emails itself. |