fix: task-mode tool calls failed with 'unknown error'

[jongalloway]

Problem

When VS Code's MCP client invokes dotnet_project with task support enabled (MCP SDK v1.1.0), the call fails with:

Task 08de8470c7f494c50000000000000002 failed: unknown error

This happens because the SDK's task infrastructure wraps tool calls in a task lifecycle. If the tool throws an unhandled exception, the SDK has no CallToolResult to return — so it surfaces an opaque 'unknown error' to the client.

Root Cause

Two issues compound:

1. Unhandled exceptions in tool execution propagate through the task pipeline without a structured error result
2. Progress channel failures (e.g., when the client doesn't support progress notifications) can throw during tool execution

Fix

Resilient error-handling filter (Program.cs)

The existing telemetry CallToolFilter now catches unhandled exceptions (excluding OperationCanceledException and McpException) and converts them into a CallToolResult { IsError = true } with a meaningful error message. This ensures the MCP task lifecycle always completes with a proper result.

Defensive progress reporting (DotNetCliTools.Core.cs)

Added ReportProgressSafe() that wraps progress notifications in try/catch so broken or unsupported progress channels never crash tool execution.

Task lifecycle conformance tests (McpConformanceTests.cs)

Two new tests exercise the full task lifecycle that VS Code uses:

• Server_DotnetProject_TaskMode_ShouldCompleteSuccessfully — full CallToolAsTaskAsync → GetTaskResultAsync → GetTaskAsync cycle
• Server_DotnetProject_TaskMode_ShouldAppearInTaskList — verifies task tracking via ListTasksAsync

Testing

• All 1,319 unit tests pass
• All 58 conformance tests pass (including 2 new task lifecycle tests)

General approach: Replace the generic catch (Exception ex) with catches that are limited to expected, recoverable exception types, and ensure that more serious process-level exceptions are not swallowed. In a boundary/adapter layer like this, keeping a fairly broad but still typed filter list is reasonable, but we should avoid a blanket Exception.

Best concrete fix here without changing user-visible behavior for ordinary errors:

• Change the catch (Exception ex) into a filtered catch that ignores non-recoverable exceptions (letting them propagate) and only handles “regular” exceptions as structured tool errors.
• In C#, this can be elegantly expressed with a when-filter: catch (Exception ex) when (ex is not OutOfMemoryException && ex is not StackOverflowException && ex is not ThreadAbortException).
• This preserves the current behavior for the vast majority of exceptions tools will throw (argument errors, IO errors, etc.), but stops us from swallowing catastrophic runtime failures.
• No imports or additional methods are required; all used exception types are in System and available by default.

Concretely, in DotNetMcp/Program.cs, at the catch (Exception ex) block starting at line 131, change it to a filtered catch as described above, keeping the catch body the same.

In general, to fix overly broad catch (Exception) blocks, you either (1) catch only the specific, expected exception types, or (2) if you truly need a broad catch for robustness, you still avoid swallowing critical system exceptions and optionally log unexpected ones. Here, the method is explicitly “best-effort” and should not throw to callers, so we should keep the behavior of not letting progress failures break tool execution, but refine which exceptions are caught.

The best targeted fix without changing external behavior is to:

• Narrow the catch from Exception to exclude severe system-level exceptions such as OutOfMemoryException, ThreadAbortException, and ThreadInterruptedException.
• Re-throw these critical exceptions while still swallowing ordinary ones.
• Optionally, we could log non-critical exceptions, but that would change behavior (by adding logging output) and might not be desired; the current comment suggests silence is acceptable, so we’ll keep it silent.

Concretely, in DotNetMcp/Tools/Cli/DotNetCliTools.Core.cs, in ReportProgressSafe, replace catch (Exception) with a catch (Exception ex) that checks for system-level exceptions and rethrows them, while swallowing everything else. This keeps the “best-effort; never let it break tool execution” contract for normal failures yet avoids suppressing critical runtime exceptions.

[Copilot]

Pull request overview

Improves MCP task-mode reliability so tool invocations return a structured CallToolResult instead of surfacing an opaque "unknown error" when exceptions occur, aligning behavior with VS Code’s MCP task lifecycle.

Changes:

• Add a resilient CallToolFilter that converts unexpected exceptions into CallToolResult { IsError = true } so task-mode calls always complete with a result.
• Make progress reporting best-effort by swallowing exceptions thrown from progress notifications.
• Add conformance tests that exercise CallToolAsTaskAsync + GetTaskResultAsync and task listing behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
DotNetMcp/Tools/Cli/DotNetCliTools.Core.cs	Wrap progress reporting in a safe helper so progress-channel failures don’t crash tool/task execution.
DotNetMcp/Program.cs	Extend the telemetry/tool filter to catch unexpected exceptions and return an error CallToolResult instead of throwing through the task pipeline.
DotNetMcp.Tests/Server/McpConformanceTests.cs	Add task-mode lifecycle tests to reproduce/guard against the VS Code task pipeline failure mode.
DotNetMcp.Tests/DotNetMcp.Tests.csproj	Add MCP SDK package reference for task-mode APIs used by new tests.

Comments suppressed due to low confidence (1)

DotNetMcp/Program.cs:139

• $"Internal error in {toolName}: {ex.Message}" can be unhelpful when ex.Message is empty and loses important context like exception type / inner exception. Consider including ex.GetType().Name and surfacing the most relevant inner message (while still keeping it concise) so clients can triage failures more easily.

                Content = [new TextContentBlock { Text = $"Internal error in {toolName}: {ex.Message}" }]
            };

---

You can also share your feedback on Copilot code review. Take the survey.

[jongalloway]

@copilot address comments

[Copilot]

@copilot address comments

Addressed both review comments in commit 4918f12:

1. Program.cs: The exception handler now runs both toolName and ex.Message through SecretRedactor.Redact() before including them in the error result, consistent with how CLI output is redacted elsewhere in the codebase.

2. McpConformanceTests.cs: Updated the comment to accurately reflect that the test validates the task infrastructure returns a structured result (instead of "unknown error") — the tool itself may legitimately fail (e.g., nonexistent project), so both Completed and Failed are valid terminal states.