# MCPサーバーカードの仕組みと公開時の設計判断 > MCPサーバーカード（SEP-2127）は接続前に取得できる公開メタデータです。自社MCPサーバーを公開する中小企業が載せる項目と載せない項目を整理します。 - Canonical: https://kuucorp.com/blog/mcp-server-card-discovery-metadata-smb/ - Date: 2026-10-10 - Last modified: 2026-10-10 - Publisher: Kuu株式会社 (https://kuucorp.com) --- 自社の予約システムや商品DBをMCPサーバーとして公開したものの、取引先から「どのURLに、どのプロトコルバージョンで接続すればよいか」という問い合わせが毎回届く。そんな運用負荷を減らすために設計されたのが、MCPサーバーカード（Server Card）です。 一方で、カードに何を書くかを誤ると、公開してはいけない情報まで外に出てしまいます。本記事では、MCP公式のSEP-2127をもとに、カードの役割と、中小企業が公開側として決めておくべき設計判断を整理します。 ## MCPサーバーカードとは何か > MCPサーバーカードは、接続前に取得できるサーバーの公開メタデータ文書です。2026年1月提案のSEP-2127で、拡張（Extensions Track）として最終承認されました。 [MCP（Model Context Protocol）](/glossary/mcp/)の従来の探索は、接続先が分かって初めて使える実行時のやり取りでした。サーバーカードはこの手前を補います。クライアントやレジストリが、接続を開く前に名前・バージョン・説明、リモートの接続先URL、対応するプロトコルバージョンを読み取れます。 SEP-2127が挙げる効果は3つです。 - IDE拡張などが、ドメインを指定するだけで自動設定できる - レジストリやクライアントがドメインを巡回して、MCPサーバーを索引化できる - 各エンドポイントに接続せずに、サーバー情報を表示できる サーバーカードは任意の拡張です。カードを公開しないサーバーも、従来どおり動作します。 ## どこに置き、どう見つけてもらうのか > カードの推奨配置は、Streamable HTTPのURL末尾に「/server-card」を付けた場所です。ドメイン単位の発見にはAI Catalogを使います。 SEP-2127によれば、カードは予約されていない任意のURIに置けます。そのうえで、`/server-card` が推奨の配置先として予約されています。ドメイン全体の探索は、`/.well-known/ai-catalog.json` に置くAI Catalogがカードへのリンクを持つ形で担います。`.well-known` は [RFC 8615](https://datatracker.ietf.org/doc/html/rfc8615) で定められた、サービス発見の標準的な置き場所です。 配信上の細かい規定（メディアタイプ、CORS、キャッシュ）は、拡張リポジトリの `docs/discovery.md` が正本です。SEP本文は最終化時点の記録にすぎないため、実装時は必ず現行の拡張仕様を確認してください。 ## カードに載せる情報と載せない情報は何か > カードに載せるのは名前・バージョン・接続先・対応バージョンまでです。ツールやリソースの一覧は、仕様上あえて含まれません。 カードが持つのは、`name` / `version` / `description` と、任意の `title` / `icons` / `repository` / `websiteUrl`、リモートの接続エンドポイント、対応プロトコルバージョン、名前空間付きの `_meta` です。 ツール・リソース・プロンプトの定義は意図的に除外されています。理由はSEPに明記されています。サーバーが公開する内容は、認証ユーザーや設定、デプロイ状態で変わります。静的な文書では正確に表せず、クライアントが古い情報を信じる危険が生じるためです。 したがって、権限や安全性の判断をカードに頼ってはいけません。実際のツール一覧は、接続後に `tools/list` などで認証済みの身元とともに確認します。 SEPはさらに、カードは公開文書であるため、認証情報、社内ネットワーク構成、独自ロジック、利用者固有のデータを含めてはならないとしています。 ## 中小企業が公開側で決めておくことは何か > 公開側で決めるのは、カードの要否、記載項目のレビュー、更新責任者の3点です。まず自社の公開範囲を棚卸しします。 着手手順は次のとおりです。 1. 公開するMCPサーバーを洗い出し、取引先限定か一般公開かを分ける。限定公開のサーバーにカードは不要な場合が多い 2. 記載項目をレビューする。内部ホスト名、社内ドメインのURL、担当者名が混ざっていないかを確認する 3. 更新責任者を決める。バージョンやURLが変わったらカードも更新する 4. 発見用エンドポイントはレート制限をかける。SEPもDoS対策として推奨している また、カードとライブ探索（`server/discover`）の値が食い違う場合、クライアントは後者を優先するべきだとされています。カードは参考情報という位置づけを前提に運用してください。大規模な組織向けの統制設計は[エンタープライズ向けのMCPレジストリ設計](/blog/mcp-registry-namespace-verification-enterprise-trust/)も参照してください。 ## 利用側ではカードをどう扱うべきか > 取得したカードは「入口の案内」にすぎません。接続前の信頼判断には使わず、導入審査は従来の確認手順で行います。 外部のMCPサーバーを導入する側では、カードで接続先を自動設定できても、それは信頼の証明ではありません。カードはHTTPSで取得し、証明書検証を有効にします。導入可否は[導入前の5つの確認観点](/blog/mcp-server-vetting-checklist-smb/)に沿って、出所・権限範囲・実行場所を確認します。SEPも、カードが侵害された場合の影響は主に発見性にとどまるとしつつ、クライアントが実行時のメタデータで検証することを前提にしています。 ## 参考 - [SEP-2127: MCP Server Cards - HTTP Server Discovery](https://modelcontextprotocol.io/seps/2127-mcp-server-cards.md) - [experimental-ext-server-card（拡張リポジトリ）](https://github.com/modelcontextprotocol/experimental-ext-server-card) - [RFC 8615: Well-Known URIs](https://datatracker.ietf.org/doc/html/rfc8615) ## まとめ MCPサーバーカードは、接続前の発見を助ける任意の公開メタデータです。載せるのは接続情報まで、ツール一覧や認証情報は載せない。この線引きが設計の核心です。 自社MCPサーバーの公開範囲の棚卸しや、導入審査の手順化は、Kuu株式会社の[AI運用管理サービス](https://kuucorp.com/services/ai-ops/)でご支援しています。お気軽にご相談ください。