Extract Tasks logic to dedicated wrapper SDK

[LucaButBoring]

Which client?

All / shared core

The problem

Currently, the TS SDK does not support the Tasks extension after a month and has had significant blockers to even supporting it outside the SDK for quite some time now.

The Inspector handles this by routing almost completely around the SDK, and as a result has one of the only usable implementations of the Tasks extension in TS at the moment. I believe one of the main reasons Tasks hasn't seen significant client uptake so far is because most agent harnesses are in TS and are not particularly interested in reimplementing the entire Tasks spec themselves.

Solution you have in mind (optional)

Extract the Inspector's Tasks implementation to a dedicated wrapper SDK for other implementations to use. The Inspector itself would then migrate to said SDK as well. I think that (similar to MCP Apps) the ext-tasks repo should own the bulk of the implementation.

Alternatives or workarounds you have tried

N/A for this kind of thing.

Already built it locally?

Guidance says not to drop code, but I have code:

• Introduce extension SDK for TS ext-tasks#21
• [WIP] Migrate to Tasks extension SDK #2308

Part of my motivation for this is getting this into Kiro, so the original plan file includes some private implementation details about various interface contracts that I can't share, but I scrubbed those and have a clean plan file here: mcp-tasks-sdk-interface-clean.md

I don't consider most of the additional prompting to be particularly reproducible, but for completeness (I was experimenting with some new workflows as well):

Prompts

In ext-tasks: "Please read ~/Documents/mcp-tasks-sdk-interface.md and implement the SDK logic in ./packages/ext-tasks - exercise TDD, installing fast-check and using property-based tests extensively, leaving standard unit tests for only key specification-conformance cases. Commit as you go, but ensure you run each of our reviewer subagents and resolve issues prior to each commit. For any issue that is raised by reviewers, specification-correctness is the highest-precedence ground truth, followed by interface document requirements, followed by other concerns (including those of the reviewers themselves if they do not fall into one of the two preceding buckets)."

In inspector:

1. "Based on the plan at ~/Documents/mcp-tasks-sdk-interface.md, replace the Tasks implementation in this repository with our updated implementation from ../mcp-ext-tasks. For now, use a path-installation rather than a standard NPM registry installation."
2. "Alright, now - as for the Inspector repo, why is it then the current diff actually results in an increase of code in inspectorClient.ts, despite us moving almost all Tasks-related logic to the extension repo?"
3. "Alright, let's do it"
4. "rawWireRequest seems unnecessary now too, or rather, the whole invokeMcpClient dance should be pulled out to a dedicated method that calls the extension where needed as part of its logic. I think we should also do a pass now to see if any of the tests we added purely for coverage purposes are now redundant, and/or if the properties they assert actually belong in mcp-ext-tasks itself. Let's do that analysis and make changes where needed."
5. "It still seems odd that we pulled so many responsibilities out of the Inspector and yet added (rather than removed) tests, and not only that, that accounts for about as much code as we removed via doing the extraction to begin with. Can we look at the test changes more critically?"
6. "The diff ratio is still indicative of a problem somewhere, let's look at our newly-added files, next. Can any parts of rawMcpRequestChannel.ts, inspectorMcpRequester.ts, and extTasksSessionAdapter.ts be converted into consumer-agnostic forms and worked into mcp-ext-tasks? rawMcpRequestChannel.ts is the most generic component out of the three, and the other two primarily depend only on it and @modelcontextprotocol/client, so in terms of the dependency graph, all three seem like highly-likely candidates for code that is already nearly generic that we can unburden the Inspector with."
7. "How do we go further? We're removing around 500 lines of logic from the Inspector, but our net diff is still only -100 lines - even purely from a code review standpoint that's not great."
8. "This is looking much better, can we attempt to reduce the size of the overall Inspector diff, now? This is now largely a matter of improving its reviewability; the migration itself is considerably cleaner after the latest round."
9. "Can we reduce the modified file count instead, then? Most of the modified files are single-line changes that might be altered to not require changes at minimal cost to clarity and a substantial improvement in reviewability."
10. "Let's try doing the inlining - doing the extraction and a heavy separate refactor in the same PR may be excessive for a repo we don't directly maintain (we maintain mcp-ext-tasks but not mcp-inspector)."
11. "We seem to have quite a lot of Tasks-specific logic in InspectorClient again - can any of that be offloaded to mcp-ext-tasks?"
12. "Our inspectorClient.ts diff is +1011/-1765, there must be more we can do to reduce the added lines there. Additionally, I think there may have been preexisting bugs we fixed which we can leave out of scope, too - the modifications to managedRequestorTasksState.ts and its tests look like a case of that (there are even some spurious changes like t->task in a variable name), and there are probably others; I have not inspected the entire diff, however."
13. "Alright, committed - now, is there anything in mcp-ext-tasks that we extracted to fill a need from the Inspector that no longer exists after this pass? We should do a simplification pass on the changes there."

Everything after that was just dealing with Copilot review rounds, so I won't include it.

Before you submit

• I searched existing issues and this is not a duplicate.
• This is a request for the Inspector itself, not for the MCP specification or an SDK.

[LucaButBoring]

Possible overlap with modelcontextprotocol/typescript-sdk#2782 (unclear if that will be merged, and it's server-only as well)

[cliffhall]

@LucaButBoring Thanks for the issue.

Extract the Inspector's Tasks implementation to a dedicated wrapper SDK for other implementations to use. The Inspector itself would then migrate to said SDK as well. I think that (similar to MCP Apps) the ext-tasks repo should own the bulk of the implementation.

Agreed. I think the support for all extensions should lie in their own SDKs. We will await your release, and then refactor to that, taking your draft as a reference.