How to handle notifications from MCP server? What are best practices?

[Gelembjuk]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I have tried to implement support of notifications from MCP servers in my AI assistant.

As an example i use the "MCP server for smart home" . Ii simulates some actions related to a smart home. Like open/close windows/doors

It has tools to manage a "smart home" by LLM.

And i want to add a support of notifications when a status of a window/door is changed "by 3-rd party".

So, i use the notifications feature of MCP (with SSE transport). I can send a notification from the server and my AI assistant can receive it.
But i still can not find what should be the right contents of a notification.

This is what i have for now:

{
  "jsonrpc": "2.0",
  "method": "tool/window_open",
  "params": {
    "params": {
      "window_name": "living_room_front"
    },
    "result": {
      "type": "text",
      "text": "Window living_room_front state changed to open"
    }
  }
}

I made my assistant to parse this fine. But it is not universal solution . Other MCP server can have this different.

What is presumed to be in the "params"?
What is the method? should it be just name of one of my tools or resources? what are params and where should be some content of the notification?

Possible the notification is just a command "call this tool back with given params?"

Also, finally, how to provide the content of a notification to LLM?

Thank you.

[olaservo]

Hi @Gelembjuk it can be helpful to check out this reference server for examples of how different types of MCP notifications can be implemented: https://github.com/modelcontextprotocol/servers/tree/main/src/everything

And if you want to see how a client could listen for these in a Typescript implementation, check out the Inspector code for where notifications are referenced: https://github.com/search?q=repo%3Amodelcontextprotocol%2Finspector%20notification&type=code

[Gelembjuk]

Since this discussion started i have done some investigating. Maybe it will be interesting to someone here.
The summary is - notifications are technically supported but it is not the aim of MCP protocol and LLMs are not designed to react on notifications from tools.
I have described my experience in this blog post https://gelembjuk.hashnode.dev/an-underrated-feature-of-mcp-servers-client-notifications

[olaservo]

Edit - sorry I misread part of the spec and was thinking that Annotations could apply here but please disregard that comment.

What you're trying to do might actually fit into the Resource notification pattern although I'm curious if others have thoughts on this.

[chrstnwhlrt]

I just totally walked the way you already did and wanted to open an issue with a feature request for notificatons or events send by the server. I mean that would be a good way to actually make use of the stateful connection server to client.

My usecase is a mcp client connected to an imap mcp server which should work with new mails autonomously. It's easy for every mcp client to use a mcp server to handle mails, but there is no way to inform the mcp client (and make the agent/llm do the work) about new unhandled mails.

To archive this I have to build a complete notification chain myself which lets me question why I should use mcp in the first place..

[Gelembjuk]

Yes. This is one more classic example when notifications would be useful.

MCP is perfect for this because notification are already supported by the transport layer. So, only some attention here is required to clarify in specifications

[chrstnwhlrt]

I think this should be a part of the standard - as fast as possible. A lot of services are adapting this standard and every service has to deal with this challange in a custom way.

Another example: Atlassian just released their own remove mcp server. It's an easy way to connect your preferred llm to JIRA using your preferred mcp client (when it's finally bug free and the clients support oauth 2). Having notifications for new interactions/tickets is a crucial feature to have a totally anonomous agent working as an assistant. Otherwise the agents have to rely on polling the updates which leads to a huge overhead in requests and pushes the agent into the rate limits.

There are lots of use cases just like that. Am I missing something or why is the demand for this feature not proposed for the standard yet?

[hesreallyhim]

It's part of the standard - but it's optional if/how to implement it - the server can just ignore the client's request for updates. I think the problem is that most existing clients and servers are ignoring this - but it's in the standard. See below.

[chrstnwhlrt]

@olaservo The idea of this request is to have a way to get events/notifications from the mcp server to the mcp client (and on this way to the agent/llm).

A mail mcp server (or anything related to notifications/ action triggers) could be named as a typical use case.

Is there any way to propose something to the standard? Is this somehow a known feature request or is there any ongoing discussion related to this?

[olaservo]

Hi, sorry was sending myself a note about this to myself through email and accidentally created a reply to this thread! Looking into how to best route this topic. :)

[hesreallyhim]

This is already within the protocol... server can send notification to client about anything. Regarding resources (e.g. "inbox"), client can send SubscribeResourceRequest to server, and server can (choose to) send "resource/updated" notifications to client (or choose to do nothing). The real problem is that very few servers seem to pay any attention to this - I think Claude Desktop doesn't support resource subscriptions. However, Inspector does. (https://modelcontextprotocol.io/specification/2025-03-26/server/resources#subscriptions)

