Gmail connector: send_message/reply cannot apply the account's Gmail signature, and there is no way to read it
What happens
The Gmail MCP connector's send_message, reply and create_draft send exactly the body they are given. The signature configured on the Gmail account (Settings > General > Signature) is never appended, and no tool exposes it for reading.
list_send_as returns send-as aliases but not the signature HTML.
Why it matters
For anyone whose email carries professional identity — a publicist writing on a client's behalf, a lawyer, anyone whose signature is how the recipient knows who they are and what authority they have — an email sent through this connector arrives unsigned and looks like it came from nobody. That is not a cosmetic difference; it changes whether the recipient acts on the message.
The only workaround today is to fetch a previously sent message with get_message at FULL_CONTENT, extract the div.gmail_signature block by hand, and paste it into htmlBody on every send. That is fragile, silently goes stale when the user edits their signature, and requires an unrelated read of the mailbox before every write.
Asks, in order of usefulness
- A
signature: true(orsendAsEmail) option onsend_message,replyandcreate_draftthat applies the account's configured signature, the way the Gmail web composer does. - Failing that, expose the signature HTML for read — either as a field on
list_send_asor a dedicated tool — so a caller can attach it deliberately.
Gmail's own API exposes this: users.settings.sendAs.list returns a signature field per send-as address. The data is already one call away.
Related paper cut
When only body (plain text) is supplied, the message goes out with no HTML alternative, so any structure the caller wanted is lost. When both body and htmlBody are supplied they are treated as alternatives, which is correct, but there is no validation that the two actually correspond — a malformed call can ship a plain-text part that does not match the HTML part, and nothing warns.