notification-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TELEGRAM_BOT_TOKEN | No | Telegram bot token. Optional if bot_token is set in the TOML configuration file; config.toml must contain bot_token_env = "TELEGRAM_BOT_TOKEN" for this environment variable to be used. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notifyB | Queue a notification. Delivery channel and recipient are chosen by server settings. event: info, action_required (needs a decision), review_requested (ready to inspect), or error. source identifies the project/task. url optionally links to the result. idempotency_key prevents duplicate queue entries for an identical logical event. |
| notification_statusA | Read queued/sending/sent/failed status. 'sent' does not confirm the user read it. |
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
The two tools are clearly distinct: notify creates/queues a notification, while notification_status reads its delivery state. There is no overlap in purpose or ambiguity about which to call.
The names are readable and individually clear, but they follow different conventions: 'notify' is a bare verb while 'notification_status' is a noun phrase without an action prefix. This is a minor inconsistency rather than chaotic naming.
Two tools is on the thin side for a notification server, but the pair covers the essential send-and-check workflow without unnecessary bloat. It feels slightly under-scoped but not unusably so.
The basic lifecycle of queueing and checking delivery status is covered, and the details around idempotency and state are thoughtfully described. Missing capabilities like canceling a queued notification or confirming read receipt are notable but not fatal gaps.