[hesreallyhim]

@chrstnwhlrt

Is there any way to propose something to the standard? Is this somehow a known feature request or is there any ongoing discussion related to this?

btw the protocol is in the repo https://github.com/modelcontextprotocol/modelcontextprotocol/ you can submit fixes or even propose changes if you want.

[Gelembjuk]

Please note, there is another problem related to notifications from a tools server back to AI agent - there is no way to tell LLM that "this request is from a tool inited by a tool". When we send a request to LLM we use roles - "user" or "assistant" or "system". And there is no a role or some option to mark a tool inited request.
Responses from tools when it was inited by LLM are provided with a "user" role. BUt this will not work in case of notifications.

So, it is not only about the transport. LLMs world also must adopt this

[hesreallyhim]

"orchestrator" just means like "chatbot app" right? (Sorry sometimes "orchestrator" is used to talk about an agent)

[Gelembjuk]

Yes. I do not know what is the right term now. I do not want to say "ai chat". And i am not sure what is exact difference between "ai agent" and "ai orchestrator".

[hesreallyhim]

i would probably say "chat application". AFAIK "orchestrator" is one kind of design for an "agent" (e.g. https://docs.getdynamiq.ai/low-code-builder/llm-agents/guide-to-agent-orchestration-linear-and-adaptive-orchestrators), vs. like ReAct I don't think they call the main LLM an "orchestrator" but I'm not an authority. But anyway I wouldn't call a chatbot an agent just because it has function-calling. Anyway... semantics.

I guess I don't know what you call "the thing that takes the tool_calls and executes the actual program/function/tool", but personally I would just say the "app"

[rednap]

@Gelembjuk

When we send a request to LLM we use roles - "user" or "assistant" or "system". And there is no a role or some option to mark a tool inited request.

There are AI messages with "tool_calls" in the response, right? and then the tool gets called and it responds and the AI gets the response. Maybe the response guides it to make another tool call. I don't know of any provider where there is a tool call result that then "initiates" a tool call request. Can you clarify?

this was the solution i ended up using. include instructions to the LLM to call another tool in the response to the first tool call. this works remarkably well, but it feels like a hack.

[hesreallyhim]

yeah there's something off there if you talk about the tool "instructing" the LLM to make another tool call response, but the important thing is not violating the expected turn-taking rules that providers expect, and there's probably different ways to frame it, like in some cases for sure the LLM needs to make two sequential tool calls, so that's the fine, the only thing that sounds weird to me is a tool result telling an LLM what to do, like the tail wagging the dog type thing.

[hesreallyhim]

What is presumed to be in the "params"?
What is the method? should it be just name of one of my tools or resources? what are params and where should be some content of the notification?

It sounds like you are talking about a "resources/updated" notification. Here is what they are supposed to look like:

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",
  "params": {
    "uri": "file:///project/src/main.rs"
  }
}

So the method would be as above. And you would need a resource URI to identify the window, or whatever. In my understanding, one thing missing here is the optional meta/_meta field that is available in the python-sdk, for example, where you can put whatever you want. But if you are talking essentially about a resource-update notification (which follows from a resource-subscribe "request"), then this is your answer. Client can also request to subscribe to updates about the list of tools. If somehow a "tool" is subject to change, I would probably define a set of tool resources, like tool://..., but the smart home sounds more to me like the window is a resource and you want updates about its status, or changes. This is already part of the spec. It's a bit awkward, IMO, because the "updated" notification is not supposed to really give you the update - it tells the client that it should do a read-resource call again to get the new status. But again, the issue seems to be that mcp server/client builders seem to disregard this (which I agree is something that could be extremely helpful).

[olaservo]

Agree with this based on other discussions:

the smart home sounds more to me like the window is a resource and you want updates about its status, or changes.

However I'm not totally clear on this statement:

If somehow a "tool" is subject to change, I would probably define a set of tool resources, like tool://...

Do you mean that the tool:// resources would correspond to responses from specific tools?

[hesreallyhim]

Honestly I'm reading through this discussion and I can't find what prompted the comment about having a "tool" as a resource, although the idea is coherent to the extent that afaict basically anything can be a resource but tools are already a primitive so i really don't know lol.

Do you mean that the tool:// resources would correspond to responses from specific tools?

i don't think i could have had this in mind. the only thing i can think of is like a tool that itself is dynamic and somehow changes (e.g. imagine a tool is a function and for some reason the function signature changes), i can't recall what this was in reference to, sorry - EDIT: - I think I was lost in another discussion by accident.