Add ToolProgressIndicator for real-time tool progress updates

src/Infrastructure/BotSharp.Core/Routing/Executor/MCPToolExecutor.cs

@@ -1,5 +1,7 @@
 using BotSharp.Abstraction.Routing.Executor;
 using BotSharp.Core.MCP.Managers;
+using BotSharp.Core.MessageHub;
+using ModelContextProtocol;
 using ModelContextProtocol.Protocol;
 
 namespace BotSharp.Core.Routing.Executor;
@@ -33,8 +35,12 @@ public async Task<bool> ExecuteAsync(RoleDialogModel message)
                 return false;
             }
 
-            // Call the tool through mcpdotnet
-            var result = await client.CallToolAsync(_functionName, !argDict.IsNullOrEmpty() ? argDict : []);
+            // Call the tool through mcpdotnet, relaying whatever progress it reports along the
+            // way — see ToolProgressIndicator for why the reporter has to be supplied here.
+            var result = await client.CallToolAsync(
+                _functionName,
+                !argDict.IsNullOrEmpty() ? argDict : [],
+                progress: ToolProgressIndicator.For(_services, message));
 
             // Extract the text content from the result
             var json = string.Join("\n", result.Content.Where(c => c is TextContentBlock).Select(c => ((TextContentBlock)c).Text));
@@ -55,6 +61,99 @@ public Task<string> GetIndicatorAsync(RoleDialogModel message)
         return Task.FromResult(message.Indication ?? string.Empty);
     }
 
+    /// <summary>
+    /// Turns a tool's <c>notifications/progress</c> into indications, so a long call can say what
+    /// it is doing while it does it.
+    /// <para>
+    /// WHY THIS EXISTS. RoutingService pushes one indication when a function starts, and for a
+    /// tool that returns in a second that is the whole story. An MCP tool driving a browser takes
+    /// minutes, and that single line — "Working out the steps" — was all the chat had to show for
+    /// the entire run: no way to tell a task making progress from one that had wedged.
+    /// </para>
+    /// <para>
+    /// Supplying the reporter is also what MAKES a server report. The SDK only attaches a
+    /// <c>progressToken</c> to the request when this is non-null, and a server with no token to
+    /// answer has nowhere to send notifications — computer-autoplay's <c>await_web_task</c>
+    /// returns early from its own reporter for exactly that reason. So the argument is not an
+    /// optimisation of an existing stream; it is what opens it.
+    /// </para>
+    /// <para>
+    /// Nothing is required of a server that does not report progress: no notifications arrive,
+    /// <see cref="Report"/> is never called, and the call behaves as it did before.
+    /// </para>
+    /// </summary>
+    private sealed class ToolProgressIndicator : IProgress<ProgressNotificationValue>
+    {
+        private readonly MessageHub<HubObserveData<RoleDialogModel>> _hub;
+        private readonly string _conversationId;
+        private readonly RoleDialogModel _message;
+
+        private ToolProgressIndicator(
+            MessageHub<HubObserveData<RoleDialogModel>> hub,
+            string conversationId,
+            RoleDialogModel message)
+        {
+            _hub = hub;
+            _conversationId = conversationId;
+            _message = message;
+        }
+
+        /// <summary>
+        /// A reporter for this call, or null when there is no conversation to report into — a
+        /// tool invoked outside one, from a task or a test. Null is the right answer there rather
+        /// than a reporter that drops everything: it also tells the server not to bother sending.
+        /// <para>
+        /// The conversation id is read HERE, on the thread that starts the call, and captured.
+        /// <see cref="Report"/> runs on whichever thread the MCP transport is reading on, and
+        /// resolving a scoped service from there to ask again would be a race for a value that
+        /// cannot change during the call.
+        /// </para>
+        /// </summary>
+        public static ToolProgressIndicator? For(IServiceProvider services, RoleDialogModel message)
+        {
+            var conversationId = services.GetRequiredService<IConversationService>().ConversationId;
+            if (string.IsNullOrWhiteSpace(conversationId))
+            {
+                return null;
+            }
+
+            var hub = services.GetRequiredService<MessageHub<HubObserveData<RoleDialogModel>>>();
+            return new ToolProgressIndicator(hub, conversationId, message);
+        }
+
+        /// <summary>
+        /// Pushes one indication per reported step.
+        /// <para>
+        /// Deliberately synchronous, which is why this is a hand-written IProgress rather than a
+        /// <see cref="Progress{T}"/>: Progress&lt;T&gt; queues every report to the thread pool
+        /// independently, so two steps reported together can arrive out of order — and the one
+        /// that arrives last is the one left on screen. Pushing inline keeps the order the server
+        /// sent them in.
+        /// </para>
+        /// </summary>
+        public void Report(ProgressNotificationValue value)
+        {
+            // A bare count with no message is a progress BAR's input, not a sentence, and the
+            // chat has nowhere to put it. Servers that only send numbers are simply not relayed.
+            if (string.IsNullOrWhiteSpace(value.Message))
+            {
+                return;
+            }
+
+            // Cloned: this is pushed to observers that read it, and the function's own message is
+            // still being used by the call in flight. Its indication is not ours to overwrite.
+            var indication = RoleDialogModel.From(_message);
+            indication.Indication = value.Message;
+
+            _hub.Push(new()
+            {
+                EventName = ChatEvent.OnIndicationReceived,
+                Data = indication,
+                RefId = _conversationId
+            });
+        }
+    }
+
 
     private static Dictionary<string, object?> JsonToDictionary(string? json)
     {