Send notifications from AI agents directly to your Telegram account via a bot.
Send text messages (send_message): Plain or formatted text using HTML, Markdown, or MarkdownV2
Send photos (send_photo): Images via URL or local file path, with an optional formatted caption
Send documents/files (send_document): Files (reports, logs, artifacts) via URL or local file path, with an optional formatted caption
Configure once with a bot token and username, then receive automatic notifications from MCP clients like Claude Desktop, Cursor, and Windsurf.
Provides tools to send text messages, images, and files as notifications to users through a Telegram bot.
Click on "Install 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 Notify MCP Send a notification to my Telegram once the report is ready"
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.
A dead-simple MCP server with one job: send AI agent progress back to you on Telegram.
That's it. No chat management, no group administration, no inline queries. Just notifications — as text, images, or files.
You kick off an agent, walk away, and get a Telegram message when it's done (or while it's working). Nothing more, nothing less.
Message @BotFather on Telegram
Send /newbot and follow the prompts
Copy the bot token
Find your bot on Telegram and send /start. This is required so the bot can discover your chat ID.
claude mcp add telegram -e TELEGRAM_BOT_TOKEN=your-token -e TELEGRAM_USERNAME=your-username -- npx @parthj/telegram-notify-mcpAdd to your MCP config file:
{
"mcpServers": {
"telegram": {
"command": "npx",
"args": ["-y", "@parthj/telegram-notify-mcp"],
"env": {
"TELEGRAM_BOT_TOKEN": "your-bot-token",
"TELEGRAM_USERNAME": "your-telegram-username"
}
}
}
}Related MCP server: telegram-commandcode
Environment Variable | Required | Description |
| Yes | Bot token from @BotFather |
| Yes | Your Telegram username (without the @) |
Three tools. That's the entire surface area.
send_messageSend a text update to the user.
Parameter | Type | Required | Description |
| string | Yes | The message text |
| string | No |
|
send_photoSend an image — a screenshot, a chart, a generated visual.
Parameter | Type | Required | Description |
| string | Yes | URL or absolute file path |
| string | No | Photo caption |
| string | No | Caption formatting mode |
send_documentSend a file — a report, a log, a build artifact.
Parameter | Type | Required | Description |
| string | Yes | URL or absolute file path |
| string | No | Document caption |
| string | No | Caption formatting mode |
On the first tool call, the server resolves your username to a chat ID via the Telegram Bot API's getUpdates
Sending /start to the bot is required — Telegram bots can only message users who have initiated a conversation
The chat ID is cached for the lifetime of the process
git clone https://github.com/ParthJadhav/telegram-notify-mcp.git
cd telegram-notify-mcp
npm install
npm run buildMIT
Send a document or file to the configured Telegram user. Accepts a URL or local file path.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | Document caption | |
| document | Yes | URL or local file path of the document to send | |
| parse_mode | No | Caption formatting mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of important traits like file size limits, upload behavior, required permissions, or potential side effects.
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?
Two concise sentences; front-loaded with action; no wasted words, though could include more detail on behavior.
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 simple schema and no output schema, description should explain return value or expected behavior; it is adequate but leaves gaps for a sending tool.
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 description adds minimal value beyond schema; it confirms 'document' accepts URL or file path, but no deeper semantic context.
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?
Clearly states it sends a document or file to a Telegram user, distinguishing it from send_message and send_photo by specifying the file nature.
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; does not mention prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message to the configured Telegram user
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The message text to send | |
| parse_mode | No | Message formatting mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'send a text message' without detailing limitations (e.g., message length), error conditions, or whether a confirmation is returned. This is insufficient for a send operation.
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 that efficiently conveys the core action. It is front-loaded with the verb and resource, making it easy to parse.
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 2 parameters and no output schema, the description lacks details about return values (e.g., message ID), behavioral constraints, and prerequisites. It feels underspecified for a messaging tool.
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 description coverage is 100% for both parameters, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for 'text' and 'parse_mode'.
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), resource (text message), and destination (configured Telegram user), and it distinguishes from sibling tools like send_document and send_photo.
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 does not explicitly state when to use this tool versus alternatives like send_document or send_photo, but the sibling tool names are provided in context. It could be improved by adding guidance on selecting the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a photo to the configured Telegram user. Accepts a URL or local file path.
| Name | Required | Description | Default |
|---|---|---|---|
| photo | Yes | URL or local file path of the photo to send | |
| caption | No | Photo caption | |
| parse_mode | No | Caption formatting mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions accepting URL or local file path, but lacks details on side effects, authentication requirements, or error 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 with no wasted words, front-loading the action and input type. Highly concise and efficient.
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?
Adequate for a simple tool but lacks information on return format, error handling, and prerequisite configuration. Could be more complete given no output schema.
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 baseline is 3. The description adds minimal value beyond the schema, mostly repeating the photo parameter description without new semantic insight.
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 it sends a photo to a configured Telegram user, distinguishing it from sibling tools like send_document and send_message which handle different content types.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and description, but no when-not or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct content type: text, photo, or document. There is no overlap in purpose, making them easily distinguishable.
All tool names follow a consistent 'send_' prefix followed by the content type (message, photo, document), forming a clear and predictable pattern.
Three tools cover the essential notification actions (text, photo, document) without unnecessary extras, perfectly scoped for a notification server.
The set covers the most common message types. Minor gaps like video or audio are absent, but for a basic notify server this is not a significant omission.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ParthJadhav/telegram-notify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
