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.