Feature request: expose filename on message tools
list_messages / get_message_context return media_type for document
attachments, but not the original filename. The bridge does store it
(messages.filename in messages.db, populated from Message.filename /
msg_to_dict in whatsapp.py), it's just not included in the dict returned
to MCP clients — msg_to_dict
only re-exposes filename when media_type == "reaction" (as
reaction_to_message_id).
Use case: filtering/identifying documents by type (e.g. "find PDFs sent
to this group") currently requires knowing the media is a generic
"document" and then reading messages.db directly to get the actual
filename/extension — which works, but means going around the MCP interface
entirely for something the data already has.
Suggestion: add filename to the msg_to_dict output for non-reaction
media types (it's already there in the Message dataclass, so this looks
like a small change), or alternatively expose it via a small addition to
download_media's response.
Happy to open a PR if a maintainer confirms this is a change you'd want —
wasn't sure if filename was deliberately withheld for privacy/size reasons
in the current design.
Feature request: expose
filenameon message toolslist_messages/get_message_contextreturnmedia_typefor documentattachments, but not the original
filename. The bridge does store it(
messages.filenameinmessages.db, populated fromMessage.filename/msg_to_dictinwhatsapp.py), it's just not included in the dict returnedto MCP clients —
msg_to_dictonly re-exposes
filenamewhenmedia_type == "reaction"(asreaction_to_message_id).Use case: filtering/identifying documents by type (e.g. "find PDFs sent
to this group") currently requires knowing the media is a generic
"document"and then readingmessages.dbdirectly to get the actualfilename/extension — which works, but means going around the MCP interface
entirely for something the data already has.
Suggestion: add
filenameto themsg_to_dictoutput for non-reactionmedia types (it's already there in the
Messagedataclass, so this lookslike a small change), or alternatively expose it via a small addition to
download_media's response.Happy to open a PR if a maintainer confirms this is a change you'd want —
wasn't sure if
filenamewas deliberately withheld for privacy/size reasonsin the current design.