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
@Kludex after thinking it and reading modelcontextprotocol/modelcontextprotocol#2133, i aggre with you. It would follow the extensions philosophy, as the typescript library already does with ext-apps. Who is supposed to handle the creation of the repo and such? i wouldn't mind contributing, as i want to use this feature myself
SEP-2663 is extension-package-only and will ship as a standalone library outside this repo (per maintainer comment above). The generic plumbing it depends on is tracked under the SEP-2133 / SEP-2575 / SEP-2322 / SEP-2243 issues. Closing.
Reopening — the plan changed since the close above: the Tasks extension core is being brought into this repo via #3005 rather than shipping as an external package, and the SDK does not yet implement SEP-2663 (the conformance suite now baselines the tasks-* scenarios as known failures until it lands). This issue tracks that work.
Adding a production data point, since the thread is mostly qualitative so far.
We run a remote MCP connector in production at Simetrik (Python/FastMCP, behind an ALB, OAuth, enterprise finance users). One of its tools hands work to an agent that legitimately takes minutes. With no task primitive available in this SDK, we hand-rolled the usual workaround: a bounded blocking wait inside tools/call, plus tool-result text instructing the model to chain another blocking poll.
30 days of APM on that tool, successful calls only (n=74):
p50
45.9 s
p95
241.7 s
max
241.9 s
calls past 60 s
22 (30%)
Two things that data says:
The median successful call sits exactly on our 45 s wait budget. For most runs it is the budget, not the work, that decides when we return — each of those hands back a handle and asks the model to poll again, costing an extra turn and extra tokens.
All 22 calls that ran past 60 s were recorded ok server-side. ~60 s is the ceiling we observe on the hosts we target. So the server believes it succeeded while the client may have stopped listening a long time earlier — and once the call is gone there is no way to deliver the result. A durable taskId plus tasks/get is exactly the fix.
We are blocked on language, not on the spec: SEP-2663 is Final, the C# and Rust SDKs shipped it, and FastMCP has a working runtime on its v4 beta line. Python is where our connector lives.
Happy to run #3005 against this workload and report back — including the operational questions the extension leaves open for server implementers: recovering orphaned/stalled tasks with no tasks/list, pollIntervalMs against real host polling behaviour, and whether a subscriptions/listen stream survives ALB/nginx idle timeouts at all. 👍 from us.
Activity
Kludex commentedon Jun 20, 2026
I don't think the Python SDK should support this unless a lot of people show interest. Thumbs up above if you want it.
Unless people show interest, I'm extremely against this being implemented here.
JoseBueno-plytix commentedon Jun 20, 2026
@Kludex do you see it as a standalone library? i think maybe an extra would fit nicely if the goal is to not bundle it always
Kludex commentedon Jun 20, 2026
Standalone library plus documented somewhere in the docs would be great. I don't think it needs to live in this repo.
JoseBueno-plytix commentedon Jun 20, 2026
@Kludex after thinking it and reading modelcontextprotocol/modelcontextprotocol#2133, i aggre with you. It would follow the extensions philosophy, as the typescript library already does with ext-apps. Who is supposed to handle the creation of the repo and such? i wouldn't mind contributing, as i want to use this feature myself
maxisbey commentedon Jun 26, 2026
SEP-2663 is extension-package-only and will ship as a standalone library outside this repo (per maintainer comment above). The generic plumbing it depends on is tracked under the SEP-2133 / SEP-2575 / SEP-2322 / SEP-2243 issues. Closing.
AI Disclaimer
maxisbey commentedon Jun 30, 2026
Reopening — the plan changed since the close above: the Tasks extension core is being brought into this repo via #3005 rather than shipping as an external package, and the SDK does not yet implement SEP-2663 (the conformance suite now baselines the
tasks-*scenarios as known failures until it lands). This issue tracks that work.AI Disclaimer
mcp tasks support (#2745)
mikerva commentedon Aug 19, 2026
@maxisbey any updates on this? i really need this for our app that is going live soon 🙏 thank you
simonschoe commentedon Aug 21, 2026
@Kludex just curious, is your pr still on the roadmap?
pedromarotta commentedon Aug 24, 2026
Adding a production data point, since the thread is mostly qualitative so far.
We run a remote MCP connector in production at Simetrik (Python/FastMCP, behind an ALB, OAuth, enterprise finance users). One of its tools hands work to an agent that legitimately takes minutes. With no task primitive available in this SDK, we hand-rolled the usual workaround: a bounded blocking wait inside
tools/call, plus tool-result text instructing the model to chain another blocking poll.30 days of APM on that tool, successful calls only (n=74):
Two things that data says:
okserver-side. ~60 s is the ceiling we observe on the hosts we target. So the server believes it succeeded while the client may have stopped listening a long time earlier — and once the call is gone there is no way to deliver the result. A durabletaskIdplustasks/getis exactly the fix.We are blocked on language, not on the spec: SEP-2663 is Final, the C# and Rust SDKs shipped it, and FastMCP has a working runtime on its v4 beta line. Python is where our connector lives.
Happy to run #3005 against this workload and report back — including the operational questions the extension leaves open for server implementers: recovering orphaned/stalled tasks with no
tasks/list,pollIntervalMsagainst real host polling behaviour, and whether asubscriptions/listenstream survives ALB/nginx idle timeouts at all. 👍 from us.mikerva commentedon Sep 30, 2026
@maxisbey any updates on this? i really need this for our app that is going live soon 🙏 thank you
maxisbey commentedon Oct 1, 2026
@mikerva yes this is planned to be taken on soon, although can't give exact promise but the idea is this month :)