Research guide · MCP · Skills · SEP-2640 · 14 September 2026
MCP Skills (SEP-2640): accepted spec, conformance and SDK status
MCP Skills has crossed an important boundary: SEP-2640 is accepted and its conformance coverage has landed. That does not mean every official SDK has shipped first-class Skills APIs. For implementers, the useful question is no longer “is there a draft?” but “which parts of the accepted wire contract can I rely on today, and which parts still require SDK-specific work?”
Published 14 September 2026 · sources checked 14 September 2026
Accepted
SEP-2640 status
11 Sep
Conformance merged
skills/list
Primary discovery method
skills/get
Single-skill lookup
Current status
Protocol readiness and SDK release readiness are different things
| Layer | Status | What it means now |
|---|---|---|
| SEP-2640 protocol | Accepted | Core-maintainer vote passed 1 Sep 2026. The SEP PR carries the final label, but remains open in GitHub. |
| Conformance | Merged | PR #330 merged 11 Sep 2026 with server and client scenarios for enumeration, manifests, directory reads and integrity checks. |
| TypeScript SDK | First-class API pending | Issue #2798 says custom handlers can express the extension, but no Skills-specific public API is available yet. |
| Python SDK | Implementation PR open | PR #3485 proposes skills/list, skills/get, optional directory reads and verification helpers. |
| Go SDK | Implementation PR open | PR #1238 proposes opt-in SEP-2640 protocol support with client/server validation and verification. |
The practical implication: do not infer “unsupported protocol” from a missing convenience API, and do not infer “shipped SDK support” from an accepted protocol. Check the exact SDK version and extension surface you are deploying.
Accepted wire shape
What a current Skills implementation should speak
SEP-2640 defines the io.modelcontextprotocol/skills extension. A server advertises the extension, exposes skill entries through skills/list and skills/get, and serves the actual SKILL.md plus supporting files through the normal MCP Resources primitive.
The accepted shape uses a per-file resource manifest. Static resources carry a URI, digest and size so clients can verify the bytes they receive. Optional directory browsing uses resources/directory/read and must only be treated as available when the extension advertises directoryRead.
For protocol version 2026-07-28 and later, the conformance scenarios also expect the modern result envelope and cache attributes where the base protocol requires them. Older protocol versions can remain compatible without those newer fields.
Migration trap
Do not copy old skill://index.json examples into a new implementation
Earlier SEP-2640 drafts and experimental implementations used a skill://index.json discovery resource and different packaging ideas. The merged conformance suite explicitly documents that skills/list and skills/get replaced that retired index shape.
This is now an important search/debugging distinction because public examples can lag the accepted contract. If a client and server disagree about Skills discovery, verify the SEP revision before adding compatibility code. Supporting a draft-era index forever can hide the real mismatch instead of fixing it.
Client integrity
A skill catalog is not permission to trust every file it names
- 1. Enumerate before loading. A client should be able to list skills without prefetching their files merely because the catalog exists.
- 2. Keep the held manifest. The skill entry is the boundary for which resource URIs belong to that skill.
- 3. Verify size and digest. Compare fetched static resources with the manifest instead of trusting transport success as integrity proof.
- 4. Check SKILL.md frontmatter. The served skill metadata should agree with the entry the client selected.
- 5. Refuse unlisted reads. A directory response or tool suggestion should not silently expand the manifest the client already approved.
- 6. Treat skill content as untrusted instructions. Verification proves consistency with the advertised artifact, not that executing its instructions is safe or authorized.
Implementation path
Use conformance as the stable target while SDK APIs catch up
The conformance project merged SEP-2640 coverage on 11 September 2026. Its server scenarios cover enumeration, manifests and optional directory reads; client scenarios test no-prefetch behavior, digest and size verification, frontmatter verification and rejection of resource reads outside the manifest.
That makes the conformance behavior a better interoperability target than copying one experimental wrapper API. If your SDK does not yet expose first-class Skills helpers, keep the compatibility layer narrow, version it explicitly, and plan to remove it once the official API you rely on ships.
Sources
Primary evidence
- SEP-2640: Skills Extension — current source-of-truth SEP pull request; checked with the
finallabel on 14 September 2026. - MCP conformance PR #330 — merged 11 September 2026; states the core-maintainer vote passed 1 September and documents the accepted enumeration, manifest and client-integrity scenarios.
- TypeScript SDK issue #2798 — open request for first-class SEP-2640 Skills APIs; notes that custom handlers can express the extension today.
- Python SDK PR #3485 — open implementation proposal for Skills protocol primitives and verification helpers.
- Go SDK PR #1238 — open opt-in SEP-2640 implementation proposal with client/server verification behavior.
Continue the implementation path
MCP 2026-07-28 migration
Check the modern result envelope, stateless transport and extension-era behavior before blaming Skills.
Verify an MCP server before connecting
Keep server identity, permissions, auth and live behavior separate from protocol-extension support.
Make an MCP server discoverable
Publish one stable identity and verify registry metadata independently from runtime capability.
Inspect zFinia machine services
Review the human service catalog before inspecting the live machine contract at api.zfinia.com.