This server cannot read the HTML part it just sent, so every HTML send is unverifiable

jlxq0 commented

2026-08-29 15:01:56 +00:00

Owner

v0.2.19 gave send_email a body_html. Nothing in this server can then tell whether the part arrived, so the sender is the one party unable to check its own output.

Measured by Lucy on a real briefing with both bodies populated, and confirmed here from the source:

get_email_headers   from, to, subject, message_id, in_reply_to, references, sent_at
                    no Content-Type, no part list
read_email          body_text only, no body_html field exists in the response
list_attachments    []

The read path is structurally incapable of seeing it. Email/get at src/mcp.rs:1283 asks for

"properties": ["from","to","cc","subject","receivedAt","keywords",
               "threadId","textBody","bodyValues","attachments"]
"fetchTextBodyValues": true

htmlBody is not among them and only text body values are fetched. ReadEmailResult has no body_html.

All three tools return the same values for a correct two-part message and for a message that only ever had text. list_attachments is empty in both cases, read_email has no field that would differ, get_email_headers carries no Content-Type. So there is no instrument here that can distinguish success from a dropped part, which is the up-answering-and-useless shape rather than a missing feature.

Julian's eyes are currently the only reading that exists, and asking him costs a glance every time.

The fix

read_email returning body_html when present, or get_email_headers carrying Content-Type. Either turns a guess into a value; the first is the more useful because it also lets an agent read HTML mail it receives.

Acceptance

A test that would have caught this: send-path output fed to the read path, asserting the HTML survives. Not a test asserting the field exists.

Found by Lucy, who measured it on her own sent copy rather than reporting that the send returned success.

`v0.2.19` gave `send_email` a `body_html`. Nothing in this server can then tell whether the part arrived, so the sender is the one party unable to check its own output. Measured by Lucy on a real briefing with both bodies populated, and confirmed here from the source: get_email_headers from, to, subject, message_id, in_reply_to, references, sent_at no Content-Type, no part list read_email body_text only, no body_html field exists in the response list_attachments [] **The read path is structurally incapable of seeing it.** `Email/get` at `src/mcp.rs:1283` asks for "properties": ["from","to","cc","subject","receivedAt","keywords", "threadId","textBody","bodyValues","attachments"] "fetchTextBodyValues": true `htmlBody` is not among them and only text body values are fetched. `ReadEmailResult` has no `body_html`. **All three tools return the same values for a correct two-part message and for a message that only ever had text.** `list_attachments` is empty in both cases, `read_email` has no field that would differ, `get_email_headers` carries no `Content-Type`. So there is no instrument here that can distinguish success from a dropped part, which is the up-answering-and-useless shape rather than a missing feature. Julian's eyes are currently the only reading that exists, and asking him costs a glance every time. ## The fix `read_email` returning `body_html` when present, or `get_email_headers` carrying `Content-Type`. Either turns a guess into a value; the first is the more useful because it also lets an agent read HTML mail it receives. ## Acceptance A test that would have caught this: send-path output fed to the read path, asserting the HTML survives. Not a test asserting the field exists. Found by Lucy, who measured it on her own sent copy rather than reporting that the send returned success.

jlxq0 commented

2026-08-31 03:30:23 +00:00

Author

Owner

Next up. Triaged 2026-08-31: this is one of three I would take before anything else in my repositories.

It cost real time on 2026-08-29 and 30, in three separate confusions that all looked like different faults.

Lucy sent Julian a styled newsletter on 2026-08-29 and nobody here could confirm the HTML part survived, because read_email, get_email_headers and list_attachments return identical values for a correct two-part message and for one that only ever had text. His eyes were the only instrument.

That is now live rather than theoretical: he is asking for briefings in a proper design, and every one of them is unverifiable from this side.

**Next up. Triaged 2026-08-31: this is one of three I would take before anything else in my repositories.** It cost real time on 2026-08-29 and 30, in three separate confusions that all looked like different faults. **Lucy sent Julian a styled newsletter on 2026-08-29 and nobody here could confirm the HTML part survived**, because `read_email`, `get_email_headers` and `list_attachments` return identical values for a correct two-part message and for one that only ever had text. **His eyes were the only instrument.** That is now live rather than theoretical: he is asking for briefings in a proper design, and every one of them is unverifiable from this side.

jlxq0 commented

2026-08-31 03:32:17 +00:00

Author

Owner

Correcting the note above: this issue is directly implicated in a rejection, and I said it was not.

On 2026-08-29 Julian rejected two of Lucy's briefing emails:

Both Lucy emails look disgusting. And corrections? Get the old template! We had a beautifully formatted and structured email. html and all.

Two HTML briefings went out, he found both unacceptable, and nobody on this side could read what had actually been sent. The correction round that followed was run blind, which is what this issue is about.

I had confused that with a separate pair of rejections, the Brevo campaign and the paste sheet, which are a different system and which this issue does not touch.

So there are two reasons and they are stronger together: it is implicated in a rejection that already happened, and it recurs on every styled briefing while being invisible from this side. read_email, get_email_headers and list_attachments return identical values for a correct two-part message and for one that only ever had text.

First of the three, on that ordering.

**Correcting the note above: this issue is directly implicated in a rejection, and I said it was not.** On 2026-08-29 Julian rejected two of Lucy's briefing emails: > Both Lucy emails look disgusting. And corrections? Get the old template! We had a beautifully formatted and structured email. html and all. **Two HTML briefings went out, he found both unacceptable, and nobody on this side could read what had actually been sent.** The correction round that followed was run blind, which is what this issue is about. **I had confused that with a separate pair of rejections**, the Brevo campaign and the paste sheet, which are a different system and which this issue does not touch. **So there are two reasons and they are stronger together**: it is implicated in a rejection that already happened, and it recurs on every styled briefing while being invisible from this side. `read_email`, `get_email_headers` and `list_attachments` return identical values for a correct two-part message and for one that only ever had text. **First of the three, on that ordering.**

jlxq0 referenced this issue from a commit

2026-09-01 16:41:44 +00:00

feat(read): return the HTML body from read_email

jlxq0 referenced this issue from a pull request that will close it,

2026-09-01 16:42:05 +00:00

feat(read): return the HTML body from read_email #35

jlxq0 referenced this issue from a commit

2026-09-01 16:53:08 +00:00

fix(read): escape the HTML body, and separate wrapping from escaping

jlxq0 closed this issue

2026-09-01 16:56:29 +00:00

jlxq0 referenced this issue