MCP notifications and the listener that isn't listening yet

What the spec defines

The MCP specification defines notifications as one-way JSON-RPC 2.0 messages. No id field, no reply expected. Fire and forget. There are five categories.

Resource notifications matter most for proactive workflows. A client subscribes to a specific resource URI. When that resource changes, the server sends notifications/resources/updated with the URI that changed, but not the new content. The client decides whether and when to re-read. Servers can also send notifications/resources/list_changed when their set of available resources shifts.

Tool and prompt notifications follow a similar list-changed pattern. A server adds or removes a tool, it sends notifications/tools/list_changed. Same for prompts. The tools available to an agent can change based on server-side state without the client needing to re-discover them.

Progress notifications track long-running operations. The client sends a progress token with a request, the server emits notifications/progress messages with percentages as work proceeds. Of all the notification types, this one sees the most real-world use.

Logging notifications send structured log messages from server to client. Eight severity levels from RFC 5424, a logger name, and arbitrary JSON data. Clients can filter by calling logging/setLevel.

None of this happens automatically. Capability negotiation during initialization determines what flows where. A server declares "resources": {"subscribe": true, "listChanged": true} if it supports subscriptions, and clients that don't declare matching capabilities won't receive them.

Who's actually using them

According to ecosystem statistics from mid-2026, 80% of public MCP servers expose only tools. About 11% add resources, 4% add prompts. Notification support doesn't show up in any published breakdown because the numbers are too small to register.

The servers that do implement notifications are almost all demos. prakharbanka/mcp-server-notifications shows progress notifications over Streamable HTTP. hesreallyhim/mcp-observer-server watches file system changes and sends resources/updated notifications. You can learn from them, but nobody's running them in production.

The bigger problem is the client side. You can build a server that sends notifications perfectly and still have nothing on the receiving end:

The only client with full subscription support is the MCP Inspector, which is a dev tool. Claude Desktop closed a feature request for proper resource handling as "not planned." People on the Python SDK struggle to wire up subscribe_resource because the client-side API is barely documented. A community discussion sums it up: "very few servers pay any attention to client subscription requests."

The SDKs themselves do implement the wire protocol. The TypeScript SDK has sendResourceUpdated(), sendResourceListChanged(), sendToolListChanged(). FastMCP (Python, v2.9.1) added MessageHandler subclasses with typed methods like on_tool_list_changed(). All the building blocks are there. Nobody picked them up.

The gap that matters most

Everything above is about notifications for internal state changes. The server knows a file was modified or a tool was added, and it passes the word along.

But proactive agents mostly need to react to things that happen outside the server. A Slack message arrives. A JIRA ticket gets updated. A Stripe payment fails. A GitHub PR picks up a review. These events show up as webhooks, HTTP POST requests from third-party services to a URL you control, and MCP has no way to receive them.

The protocol's two transports, stdio and Streamable HTTP, handle client-to-server requests with optional server-push responses. Neither accepts incoming HTTP from arbitrary external services. Hookdeck's analysis puts it well: "MCP assumes the world is synchronous."

The experimental Tasks primitive covers one piece. A tool call that starts a long-running operation gets back a task ID immediately. The client polls with tasks/get until it completes. Five states: working, input_required, completed, failed, cancelled. There's even an optional notifications/tasks/status notification, but the spec says explicitly: "Requestors MUST NOT rely on receiving this notification, as it is optional." Polling is the primary model.

Tasks answer the question "I started something, when will it finish?" They don't help with "something happened in the world that I didn't initiate." Hookdeck's phrasing is useful here: "Tasks give you the envelope. They don't give you the mailroom."

The MCP project is aware of the gap. In March 2026, they chartered a Triggers and Events Working Group co-led by engineers from AWS and Anthropic, with the goal of defining "a standardized callback mechanism — webhooks or similar — that lets servers push notifications when new data is available, with defined ordering guarantees." The charter targeted an initial RFC by end of April 2026. That deadline has passed.