node-notifier
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_NOTIFIER_CONFIG | No | Can supply the configuration path instead of --config. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Send local desktop notifications when requested. Use list_notification_profiles to discover configured profiles and their intended purpose. Choose a profile by name, or use kind for a built-in profile. A profile determines its kind. Use waiting just before asking for user input; the local timer handles repeats. Use a stable task_id unique to this chat/task. Success/error for that task stops its old waiting reminder. Info does not stop it. Acknowledgement only silences a reminder: it is not an answer, approval, or permission. Reminders last only while this MCP process is running. Do not call tools repeatedly to implement a timer.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| notifyA | Show a local notification using a built-in kind or a configured profile from list_notification_profiles. The profile supplies its kind, title, icon and audio settings. Waiting can repeat until acknowledged. Returns promptly; later delivery errors appear in list_notifications. |
| acknowledge_notificationA | Stop repetitions and audio for one notification. Does not answer a question or grant permission. |
| list_notificationsA | Inspect current reminders, acknowledgements and asynchronous delivery/audio errors for this MCP connection. |
| list_notification_profilesA | List available built-in and custom notification profiles with their names, kinds, titles and descriptions. Reads current configuration; use the returned name in notify.profile. |
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 4 tools
Each tool targets a distinct action: creating a notification (notify), stopping one (acknowledge_notification), inspecting active notifications (list_notifications), and inspecting configuration profiles (list_notification_profiles). The two list_* tools are clearly differentiated by their descriptions (runtime state vs. configuration catalog).
Three of four tools follow a consistent verb_noun pattern (acknowledge_notification, list_notifications, list_notification_profiles). The bare verb 'notify' is a minor deviation but remains clear and readable.
Four tools is well-scoped for a notification server: create, acknowledge, inspect runtime state, and inspect profiles. Each tool earns its place with no redundancy.
Core lifecycle (notify, repeat, acknowledge, inspect state and errors) is covered, and profile discovery is present. Minor gaps: no way to dismiss/clear a non-repeating notification or read a single notification's details beyond the list view.