Add support for the Skills extension (SEP-2640)

Summary

Add support for the MCP Skills extension, SEP-2640 (io.modelcontextprotocol/skills, accepted 2026-09-01), so that .NET servers can publish Agent Skills and .NET hosts can discover, retrieve, and verify them.

Specification: https://github.com/modelcontextprotocol/ext-skills/blob/main/specification/stable/skills.mdx
SEP: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640

What the extension defines

• skills/list: paginated enumeration of the skills a server serves. Each entry carries the SKILL.md URI, the file's YAML frontmatter rendered as a JSON object, and a complete manifest of the skill's files with SHA-256 digests and sizes (or the string "dynamic" for generated content).
• skills/get: the same entry for a single skill by URI, including skills a server serves but does not list.
• Skill files themselves are ordinary resources read through resources/read. Hosts verify every read against the manifest, and treat an unlisted file as a change to the skill.
• resources/directory/read is an optional third method behind a directoryRead capability setting.

Why now

The working group asked for reference implementations in Tier 1 SDKs. The Go SDK has one in flight, and the conformance suite has scenarios for it (modelcontextprotocol/conformance#330). Two PRs against this repo exist: #1856 and a fuller one I am opening alongside this issue.

Proposed shape

A separate package, ModelContextProtocol.Extensions.Skills, matching how Extensions.Apps and Extensions.Tasks ship. It needs one small Core change: the constructors of PaginatedRequestParams and PaginatedResult are private protected, so no package outside Core can implement a paginated method.

Server side: an IMcpSkillCatalog behind skills/list and skills/get, plus an authoring model that reads a skill directory (or in-memory files), parses the SKILL.md frontmatter, computes the manifest from the bytes it serves, and registers the file resources, so a server author points at a directory of skills and is done.

Client side: SupportsSkills, ListSkillsAsync, GetSkillAsync, and a verified read that checks size and digest against the held entry and refuses unlisted files.

Open questions for maintainers

1. Separate package, or in Core?
2. Is a strict YAML-subset frontmatter reader acceptable, given the SDK takes no third-party dependencies? The alternative is requiring authors to restate the frontmatter as a JsonObject, which duplicates what is already in the file.
3. ttlMs / cacheScope on skills/list follow the same 2026-07-28 gating as tools/list (#1721). SEP-2640 currently words this as version-conditional; the Go SDK does the same thing.
4. resources/directory/read is optional in the SEP. Leave it for a follow-up?

Start by comparing the Extensions.Apps and Extensions.Tasks packages, then inspect Core's PaginatedRequestParams and PaginatedResult constructors. Review the proposed IMcpSkillCatalog, client methods, and conformance scenarios for the required skills/list, skills/get, and verified resource reads. Done means the package shape and open questions are resolved and the listed server and client capabilities are covered.