check_inbox is the list. get_package is one briefing, in full, as markdown your assistant can work with.
That call is also a fact about the other person.
What it records
A PulledViaMcp event: this account's assistant fetched this package. thread_status answers "have they seen it" from that event — or from a reply, or from an acknowledge. Those three are consequential. A link scanner is not.
What the sender sees includes that pull. It never includes a fetched email link or a portal view.
The trail does not name which assistant did the pulling. Which app they read their mail with is a fact about them.
Why the portal does not reuse it
Two reasons, and either would be enough.
The MCP result is markdown. Rendering that as HTML on a page would put someone else's words through a second sink. The package page already has one, and every field there is encoded.
And a human opening a page is not an assistant fetch. Labelling it the same way would put a false line in the provenance record — the thing thread_status and the sender's trail both read.
So the portal has its own read. It records a view under a different name, and that name is omitted from everything the sender is shown. Acknowledging stays the deliberate act.
What comes back
The briefing, neutralized — images and live links already defused. Newlines in the note are the point; this is prose, not a labelled listing. check_inbox is the surface that must not let a sender invent a From: line.
A hand-off you sent yourself stays unread in the inbox until any assistant on the account pulls it, including the one that sent it. That is the honest state: handed off, not yet picked up.
What to tell the sender
If they ask whether it was read, the honest answers are: their assistant has it, someone pressed acknowledged, or someone replied. "The link was fetched" is not one of them. get_package is the first of those, and only that.