Skip to main content
Glama
harnyk

Telegram Notifier MCP Server

by harnyk

Telegram Notifier MCP Server

npm version License: WTFPL Node.js Version TypeScript ESLint MCP Telegram Bot API pnpm npm downloads

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

  1. Message @BotFather on Telegram

  2. Use /newbot command and follow instructions

  3. Save the bot token (looks like 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

2. Get Chat ID

For personal messages:

  1. Message your bot first

  2. Visit: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates

  3. Find the chat.id value

For channels:

  1. Add your bot to the channel as admin

  2. Send a message to the channel

  3. 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 link

4. 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, or HTML (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 typecheck

Configuration Examples

Claude Desktop

{
  "mcpServers": {
    "telegram-notifier": {
      "command": "telegram-notifier",
      "env": {
        "TELEGRAM_BOT_TOKEN": "123456789:ABCdefGHIjklMNOpqrsTUVwxyz",
        "TELEGRAM_CHAT_ID": "-1001234567890"
      }
    }
  }
}

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if needed

  5. Run pnpm lint and pnpm typecheck

  6. Submit a pull request

License

WTFPL - Do What the Fuck You Want to Public License

Available Tools

4 tools
send_markdown_message_as_telegram_botSend Telegram Message in Markdown formatB

Send a message using Telegram bot in Markdown format

ParametersJSON Schema
NameRequiredDescriptionDefault
messageTextYesMessage 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.
parseModeNoMessage formatting mode: Markdown (legacy), MarkdownV2 (comprehensive), or HTML (tag-based)MarkdownV2

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
documentYesFile path or HTTP URL to the document
captionNoDocument caption with formatting support
filenameNoCustom filename for the document
parseModeNoCaption formatting modeMarkdownV2

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
photoYesFile path, HTTP URL, or base64 encoded image data
captionNoPhoto caption with formatting support
parseModeNoCaption formatting modeMarkdownV2

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
videoYesFile path or HTTP URL to the video
captionNoVideo caption with formatting support
filenameNoCustom filename for the video
parseModeNoCaption formatting modeMarkdownV2

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness2/5

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.

Completeness1/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 4 tool updatesv0.1.6
    • First observedsend_markdown_message_as_telegram_bot
    • First observedsend_telegram_document
    • First observedsend_telegram_photo
    • First observedsend_telegram_video

TDQS

B3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool clearly targets a distinct content type (markdown message, document, photo, video), with no overlapping purposes.

Naming Consistency2/5

The first tool 'send_markdown_message_as_telegram_bot' breaks the 'send_telegram_<type>' pattern used by the other three, mixing naming conventions.

Tool Count4/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers