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

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.

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..

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

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?

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.

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. :)

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)

@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.

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

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".

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"

@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.

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.

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?

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.