Is your feature request related to a problem? Please describe.
I would like to be able to call tools as tasks. It would be something like McpClientTool.CallAsTaskAsync or McpClientTool.CallWithPollingAsync. Right now the only way seems to be invoking the tools manually with McpClient, which requires tracking which tool is for which client, and ideally also mapping stuff like metadata.
Describe the solution you'd like
Something like this:
namespace ModelContextProtocol.Extensions.Tasks;
public static class McpTasksClientToolExtensions
{
public static ValueTask<ResultOrCreatedTask<CallToolResult>> CallAsTaskAsync(this McpClientTool tool, ..., CancellationToken cancellationToken = default);
public static ValueTask<CallToolResult> CallWithPollingAsync(this McpClientTool tool, int maxConsecutiveStuckPolls = 60, ..., CancellationToken cancellationToken = default);
public static ValueTask<GetTaskResult> GetTaskAsync(this McpClientTool tool, string taskId, CancellationToken cancellationToken = default);
public static ValueTask<GetTaskResult> GetTaskAsync(this McpClientTool tool, GetTaskRequestParams requestParams, CancellationToken cancellationToken = default);
public static ValueTask<CancelTaskResult> CancelTaskAsync(this McpClientTool tool, string taskId, CancellationToken cancellationToken = default);
public static ValueTask<CancelTaskResult> CancelTaskAsync(this McpClientTool tool, CancelTaskRequestParams requestParams, CancellationToken cancellationToken = default);
public static ValueTask<UpdateTaskResult> UpdateTaskAsync(this McpClientTool tool, UpdateTaskRequestParams requestParams, CancellationToken cancellationToken = default);
}
the ... indicate placeholders, as I think it may be a good idea to provide additional arguments, similar to McpClientTool.CallAsync.
I am not a fan of all the (Get/Cancel/Update)TaskAsync methods there, because they are just plain wrappers over McpClient, meaning that if you provide a different task ID, they may target a completely unrelated task. Another possible way would be to make CallAsTaskAsync return some object containing the McpClient and the task ID that would make manual polling possible.
Implementation of this will also be a bit tricky because it will require changes in the core package to expose the required data to extensions or/and relying on stuff like InternalsVisibleToAttribute or using reflection/UnsafeAccessors.
I think I may look into implementing this if it would be helpful, but I would likely need a direction as of which ways to choose.
Describe alternatives you've considered
Implementing it myself with UnsafeAccessors.
Is your feature request related to a problem? Please describe.
I would like to be able to call tools as tasks. It would be something like
McpClientTool.CallAsTaskAsyncorMcpClientTool.CallWithPollingAsync. Right now the only way seems to be invoking the tools manually withMcpClient, which requires tracking which tool is for which client, and ideally also mapping stuff like metadata.Describe the solution you'd like
Something like this:
the
...indicate placeholders, as I think it may be a good idea to provide additional arguments, similar toMcpClientTool.CallAsync.I am not a fan of all the
(Get/Cancel/Update)TaskAsyncmethods there, because they are just plain wrappers overMcpClient, meaning that if you provide a different task ID, they may target a completely unrelated task. Another possible way would be to makeCallAsTaskAsyncreturn some object containing theMcpClientand the task ID that would make manual polling possible.Implementation of this will also be a bit tricky because it will require changes in the core package to expose the required data to extensions or/and relying on stuff like
InternalsVisibleToAttributeor using reflection/UnsafeAccessors.I think I may look into implementing this if it would be helpful, but I would likely need a direction as of which ways to choose.
Describe alternatives you've considered
Implementing it myself with UnsafeAccessors.