Recipients resolve the same way they do in the app. A username is looked up live through the connected account, including someone who has never messaged your workspace, and a phone number is resolved when there is no username to work from. The send spreads across the accounts you have connected, each behind its own proxy, with Telegram-aware pacing. An assistant cannot reach anything the connected account cannot reach.
Three Telegram marketing examples people actually ask for:
Go through my Telegram chats, find the ones where we are writing in Chinese, translate this month's product update into Chinese, and broadcast it only to those.
The assistant reads recent messages in each chat through the connected account, keeps the Chinese-speaking ones, localizes the text, and sends to that set alone. Every other language gets its own pass with its own translation instead of one English message for everyone.
entergram_list_accounts → entergram_list_chats → entergram_list_messages → entergram_broadcast_message
Find every chat where Outreach Stage is Declined or No reply, send them the September win-back offer, then set their stage to Re-contacted.
Custom columns are defined by your workspace rather than shipped by Entergram, so the assistant reads the column schema first to learn which columns and option values exist before it filters. A stage column holding a Declined or Lost value is the segment. Writing the stage back once the job finishes is the same kind of call in reverse.
entergram_list_custom_columns → entergram_list_custom_column_options → entergram_list_workspace_chats → entergram_broadcast_message → entergram_patch_chat_custom_fields
Pull the beta invite list and the announcement copy from the Notion page, then send it to those usernames from my Telegram accounts.
Entergram's MCP sits alongside whatever else the assistant is connected to. The segment and the copy can come from Notion, a spreadsheet or a ticket queue, while the Telegram send, the pacing and the reply routing stay on Entergram's side.
Notion MCP → entergram_list_accounts → entergram_broadcast_message
Two limits are worth knowing before you build on this. The broadcast call takes a bounded list of unique usernames, so a long list runs as a series of jobs rather than one blast, and every message call needs an account id from entergram_list_accounts, which keeps the sending account named explicitly instead of guessed. Replies to an MCP-triggered send arrive in the same inbox as replies to a send from the composer.