Claude Code Notification Hooks
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
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 |
|---|---|
| send_user_action_needed_notificationA | AUTOMATICALLY send urgent notifications when user input, decision, or immediate attention is required. Claude should proactively use this for: file conflicts, permission requests, critical errors requiring user choice, or when waiting for user response before proceeding. Essential for good UX - notify users immediately when blocked. |
| send_task_complete_notificationA | AUTOMATICALLY send success notifications when any significant task completes successfully. Claude should proactively use this for: builds finishing, tests passing, file operations completing, refactoring done, analysis complete, long operations finishing. Always notify users of completion for better UX. |
| send_error_notificationA | AUTOMATICALLY send error notifications with error sound when anything fails. Claude must proactively use this when: compilation fails, tests fail, file operations fail, network requests fail, validation errors occur, bash commands fail. Critical for error awareness - always notify on failures. |
| auto_notify_if_appropriateA | SMART AUTO-NOTIFICATION: Intelligently analyze context and automatically send appropriate notifications. Claude should use this proactively for: task completion detection, error analysis, user action evaluation, progress updates. This is the primary notification tool - use it frequently to keep users informed. |
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
The tools have overlapping purposes despite different names, as all are notification tools with specific triggers. The descriptions help differentiate contexts (errors, task completion, user actions, general auto-notification), but the boundaries are somewhat fuzzy, especially between auto_notify_if_appropriate and the more specific tools. An agent might struggle to choose between them in ambiguous situations.
The naming follows a consistent verb_noun pattern (e.g., send_error_notification, send_task_complete_notification), with all tools using snake_case. The only deviation is auto_notify_if_appropriate, which uses a slightly different verb style ('auto_notify' vs. 'send'), but overall, the naming is predictable and readable.
With 4 tools, the count is well-scoped for a notification server. Each tool serves a distinct notification type (errors, task completion, user actions, general auto-notification), and there are no unnecessary redundancies. This number allows for focused coverage without being overwhelming or too sparse.
The tool set comprehensively covers the notification domain for code-related contexts. It includes notifications for errors, task completions, user actions, and general auto-notification, ensuring no gaps in common scenarios like failures, successes, or required interactions. This provides a complete lifecycle of notification needs without dead ends.