The wire · review · first seen Oct 24, 01:28 UTC

Model Context Protocol TypeScript SDK adds skills support

Version 2.4.0 shipped skills support for MCP servers and clients. Builders can test a publish-and-read workflow today, but the server attachment API is experimental.

L0 · primary1 source4 claims checked4 min read

What shipped

Servers can publish a folder of skills using loadSkills(folder) and skills.attach(server). These are the two server-side entry points named in the release. For a developer with a folder to expose, they provide a concrete place to begin an integration. The supplied excerpt does not describe the folder layout or the contents required for each skill, so those details should not be inferred from the two calls alone. [1]

Clients can list, read and verify skills with SkillsClient. Those are separate operations to exercise: first find what the server publishes, then read a selected skill, then invoke verification. The release establishes that these operations shipped. It does not say what decision an application should make after verification, so a client developer still needs to define that behavior for their own workflow. [1]

The skills support works on 2025-11-25 and 2026-07-28 connections. Those are the two connection versions the release names; it makes no claim here about others. The release also calls skills.attach experimental and says it may change in a minor release. Skills support has shipped, but the stated stability warning applies to the server attachment call now, not merely to a possible future feature. [1][2]

Why it matters if you build

A builder who controls both server and client can run a bounded end-to-end trial. Publish a folder through the named server calls, then use SkillsClient to list, read and verify a skill. That tests the workflow the release actually describes. It is a more useful first decision point than assuming the release also defines distribution, review or trust policies, none of which are established by these claims. [1][2]

The source does not quantify adoption cost. It names entry points, but gives no skills-specific migration procedure, performance figure or operating limit in the supplied excerpt. A team should therefore measure the work in its own server and client rather than assign an effort estimate from this release note. Test the folder you intend to publish and the client behavior you intend to use; keep conclusions limited to what that test shows. [1][2]

The clearest maintenance risk is at skills.attach(server). Production code that depends on its present shape may need revision if that experimental API changes in a minor release. Isolating that call is a reasonable way to make a trial easier to revisit. Testing on both named connection versions can check the release’s compatibility statement for your integration, but it does not cancel the attachment API’s stability warning. [1][2][3]

How to try it today

1. Choose a folder of skills for a test server to publish.
2. Call loadSkills(folder), then skills.attach(server).
3. Use SkillsClient to list the published skills.
4. Read one listed skill and invoke verification with SkillsClient.
5. If relevant to your integration, test the path on 2025-11-25 and 2026-07-28 connections.
6. Keep the experimental skills.attach call easy to revise.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Servers can publish a folder of skills with loadSkills(folder) and skills.attach(server).

   per GitHub releases · modelcontextprotocol/typescript-sdk (L0); contradicted by GitHub releases · modelcontextprotocol/typescript-sdk (L0)
2. shipped L0 · primary

   Clients can list, read and verify skills with SkillsClient.

   per GitHub releases · modelcontextprotocol/typescript-sdk (L0); contradicted by GitHub releases · modelcontextprotocol/typescript-sdk (L0)
3. shipped L0 · primary

   Skills support works on 2025-11-25 and 2026-07-28 connections.

   per GitHub releases · modelcontextprotocol/typescript-sdk (L0); contradicted by GitHub releases · modelcontextprotocol/typescript-sdk (L0)
4. shipped L0 · primary

   skills.attach is experimental and may change in a minor release.

   per GitHub releases · modelcontextprotocol/typescript-sdk (L0); contradicted by GitHub releases · modelcontextprotocol/typescript-sdk (L0)

What is not confirmed

The supplied excerpt does not establish a required folder layout, verification criteria, or what a client should do when verification fails. It identifies server publishing and client operations without specifying those application decisions. Do not treat the presence of a verify operation as a complete trust policy. [1][2]

No skills-specific size limit, performance result, or guarantee of skills.attach stability is stated here. The release explicitly says that attachment may change in a minor release. It confirms support on two named connection versions, not on every possible connection version. [1][2]

Who should act, who should wait

Act now if you own enough of the server and client to test the named publish, list, read and verify path, and you can accommodate a possible change to skills.attach. The shipped operations and two stated connection versions give you a focused trial. Base a wider rollout decision on the behavior you observe, not on capabilities the release does not claim. [1][2][3][4]

Wait before making this attachment call a hard-to-change dependency if your deployment requires a stable API or a specified verification policy. That is not a finding that the feature cannot meet those needs. The supplied material does not establish the policy, and it expressly marks the attachment API as experimental. [1][2]

Sources

• @modelcontextprotocol/server-legacy@2.4.0 — GitHub releases · modelcontextprotocol/typescript-sdk L0 · primary
• 2.4.0 — GitHub releases · modelcontextprotocol/typescript-sdk L0 · primary