AI Notify MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| show_completion_notificationB | Show a system notification when AI completes a response |
| auto_notify_completionB | Automatically show completion notification (call this after providing any response) |
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 essentially identical in purpose. Both 'auto_notify_completion' and 'show_completion_notification' describe showing a notification when AI completes a response, with only minor wording differences. An agent would have no meaningful basis to choose between them, leading to confusion and misselection.
The naming shows mixed conventions. 'auto_notify_completion' uses a verb-object pattern with underscores, while 'show_completion_notification' uses a verb-noun pattern with underscores. Both are readable, but the inconsistency in structure (auto vs. show, notify vs. notification) reduces predictability.
With only 2 tools, the server feels thin for its purpose of AI notifications. Given the tools are redundant, this exacerbates the issue—it's essentially one tool split into two. A more appropriate count would be 1-2 distinct tools, but here the duplication makes it seem artificially inflated.
The server's domain appears to be AI response notifications, but the tool set is severely incomplete. There are no tools for configuring notifications (e.g., setting preferences, disabling), handling different types of notifications, or managing notification history. The redundancy in the two tools does not add meaningful coverage, leaving significant gaps for agent workflows.