Problem
There is currently no way to send a real WhatsApp @-mention through the bridge or the send_message MCP tool. Writing @<number> in the message text sends it as plain text: it doesn't render as a highlighted/tappable mention on recipients' devices and — more importantly — doesn't trigger a mention notification for the tagged user. WhatsApp only renders a mention when the message carries the mentioned users' JIDs in ContextInfo.MentionedJID, which nothing in the current send path can set.
Use case
An agent posts status updates into a team group chat (build finished, PR merged, question for a specific person). To be useful it needs to tag the relevant person so they actually get notified — e.g. "Hi @420…, your PR is merged". Today the agent can only send untargeted group messages that are easy to miss.
Which scope bucket does this fit?
MCP correctness — exposing a core message feature that whatsmeow already fully supports, additive and opt-in (same shape as the existing quoted-reply fields on /api/send).
Proposed approach
- Bridge: optional
mentions field ([]string of phone numbers or JIDs) on /api/send. Text messages with mentions go out as ExtendedTextMessage with ContextInfo.MentionedJID (composes with the existing quoted-reply ContextInfo); image/video/document captions set MentionedJID on their own ContextInfo.
- Phone-number entries resolve to both the phone JID and (when the LID cache knows it) the LID form, mirroring what
resolveRecipientJID already does — so mentions render correctly in LID-addressed groups as well as legacy ones.
- MCP:
send_message gains mentions: list[str] | None, forwarded in the payload; the docstring documents that the text must contain a matching @<number> token per entry (that token is what clients replace with the contact name).
I have this implemented with tests and can open a PR right away.
Alternatives considered
- Putting
@<number> in plain text — renders as literal text, no notification (the problem itself).
- Downstream fork carrying the patch — works but fragments the ecosystem; the feature seems generally useful and is small (~190 LOC incl. tests).
Problem
There is currently no way to send a real WhatsApp @-mention through the bridge or the
send_messageMCP tool. Writing@<number>in the message text sends it as plain text: it doesn't render as a highlighted/tappable mention on recipients' devices and — more importantly — doesn't trigger a mention notification for the tagged user. WhatsApp only renders a mention when the message carries the mentioned users' JIDs inContextInfo.MentionedJID, which nothing in the current send path can set.Use case
An agent posts status updates into a team group chat (build finished, PR merged, question for a specific person). To be useful it needs to tag the relevant person so they actually get notified — e.g. "Hi @420…, your PR is merged". Today the agent can only send untargeted group messages that are easy to miss.
Which scope bucket does this fit?
MCP correctness — exposing a core message feature that whatsmeow already fully supports, additive and opt-in (same shape as the existing quoted-reply fields on
/api/send).Proposed approach
mentionsfield ([]stringof phone numbers or JIDs) on/api/send. Text messages with mentions go out asExtendedTextMessagewithContextInfo.MentionedJID(composes with the existing quoted-reply ContextInfo); image/video/document captions setMentionedJIDon their own ContextInfo.resolveRecipientJIDalready does — so mentions render correctly in LID-addressed groups as well as legacy ones.send_messagegainsmentions: list[str] | None, forwarded in the payload; the docstring documents that the text must contain a matching@<number>token per entry (that token is what clients replace with the contact name).I have this implemented with tests and can open a PR right away.
Alternatives considered
@<number>in plain text — renders as literal text, no notification (the problem itself).