Allows sending notifications with different urgency levels and receiving user responses via Telegram messages.
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., "@notification ask me if I should proceed with deployment to production"
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.
An MCP server for Cline that enables sending notifications and receiving responses via Telegram. When Cline needs to ask a question, it will send you a Telegram message and wait for your response.
Send notifications with different urgency levels (low, medium, high)
Automatically waits for user responses
Configurable timeout (defaults to 30 seconds)
Stops Cline when user is unavailable to prevent unwanted actions
Related MCP server: telegram-mcp
npm install cline-notification-serverMessage @BotFather on Telegram
Send /newbot and follow the instructions
Save the bot token you receive (it looks like 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)
Start a chat with your new bot
Message /start to your bot
Send a message to your bot
Open this URL in your browser (replace BOT_TOKEN with your token):
https://api.telegram.org/botBOT_TOKEN/getUpdatesLook for the chat object and note the id field - this is your chat ID
Add the server to your Cline configuration file:
For VSCode extension (cline_mcp_settings.json):
{
"mcpServers": {
"notification": {
"command": "npx",
"args": ["cline-notification-server"],
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token",
"TELEGRAM_CHAT_ID": "your_chat_id"
}
}
}
}For Claude desktop app (claude_desktop_config.json):
{
"mcpServers": {
"notification": {
"command": "npx",
"args": ["cline-notification-server"],
"env": {
"TELEGRAM_BOT_TOKEN": "your_bot_token",
"TELEGRAM_CHAT_ID": "your_chat_id"
}
}
}
}When Cline needs to ask you a question:
It sends a message via Telegram using your bot
Waits up to 30 seconds for your response
If you respond within 30 seconds, Cline continues with your answer
If you don't respond within 30 seconds, Cline stops and waits for you to restart it
When this server is configured, Cline can use it to ask you questions:
// Example of how Cline uses the notification tools
const response = await use_mcp_tool({
server_name: "notification",
tool_name: "send_notification",
arguments: {
message: "Should I proceed with deploying to production?",
project: "MyApp",
urgency: "high"
}
});Messages are formatted with:
🚨 Prefix for high urgency
⚠️ Prefix for medium urgency
No prefix for low urgency
TELEGRAM_BOT_TOKEN: Your Telegram bot token from BotFather
TELEGRAM_CHAT_ID: Your Telegram chat ID where messages will be sent
Feel free to open issues or submit pull requests if you have suggestions for improvements.
MIT
Check if the user has responded to a notification
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | The ID of the message to check for responses | |
| timeout_seconds | No | How long to wait for a response before giving up (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic check action, omitting whether the tool blocks, whether it returns a boolean, or whether it has side effects. The schema parameter for timeout_seconds hints at waiting, but the description adds no such context.
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, focused sentence with no fluff. It is front-loaded and communicates the core purpose directly, making it easy for an agent to parse quickly.
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?
The tool has no output schema and no annotations, so the description should explain expected behavior and return value. It only states the check action, leaving the agent to infer timeout behavior, return format, and what constitutes a response. For a tool with a timeout parameter, this is a notable gap.
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?
The input schema has 100% coverage, with descriptions for both parameters, so the baseline is 3. The tool description does not add any extra meaning beyond what the schema already provides for message_id or timeout_seconds.
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 specific action ('Check') and resource ('if the user has responded to a notification'). It naturally distinguishes itself from the sibling tool send_notification, as checking is conceptually different from sending.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after sending a notification, nor does it exclude any scenarios where it would be inappropriate.
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 notification to the user
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message to send to the user | |
| project | Yes | The name of the project the LLM is working on | |
| urgency | No | The urgency of the notification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It implies a side effect through the verb 'send' but does not mention permissions, reversibility, failure modes, or return behavior, leaving significant ambiguity for a mutation-like 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, front-loaded sentence with no wasted words. It immediately communicates the action and recipient, which is ideal for a simple tool.
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?
For a simple sending tool, the description and schema are adequate, but the lack of usage guidance and no output schema leave uncertainty about expected outcomes. It is minimally viable but not comprehensive.
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?
The input schema already provides 100% coverage with clear descriptions for all three parameters, including the urgency enum. The description adds no additional parameter meaning, so a baseline score of 3 is appropriate.
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 text message notification to the user, using a specific verb and target. It doesn't explicitly contrast with the sibling tool check_notification_response, but the action is distinct enough to avoid confusion.
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 is provided on when to use this tool versus the sibling check_notification_response, nor any prerequisites or exclusions. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_notification_responsesend_notificationScored across 2 tools
The two tools have clearly distinct purposes: one sends a notification, the other checks for a response. There is no overlap or confusion between them.
Both tool names follow a consistent verb_noun pattern (send_notification, check_notification_response), using snake_case and clear action-object structure.
With only 2 tools, the set feels thin, but it is plausible for a narrowly scoped notification utility. It is not extreme, but on the low end of the typical range.
The pair covers sending a notification and checking for a response, which are the core operations. Missing features like canceling or resending are minor gaps that agents can work around.
Central Slack/Telegram router with jobs, memory, approvals, and A2A delegation
Send mobile pings and route human questions, approvals, and handoffs from AI agents.
Send tasks and notifications to people's phones. Answers build a queryable knowledge base.
Telegram CRM: manage contacts, conversations, tickets, campaigns and analytics.
