MCPサーバーが増えるほど、「このサーバー専用の手順書（Agent Skills）をどう配る」かが課題になります。GitHubリポジトリへの直置き、マーケットプレイス経由の配布はすでに記事で扱いましたが、MCPの標準拡張としてスキルを配信する仕組みが2026年に確定しました。
Skills over MCPとは何か
Skills over MCPはSEP-2640で確定したMCP公式拡張で、既存のResourcesプリミティブ上でSKILL.mdを配信します。
SEP-2133が定めた拡張ガバナンスの枠組みに沿って登録された公式拡張の一つがio.modelcontextprotocol/skillsです。SEP-2640としてStatus: Finalに達し、ext-skillsリポジトリで仕様が公開されています。既存のMCPプロトコルに新しいメッセージ型を追加するのではなく、skills/list・skills/getという2つのメソッドと、既存のresources/readを組み合わせて、SKILL.mdと付随ファイルを配信する設計です。サーバーはserver/discoverのレスポンスでresourcescapabilityとextensions内のio.modelcontextprotocol/skillsを宣言した場合のみ、この拡張に対応しているとみなされます。
skills/listとskills/getはどう動くか
skills/listはSKILL.mdと付随ファイルのURI・SHA-256ダイジェスト・バイトサイズを含む完全なマニフェストを返します。
クライアントはskills/listでページング対応の一覧を取得し、各エントリに含まれるfrontmatter（name・description等）とファイルマニフェストからスキルを選別します。URIを直接知っている場合はskills/getで個別取得でき、一覧に出てこない非公開スキルも読み込めます。実際のSKILL.md本文やreferences/配下のファイルはresources/readで取得する設計で、MCPの既存プリミティブを再利用する点がこの拡張の特徴です。ディレクトリ一覧が必要ならresources/directory/readを使いますが、これはdirectoryRead: trueを宣言したサーバーのみが対応します。
整合性検証と承認はどう設計すべきか
ホストはSKILL.md読込時にSHA-256ダイジェスト・バイトサイズ・frontmatterをマニフェストと照合する必要があります。
仕様はホスト側の実装要件を細かく定めています。スキルの承認はマニフェスト全体（ファイルURIとダイジェストの組）に対して発行され、1ファイルでも変更・追加・削除があれば承認は失効し、再承認が必要です。読み込んだコンテンツは発信元サーバーのラベルを付けて保持し、別サーバーのリソースを読むクロスサーバー読み込みは明示的な個別承認を要します。サーバー1件あたりはSKILL.mdを含めて512ファイル・16MiB以内に収めることが推奨され、ホストはこの上限まで対応する必要があります。スキル本体はエージェントガバナンス上「信頼できない入力」として扱い、allowed-toolsのような権限付与は個別承認を経由させます。
既存のスキル配布経路とどう使い分けるか
GitHubの自動読込・マーケットプレイス配布・Skills over MCPは、信頼境界を設計する層が異なる3つの経路です。
Managed AgentsのGitHub自動読込はリポジトリマウント時にレビューなしで読み込む設計で、マーケットプレイス経由の配布は審査プロセスが信頼の起点でした。Skills over MCPはこの両者と異なり、プロトコルレベルでサーバーのcapabilities宣言とホスト側の検証・承認フックを強制する点が差分です。MCPサーバーを本番で運用するプラットフォームエンジニアリングの観点では、どの経路で入ってきたスキルも最終的にはこの検証ロジックを通す設計にしておくと、配布経路が増えても信頼境界を一本化できます。
参考
まとめ
Skills over MCPは、MCPの既存プリミティブを使ってAgent Skillsを配信する公式拡張として確定しました。重要なのは新しいメッセージの追加ではなく、ダイジェスト検証・マニフェスト単位の承認・クロスサーバー制限という、ホスト側に課される検証義務の設計です。自社のMCPホストやエージェント基盤を運用している場合、スキルの入り口が増える前に、この検証ロジックを一箇所に集約しておくことをお勧めします。KuuではRDEとして、こうしたプロトコル拡張への追従と信頼境界の設計を支援しています。