Telegram Notifier MCP Server
Provides tools for sending messages, photos, documents, and videos to Telegram chats via a bot.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Telegram Notifier MCP ServerSend a notification to the admin group: 'Server backup completed successfully.'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Telegram Notifier MCP Server
A Model Context Protocol (MCP) server that enables AI agents to send messages via Telegram bot. Perfect for notifications, alerts, and real-time communication from your AI applications.
Features
📱 Send messages to Telegram channels/chats via bot
🎨 Support for multiple formatting modes (Markdown, MarkdownV2, HTML)
📷 Send photos/images (local files, HTTP URLs)
📁 Send documents/files with custom filenames
🎬 Send videos with caption support
🏷️ Caption support for all media with full formatting
🛡️ Robust error handling with detailed Telegram API responses
🏗️ Clean service architecture for maintainable code
Related MCP server: Telegram MCP Server
Quick Start
1. Create a Telegram Bot
Message @BotFather on Telegram
Use
/newbotcommand and follow instructionsSave the bot token (looks like
123456789:ABCdefGHIjklMNOpqrsTUVwxyz)
2. Get Chat ID
For personal messages:
Message your bot first
Visit:
https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdatesFind the
chat.idvalue
For channels:
Add your bot to the channel as admin
Send a message to the channel
Visit the same URL and find the
chat.id(negative number for channels)
3. Install and Configure
# Install the package
npm install -g @harnyk/telegram-notifier-mcp
# Or clone and build locally
git clone <repository-url>
cd mcp-telegram-notifier
pnpm install
pnpm build
pnpm link4. Add to Your MCP Client
Add to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"telegram-notifier": {
"command": "telegram-notifier",
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token_here",
"TELEGRAM_CHAT_ID": "your_chat_id_here"
}
}
}
}Or using npx:
{
"mcpServers": {
"telegram-notifier": {
"command": "npx",
"args": ["-y", "@harnyk/telegram-notifier-mcp"],
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token_here",
"TELEGRAM_CHAT_ID": "your_chat_id_here"
}
}
}
}Available Tools
Once configured, your AI agent will have access to these MCP tools:
📝 send_markdown_message_as_telegram_bot
Send formatted text messages to Telegram
messageText: Text content with Markdown/HTML formatting
parseMode:
Markdown,MarkdownV2, orHTML(default: MarkdownV2)
📷 send_telegram_photo
Send photos/images to Telegram
photo: Local file path or HTTP URL to image
caption: Optional image caption with formatting
parseMode: Caption formatting mode
📁 send_telegram_document
Send documents/files to Telegram
document: Local file path or HTTP URL to document
caption: Optional document caption with formatting
filename: Custom filename override
parseMode: Caption formatting mode
🎬 send_telegram_video
Send videos to Telegram
video: Local file path or HTTP URL to video
caption: Optional video caption with formatting
filename: Custom filename override
parseMode: Caption formatting mode
Use Cases
📊 Monitoring: Get alerts when system metrics exceed thresholds
🚀 Deployments: Notifications when CI/CD pipelines complete
📈 Analytics: Daily/weekly reports with charts and data files
🔍 Error Tracking: Instant notifications with error screenshots
📅 Scheduling: Reminders with attached documents
💬 Customer Support: Forward important messages with media
Development
# Install dependencies
pnpm install
# Run in development mode
pnpm dev
# Build for production
pnpm build
# Run linting
pnpm lint
# Run type checking
pnpm typecheckConfiguration Examples
Claude Desktop
{
"mcpServers": {
"telegram-notifier": {
"command": "telegram-notifier",
"env": {
"TELEGRAM_BOT_TOKEN": "123456789:ABCdefGHIjklMNOpqrsTUVwxyz",
"TELEGRAM_CHAT_ID": "-1001234567890"
}
}
}
}Contributing
Fork the repository
Create a feature branch
Make your changes
Add tests if needed
Run
pnpm lintandpnpm typecheckSubmit a pull request
License
WTFPL - Do What the Fuck You Want to Public License
Available Tools
4 toolssend_markdown_message_as_telegram_botSend Telegram Message in Markdown formatB
Send a message using Telegram bot in Markdown format
| Name | Required | Description | Default |
|---|---|---|---|
| messageText | Yes | Message text with formatting. Examples: HTML: <b>bold</b>, <i>italic</i>, <u>underline</u>, <s>strike</s>, <code>code</code> Markdown: *bold*, _italic_, `code`, [link](url) MarkdownV2: *bold*, _italic_, __underline__, ~strike~, ||spoiler||, `code` Prefer MarkdownV2. Read the documentation on MarkdownV2 formatting below: MarkdownV2 style To use this mode, pass MarkdownV2 in the parse_mode field. Use the following syntax in your message: *bold \*text* _italic \*text_ __underline__ ~strikethrough~ ||spoiler|| *bold _italic bold ~italic bold strikethrough ||italic bold strikethrough spoiler||~ __underline italic bold___ bold* [inline URL](http://www.example.com/) [inline mention of a user](tg://user?id=123456789) `inline fixed-width code` ``` pre-formatted fixed-width code block ``` ```python pre-formatted fixed-width code block written in the Python programming language ``` >Block quotation started >Block quotation continued >The last line of the block quotation **>The expandable block quotation started right after the previous block quotation >It is separated from the previous block quotation by an empty bold entity >Expandable block quotation continued >Hidden by default part of the expandable block quotation started >Expandable block quotation continued >The last line of the expandable block quotation with the expandability mark|| Please note: Any character with code between 1 and 126 inclusively can be escaped anywhere with a preceding '\' character, in which case it is treated as an ordinary character and not a part of the markup. This implies that '\' character usually must be escaped with a preceding '\' character. Inside pre and code entities, all '`' and '\' characters must be escaped with a preceding '\' character. Inside the (...) part of the inline link and custom emoji definition, all ')' and '\' must be escaped with a preceding '\' character. In all other places characters '_', '*', '[', ']', '(', ')', '~', '`', '>', '#', '+', '-', '=', '|', '{', '}', '.', '!' must be escaped with the preceding character '\'. In case of ambiguity between italic and underline entities __ is always greadily treated from left to right as beginning or end of an underline entity, so instead of ___italic underline___ use ___italic underline_**__, adding an empty bold entity as a separator. | |
| parseMode | No | Message formatting mode: Markdown (legacy), MarkdownV2 (comprehensive), or HTML (tag-based) | MarkdownV2 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'send a message' without mentioning authentication, rate limits, error handling, or what happens on failure. The minimal description does not adequately inform the agent of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core function. It is front-loaded and wastes no words, though it could benefit from a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two parameters and no output schema or annotations, the description is incomplete. It does not explain return values, error messages, or prerequisites like bot token setup. A simple send message tool still needs basic behavioral context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both parameters, especially messageText with extensive formatting examples. The tool description adds no additional meaning beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a message using a Telegram bot in Markdown format. It distinguishes from siblings like sending documents, photos, or videos by specifying 'message' and 'Markdown format'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sending formatted text messages, but lacks explicit guidance on when to use it vs. siblings or which parse mode to prefer. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_telegram_documentSend Telegram DocumentB
Send a document/file via Telegram bot
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | File path or HTTP URL to the document | |
| caption | No | Document caption with formatting support | |
| filename | No | Custom filename for the document | |
| parseMode | No | Caption formatting mode | MarkdownV2 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the short description omits behavioral details such as file size limits, supported file types, error handling, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that states the purpose without unnecessary words, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description is minimally adequate but lacks return value information (e.g., confirmation or sent message object).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The tool description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Send) and the resource (document/file via Telegram bot), distinguishing it from siblings like photo and video tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives (e.g., send_telegram_photo, send_telegram_video) or prerequisites like bot permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_telegram_photoSend Telegram PhotoC
Send a photo/image via Telegram bot
| Name | Required | Description | Default |
|---|---|---|---|
| photo | Yes | File path, HTTP URL, or base64 encoded image data | |
| caption | No | Photo caption with formatting support | |
| parseMode | No | Caption formatting mode | MarkdownV2 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only states it sends a photo, with no information about side effects, permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary information. It is front-loaded but could benefit from a second sentence addressing common constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no description of return values or error conditions make the tool definition incomplete for an agent to understand full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond what the schema already provides. The description does not clarify the photo parameter types beyond the schema's enumeration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a photo/image via Telegram bot, distinguishing it from sibling tools like send_telegram_document or send_telegram_video. However, it lacks specifics like supported file formats or size limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., send_markdown_message_as_telegram_bot, send_telegram_document). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_telegram_videoSend Telegram VideoC
Send a video via Telegram bot
| Name | Required | Description | Default |
|---|---|---|---|
| video | Yes | File path or HTTP URL to the video | |
| caption | No | Video caption with formatting support | |
| filename | No | Custom filename for the video | |
| parseMode | No | Caption formatting mode | MarkdownV2 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It offers no information about side effects, permissions, rate limits, or response behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified. It fails to convey useful information that would help an agent, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no annotations or output schema, the description is extremely incomplete. It omits prerequisites, error conditions, return format, and any behavioral nuance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the input schema already provides for parameters like video, caption, filename, and parseMode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a video via Telegram bot' clearly states the action (send) and resource (video via Telegram bot), and it is distinct from sibling tools like send_telegram_photo or send_telegram_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., send_telegram_document for other file types). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.6- First observed
send_markdown_message_as_telegram_bot - First observed
send_telegram_document - First observed
send_telegram_photo - First observed
send_telegram_video
TDQS
Scored across 4 tools
Each tool clearly targets a distinct content type (markdown message, document, photo, video), with no overlapping purposes.
The first tool 'send_markdown_message_as_telegram_bot' breaks the 'send_telegram_<type>' pattern used by the other three, mixing naming conventions.
Four tools is reasonable for a Telegram notifier; it's concise but could benefit from a few more common actions like send_audio or send_sticker.
Covers key send operations for text, document, photo, and video, but notably absent are audio, location, and plain text (non-markdown) sending, which are common Telegram features.
Maintenance
Related MCP Connectors
Run a Telegram channel from your AI agent. Posts go out through your own bot, not your account.
Messaging tools for AI agents: send messages, manage chats, groups and channels.
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to send and receive messages, media, and files on Telegram, and manage chats via a bot token.17MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with the Telegram Bot API, allowing them to send messages, forward messages, get bot information, and receive updates.11 npm3MIT
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to send notifications and receive responses via Telegram.29 npm4MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI coding agents to send structured Telegram notifications for events like questions, plan_ready, final, attention_needed, and error.MIT