feat(mcp): Implement basic support for Tasks

[LucaButBoring]

Description

Implements client support for MCP Tasks via an adapter model that handles both tool execution modes identically. This can later be hooked into event handlers in a more intelligent way, but this unblocks support for simply invoking task-augmented tools.

Note that unlike strands-agents/sdk-typescript#357, this PR handles the capability/executionMode logic explicitly, as the MCP Python SDK's implementation of Tasks does not encapsulate that logic, unlike the MCP TS SDK.

Related Issues

#1260

Documentation PR

N/A

Type of Change

New feature

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

• I ran hatch run prepare
• I spot-checked against an MCP server that supports Tasks

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

❌ Patch coverage is 96.62921% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/strands/tools/mcp/mcp_client.py	96.62%	1 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[dbschmigelski]

High level comment

I think we should consider the experimental nature of tasks.

I am fine with the session.experimental.poll_task in the non-experimental strands.MCPClient.

But what feels strange to me is that this is not opt-in on behalf of the mcp client. Instead it seems that a Strands application could be automatically opted in to the experimental behavior because of a change made to a remote MCP server. For an experimental feature that feels strange. But want to hear your thoughts on how things like this have been rolled out for MCP in the past!

[LucaButBoring]

This is the first time we've had a situation like this in MCP, so there's room for discussion on how we integrate this. My reasoning is just that it's better to be optimistic and elegantly handle errors than it is to force a break without the application opting into support. We can put this under some sort of option if you'd prefer the latter behavior, though.

My general opinion on this is that it should be handled as invisibly as possible, which is why the TS SDK wraps both task and non-task tool calls in the same callToolStream method, with the intent being that an SDK consumer would simply replace their callTool calls with callToolStream in one go.

[dbschmigelski]

Regarding "optimistic and elegantly handle errors than it is to force a break without the application opting into support." I definitely agree in principal. If a breaking change was made to MCP tasks how would that be surfaced on the capability negotiation?

Basically I want to tease out if a client is on v1 of tasks and a server switches to v2 of tasks, would v1 no-op here or would it attempt to use the feature and potentially fail? Basically I want to be careful since the SDKs MCP dependency isn't pinned

[LucaButBoring]

It depends on the nature of the change - it likely wouldn't be communicated via capabilities (as capabilities themselves aren't versioned), so that could indeed cause problems depending on the client SDK version. While I don't anticipate us redesigning Tasks in a backwards-incompatible way at this point, it is possible that there could be some interplay between Tasks and the (probable) incoming new Streamable HTTP specs that could cause subtle issues. That would be a good argument in favor of putting this under an option.

I did forget that the MCP SDK version is unpinned however, I'll have to see if this even works on versions prior to November. That will definitely require some additional checks (though those ones can be automatic).

[dbschmigelski]

Spoke with @zastrowm, I think opt in is going to be necessary. I think we can do per-feature experimental flags using some new dictionary on the MCPClient class like

experimental: {
    tasks: bool
}

[LucaButBoring]

Implemented in the latest commit - I moved the other new task-specific options into a new dict on experimental.tasks, too.