MCP Notifications Support for Live Tool Updates

[flvndvd]

Description

The Model Context Protocol was designed to facilitate tool interactions in a standardized way. However, our current implementation only displays results once a tool has completed execution, which can lead to a degraded user experience, especially for long-running tools that may take several minutes to complete.

Previously, with Dust Apps, we could stream reasoning tokens as they were generated, providing immediate feedback to users. The introduction of tools changed this paradigm, creating a gap in user feedback during tool execution.

Implementation

This PR introduces foundational support for MCP notifications, enabling server-to-client intermediate updates during tool execution. We leverage the notifications/progress method from the MCP specification, which provides a structured way to communicate progress updates.

The notification system requires:

• Progress indicator (normalized between 0 and 100)
• Optional label for status description
• Optional output that follows our existing MCPToolResultContentType structure

We temporary hack the progressToken used to ensure only active requests can get progress notification, since it's not yet available in the ToolCallback. The PR was recently merged and the SDK has not been published yet. This logic will be removed once it's available (PR modelcontextprotocol/typescript-sdk#328).

For example, an image generation tool can now provide:

{
  method: "notifications/progress",
  params: {
    progress: 50,
    label: "Generating image...",
    output: {
      type: "image",
      mimeType: "image/png"
    }
  }
}

Dependencies

We've updated to the latest MCP SDK which includes proper notification support and fixes the ESM issues reported in modelcontextprotocol/typescript-sdk#217.

Future Work

While this PR establishes the basic infrastructure, the current implementation prioritizes functionality over type safety. A follow-up PR will introduce proper TypeScript types and wrappers around the notification system.

The decision to use a subset of our output types rather than the complete MCPToolResultContentType allows tools to send partial results during execution, which is essential for progressive updates. This approach maintains flexibility while ensuring consistent structure in notifications.

Some refactoring is required around the AgentMessage component to handle notification as part of the streaming message.

Tests

Risk

Deploy Plan

[Fraggle]

you rely on the timeout above to exit the loop if the tool never ends ?

is the toolPromise resolved when the timeout is reached or does it raise an error or something ?

[flvndvd]

If the tools never ends, it works like before. If timeout is reached, then it raises an McpError that will be caught by the surrounding try/catch block.

Here is the Promise.race() is used to either yield the notification or the result based on the first one that resolves.

[Fraggle]

I understand but if you have an error, how does the while(toolDone) behave ?

[flvndvd]

There are two scenarios here:

1. Looking at the return type of callTool it returns an object with isError. This one will properly exit the loop from the toolPromise.then(() => MCP_TOOL_DONE_EVENT_NAME),,
2. callTool can also throw an error like it does when the timeout is reached. Here is what will happen:

• toolPromise will reject with a timeout error
• The Promise.race() will reject with that same error
• The error will propagate out of the while loop
• The outer try/catch will catch the error

[Fraggle]

i find it a bit convoluted to have the tool promise to turn into a string to turn into a boolean. Can't you make it a bit more simple ?

[Fraggle]

My main concerns is the handling of the potential infinite loop.