telegram-notify MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TELEGRAM_CHAT_ID | Yes | Numeric Telegram chat id of the fixed recipient. Required unless configured via the setup command/config file. | |
| TELEGRAM_BOT_TOKEN | Yes | Telegram bot token from @BotFather. Required unless configured via the setup command/config file. | |
| TELEGRAM_NOTIFY_HOME | No | Optional path to relocate the telegram-notify configuration folder. | |
| TELEGRAM_NOTIFY_FILES_DIR | No | Optional folder that notify_file may read from. If unset, file sending is disabled. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Sends Telegram notifications to the owner of this server — one fixed chat, set in its configuration.
notify: a short message when something finishes, fails, or needs the user's attention. Plain text by default; format="markdown" for bold, italic,
code, links. silent=true delivers without a sound.Write plain words: no emoji or icons in the text or captions.
notify_file: sends a file, only from the folder the owner allowed.
This is one-way: replies in Telegram never come back here. Do not ask the user a question through it and wait for an answer.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notifyA | Sends a message to the owner's Telegram (a fixed chat; you cannot choose the recipient). Messages over 4096 characters are split. Do not use emoji or icons. |
| notify_fileA | File sending is turned off on this server (TELEGRAM_NOTIFY_FILES_DIR is not set); every call is refused. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
notify and notify_file have clearly different nominal purposes (text vs file), but notify_file is permanently disabled, so an agent has a real chance of wasting a call on a dead branch before reading the caveat. With only one functional operation, the distinction is trivial rather than a genuine choice.
Both names are lowercase snake_case and share the 'notify' stem, which is predictable. Minor deviation: 'notify' is a bare verb while 'notify_file' adds a noun, so the pattern is more a prefix family than a strict verb_noun scheme.
Effectively one usable tool, since notify_file is refused on every call. For a single-purpose one-way notifier that is defensible, but advertising a non-functional second tool makes the surface feel padded and thin at the same time.
The core send-a-message operation exists, but file sending is exposed yet permanently off, and there is no recipient selection, no read/status, and no message formatting options. The surface has a built-in dead end rather than a coverage gap an agent can work around.