In recent months, the Model Context Protocol (MCP) has gained a lot of traction as a powerful foundation for building AI assistants. While many developers are familiar with its core request-response flow, there's one feature that I believe remains underappreciated: the ability of MCP servers to send **notifications to clients**.
Let’s quickly recap the typical flow used by most MCP-based assistants:
* A user sends a prompt to the assistant.
* The assistant attaches a list of available tools and forwards the prompt to the LLM.
* The LLM generates a response, possibly requesting the use of certain tools for additional context.
* The assistant invokes those tools and gathers their responses.
* These tool responses are sent back to the LLM.
* The LLM returns a final answer, which the assistant presents to the user.
This user-initiated flow is incredibly effective—and it’s what powers many AI assistants today.
However, MCP also supports a less obvious but equally powerful capability: **tool-initiated communication**. That is, tools can trigger actions that cause the MCP server to **send real-time notifications to the client**, even when the user hasn’t sent a new prompt.
This feature unlocks entirely new interaction models and use cases, and in this post, I’ll explore why it deserves more attention.
The different workflow could be like this:
* A MCP server decides to send some notification to a clien or to all connected clients.
* The MCP server sends a notification to the client (which is AI assistant).
* The assistant receives the notification and sends it as a prompt to the LLM.
* The LLM generates a response, possibly requesting the use of certain tools for additional context.
* The assistant receives the final response from the LLM and presents it to the user.
From a user perspective it could look like a chat message appeared without a prompt in the chat. But there are some scenarios where this could be useful.
## Use Cases for Notifications
Imagine a user has an AI assistant running quietly in the background most of the time. One of the connected MCP servers is a Smart Home server with access to various devices in the house—it can open or close windows and doors, toggle lights, adjust heating, and more.
At some point, the user tells the assistant:
**"Check that all doors are closed."**
The assistant checks by calling a tool from the Smart Home MCP server, confirms that all doors are closed, and closes any that aren’t.
But later, one of the doors is opened. Here's where notifications shine: the Smart Home server can **proactively send a notification** to the assistant about this event. The assistant processes the notification—possibly referencing prior conversations or configured rules—and responds intelligently:
**"The back door just opened. Are you expecting someone to enter the house?"**
Another scenario: a trading assistant is connected to both a stock market data feed and a news-monitoring MCP server. When critical news is published—e.g., negative coverage about Company X—the news server sends a notification. The assistant evaluates the context and alerts the user:
**"Negative news has just been published about Company X. Would you like to consider selling your shares?"**
These are just two examples among many where notifications can make assistants significantly more proactive and intelligent. That’s why I believe this feature is underrated and deserves more attention.
## Challenges of Notifications in MCP
Despite their potential, notifications in MCP come with challenges—primarily because the protocol specification doesn't clearly define **how** notifications should be used, or even **whether** they should be used beyond technical updates.
Yes, notifications are supported. For example, MCP includes technical notifications such as *"tools list changed"*. However, there's no official guidance for using notifications for general-purpose communication. The spec defines the structure of a notification, but not its semantics or integration in real-world assistant workflows.
Another issue is that LLMs aren’t designed to process notifications. They're built to handle **user prompts**, not asynchronous updates from external sources. There’s no established way to indicate to the LLM that a message is a notification and should be treated differently than a prompt from a human user.
## Attempt to Add Notification Support in CleverChatty
I recently released [CleverChatty](https://github.com/Gelembjuk/cleverchatty), an open-source Go package that implements core AI assistant functionality for working with various MCP servers and LLMs. I also built a companion CLI tool, [CleverChatty CLI](https://github.com/Gelembjuk/cleverchatty-cli), that lets you run the assistant directly in the terminal.
To explore notification support, I tried extending the system with basic notification handling. The idea was simple: register a handler in the assistant that processes incoming notifications from the MCP server and passes them to the LLM for reasoning and response.
### Implementation Details
CleverChatty uses the excellent [mcp-go](https://github.com/mark3labs/mcp-go) library for MCP client functionality. Handling notifications is straightforward—you register a callback like this:
```go
for serverName, client := range host.clients {
client.OnNotification(func(notification mcp.JSONRPCNotification) {
callback(serverName, notification)
})
}
```
When a notification arrives, the assistant extracts its contents, sends it to the LLM, and displays the generated message to the user.
To simulate notifications, I also built a mock Smart Home server using `mcp-go`. It randomly opened or closed windows and sent a corresponding notification:
```go
mcpSerever.SendNotificationToAllClients("tool/window_state",
map[string]any{
"window_name": randomWindow,
"_content": mcp.TextContent{
Type: "text",
Text: fmt.Sprintf("Window %s state changed to %s", randomWindow, getStateTitle(windows[randomWindow])),
},
},
)
```
---
## Why the Experiment Failed
Unfortunately, the experiment wasn’t successful.
The biggest issue was **broken communication** between the MCP server and the assistant. After a notification was sent, subsequent tool calls from the assistant would often hang. This only happened **after** a notification had been received, suggesting a potential bug in the `mcp-go` library—but I didn’t investigate it deeply.
Another issue: there’s no native role in the LLM message format for notifications. I had to send the notification as a `"user"` message, with additional `"system"` instructions explaining that it should be treated as a notification. This hack worked, but it’s a fragile workaround. Ideally, notifications should have their own dedicated role or message type.
---
## Final Thoughts
From this experience, it’s clear that while **notifications are technically possible** in MCP-based systems, they’re **not ready for production** use just yet. But I still believe in the concept—it opens up a lot of exciting opportunities for proactive assistants.
I hope to revisit this idea in the future, especially in the context of **A2A (Assistant-to-Assistant)** communication. Maybe in that setting, it will be easier to support workflows where tools or other assistants push data to an AI agent in real time.
