Repository navigation
.NET: Python: [Feature]: Move MCPSkillsSource to the released SEP-2640 (skills/list and skills/get) #8772
Description
Description
SEP-2640, the MCP Skills Extension, is now Final. In the released version, a server that declares the extension must implement two new methods, skills/list and skills/get (stable spec), and the specification targets protocol revision 2026-07-28 or later (same file). The final text does not define a skill://index.json resource.
MCPSkillsSource still discovers skills by reading skill://index.json (here), and the .NET AgentMcpSkillsSource does the same (here). That follows the draft that ADR 0029 was written against, and the ADR names the release of the spec as the point to revisit its design (ADR 0029). The spec has now been released, so I would like to propose the update and implement it myself.
In outline, discovery would call skills/list and follow its pagination, and direct references would resolve through skills/get. Each skill would take the entry shape the specification defines: a URI, the frontmatter, and the list of files with a digest and a size for each. File reads would be verified against those digests and limited to the files the entry lists, as the specification requires (SEP). I would keep the details open until we agree on the questions below.
Two pieces of work come first, and I would build on both rather than duplicate them. The released spec needs protocol revision 2026-07-28, which the 1.x line of the MCP Python SDK does not support (v1.30.0) and the 2.x line does (v2.2.0), while agent-framework-core pins mcp>=1.24.0,<2 (pyproject). Lifting that pin is tracked in #7446. The Python SDK's own support for the extension is in review in modelcontextprotocol/python-sdk#3485.
I have three questions before starting. First, should skill://index.json stay as a deprecated fallback for a transition period? The Foundry Toolbox integration reads skills through MCPSkillsSource today (here), so removing it outright would break that path. Second, would you prefer Python first, or both languages in one change, as in #8290? Third, may I start against the SDK pull request while #7446 lands, or would you rather I wait for both to merge?
Code Sample
No response
Language/SDK
Python
Metadata
Metadata
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
[-]Python: [Feature]: Move MCPSkillsSource to the released SEP-2640 (skills/list and skills/get)[/-][+].NET: Python: [Feature]: Move MCPSkillsSource to the released SEP-2640 (skills/list and skills/get)[/+]sun-9545sunoj commentedon Sep 25, 2026
Hi Daniel Quintas (@danielquintas8), thanks for creating this detailed issue! I'm really interested in working on this update. I'd be happy to handle the implementation or collaborate with you on it.
danielquintas8 commentedon Sep 28, 2026
Hi Eduard van Valkenburg (@eavanvalkenburg), I think this was closed by mistake. It is marked as completed, but main still discovers skills through
skill://index.json(here), and #7446 is still open. If the team would rather not take this change, or plans to do it internally, could you close it as not planned instead, so I know not to start? If it is still wanted, could you reopen it? I am happy to wait for #7446 and the SDK pull request before starting.danielquintas8 commentedon Oct 7, 2026
Hi SergeyMenshykh, could you clarify whether the team would welcome a community contribution for the migration to
skills/listandskills/get? I’m following up on my 28 September comment after this issue was closed as completed.I’m still willing to implement it once the MCP 2.x migration and SDK skills support land. If that contribution is wanted, could you reopen the issue? Otherwise, please clarify whether the team plans to handle it internally or does not plan to pursue the change.
danielquintas8 commentedon Oct 12, 2026
Hi SergeyMenshykh, I saw your .NET MCP skills work in #9198 and #9217. Is anyone already handling the Python
MCPSkillsSourcemigration toskills/listandskills/get?I would be happy to implement it after the MCP 2.x migration in #9236 lands. Could you confirm whether a community implementation is wanted and the intended Python scope? If so, could you reopen #8772 or point me to the issue you want the Python PR to address?
SergeyMenshykh commentedon Oct 12, 2026
Daniel Quintas (@danielquintas8), thanks for offering to help with the Python implementation, and sorry I missed your earlier comment! I’m currently working on the .NET support and had planned to tackle Python afterward, so your contribution would be very welcome 🙂
Let’s wait until the .NET implementation is finished before starting on Python. That should give us a clearer picture of the feature set and help us keep the two implementations aligned. Happy to coordinate with you on the Python work from there!