You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explore streaming MCP notifications/progress from long-running tools (test, packages_get, packages_check_licenses) so clients can show live progress while a command runs, instead of only seeing output once the tool returns.
Background
#1612 captures a command's in-process mason Logger output and returns it in CallToolResult.content. That is the reliable way to get diagnostics to the agent, because the tool result is what every client feeds back to the model.
Progress notifications are a complementary, optional UX layer on top of that — not a replacement.
Proposal
When a client includes a progressToken in a request's _meta, the server emits notifications/progress as the command runs (e.g. test counts, "Optimizing tests…", per-package steps). The MCP spec (2025-03-26+) allows an optional human-readable message field alongside progress/total.
Over the stdio transport these are valid JSON-RPC messages on the same stdout stream, so they do not conflict with the "no non-MCP content on stdout" constraint that motivated #1612 (raw logger text broke it; structured notifications are the correct channel).
Caveats / open questions
Only allowed when the client supplies a progressToken; otherwise the server must stay silent.
Streaming is fire-and-forget with no ordering guarantee relative to the final result.
Need to confirm whether the dart_mcp server package exposes a helper for sending progress notifications, or whether we'd send raw notifications ourselves.
Summary
Explore streaming MCP
notifications/progressfrom long-running tools (test,packages_get,packages_check_licenses) so clients can show live progress while a command runs, instead of only seeing output once the tool returns.Background
#1612 captures a command's in-process mason
Loggeroutput and returns it inCallToolResult.content. That is the reliable way to get diagnostics to the agent, because the tool result is what every client feeds back to the model.Progress notifications are a complementary, optional UX layer on top of that — not a replacement.
Proposal
When a client includes a
progressTokenin a request's_meta, the server emitsnotifications/progressas the command runs (e.g. test counts, "Optimizing tests…", per-package steps). The MCP spec (2025-03-26+) allows an optional human-readablemessagefield alongsideprogress/total.Over the stdio transport these are valid JSON-RPC messages on the same stdout stream, so they do not conflict with the "no non-MCP content on stdout" constraint that motivated #1612 (raw logger text broke it; structured notifications are the correct channel).
Caveats / open questions
progressToken; otherwise the server must stay silent.dart_mcpserver package exposes a helper for sending progress notifications, or whether we'd send raw notifications ourselves.Related
directoryargument as the working directory #1600