【ITニュース解説】MCP Server Icon: Where to Find and Use It — What Listing 24 MCP Servers Taught Us

システムエンジニアを目指す初心者の皆さんにとって、プログラムのコードやシステム設計は主要な学習テーマだろう。しかし、今回取り上げる「MCPサーバーアイコン」の話題は、実はシステムを開発し公開する上で非常に重要な側面を教えてくれる。アイコンは単なるデザイン要素ではなく、公開するシステムの「信頼性」や「正確性」に直結するという話だ。

ScriptMasterLabsという組織は、Model Context Protocol (MCP) に対応する24台ものサーバーを運用しており、合計182種類のツールを提供している。これらを公式のMCPレジストリやGlama、Smitheryといった様々なディレクトリに登録しているが、この大規模な運用を通して彼らは一つの重要な事実に気づいた。それは、ほとんどのディレクトリやレジストリが、実際にあなたのサーバーを実行して内容を確認するわけではないということだ。彼らは、あなたが公開したパッケージやリポジトリ、あるいはレジストリの記録を読み取って、その情報に基づいてサーバーのリスティング（一覧表示）を作成している。そのため、あなたが公開するソースコードにどのようなアイコンやツールリスト、メタデータ（付加情報）が組み込まれているか、それこそが世界中のユーザーが目にする情報になる。もしアイコンの指定が間違っていたり、情報が古かったりすると、ディレクトリ上では「サイレントに」、つまりエラーメッセージも出さずに表示がおかしくなってしまうのだ。24台ものサーバーを運用しているScriptMasterLabsにとって、これは大きな問題であり、正確なリスティングのためにはアイコンの管理が不可欠だった。

では、具体的にどうすれば良いのか。まず、公式のMCPサーバーアイコンを入手するには、どこかから勝手に画像を拾ってくるのではなく、Model Context Protocolの公式GitHub組織から直接ダウンロードする必要がある。ここには、READMEファイルやレジストリのリスティング、パッケージのメタデータに使うための公式のブランドアセット（ロゴファイル）が用意されている。SVG形式かPNG形式でダウンロードし、それを自身のプロジェクトのリポジトリにコミット（保存）し、ローカルで参照するのが正しい方法だ。

なぜわざわざダウンロードしてローカルで管理する必要があるのだろうか。それは、ディレクトリサイトからアイコン画像をスクレイピング（ウェブサイトから自動的に情報を収集すること）したり、アイコンのURLを直接リンク（ホットリンク）したりする行為が危険だからだ。ディレクトリサイトは、自身のUIに合わせてロゴを圧縮したり、トリミングしたり、再エンコード（再変換）したりすることが多い。そのため、スクレイピングした画像は、背景が焼かれた状態のぼやけたPNG画像になってしまう可能性がある。また、ホットリンクされたURLは、予告なく変更されることがあり、その結果、あなたのREADMEファイルに「壊れた画像」が表示され続けるという事態も起こりうる。ScriptMasterLabsでは、24台のサーバーすべてで、画像をローカルにコミットし、実行時に外部から取得しない方法を採用している。これにより、一貫した高品質な表示を保っているのだ。

アイコンのフォーマットとサイズについても知っておくべきことがある。マスターファイルとしてはSVG形式を扱うのが最善だ。SVGはベクター画像であるため、16ピクセルの小さなファビコンから、幅いっぱいのバナーまで、一つのソースからどんなサイズにも劣化なくきれいに拡大縮小できる。ベクター対応のレジストリでは、ライトテーマでもダークテーマでも鮮明に表示される。たとえ直接SVGを公開しない場合でも、リポジトリにSVGを保持しておけば、エクスポートされるすべてのPNG画像が同じ形状に基づいていることを保証できる。

しかし、SVGが使えない場面もある。特定のパッケージカード、一部のディレクトリのリスティング、メールクライアント、古いMarkdownレンダラーなどがその例だ。このような場合は、固定サイズのPNG画像をエクスポートして利用する。推奨されるPNGのサイズと用途は以下の通りだ。16x16ピクセルはブラウザのタブや狭いUIの行に、32x32ピクセルはブックマークや小さなバッジに、128x128ピクセルはレジストリカードやREADMEのインライン表示に、そして512x512ピクセルはオープングラフ（SNSで共有される際に表示される画像）やストアのリスティングで使用する。特に16ピクセルのアイコンは、サーバーアイコンの品質が試されるサイズだ。このサイズでアイコンが「つぶれて」見えないか、白い背景、暗いエディタテーマ、中間のグレーのレジストリカード上で確認することが重要だ。もしアイコンが判別できないほどになってしまう場合は、図形を減らしたり、線の太さを太くしたり、細かい文字をなくしたりして、デザインを簡素化する必要がある。数十ものリスティングを管理する際には、このテストは単なる「見た目を良くする」ためではなく、すべてのサーバーが同じブランドとして認識されるか、それともただの灰色のシミの集まりに見えるかの決定的な違いを生む。

また、Webアプリケーションでは、ユーザーがライトテーマとダークテーマを切り替えることが一般的だ。MCPのブランドキットには、ライトとダークの両方のバリアント（派生バージョン）が用意されている。ガイドラインはシンプルで、背景色に対して十分なコントラストがあるバージョンを使用することだ。ドキュメントページには暗い背景に明るいアイコン、ターミナル画面のスクリーンショットやダークモードのレジストリには明るい背景に暗いアイコンといった具合に、表示される文脈（コンテキスト）ごとに適切な方を選ぶ。

GitHubのREADMEファイルは、あなたが指定したCSSを直接実行するわけではないが、<picture>タグのメディアクエリは尊重してくれる。そのため、ライトとダーク両方のSVGファイルをホストし、ブラウザがユーザーの設定に基づいて適切な方を選択するように設定できる。この方法はScriptMasterLabsが採用しているパターンだ。その理由は、前述の通り、レジストリやディレクトリがそれぞれ独自の背景でリスティングをレンダリングし、それらが常に同じテーマを使っているとは限らないからだ。もしライトテーマのアイコンを固定してしまうと、ダークテーマのレジストリでは「暗い背景に暗いマーク」が表示され、あなたのサーバーアイコンは背景に溶け込んで見えなくなってしまう。この<picture>ブロックを記述するのにかかる時間はわずかだが、これによって、ブラウザがレンダリング時に適切なアイコンを解決してくれるため、コミット時にあなたがどちらのテーマのアイコンを使うか推測する必要がなくなる。自身のドキュメントサイトでは、CSSを使って同様の制御が可能だ。公開前には、GitHubの設定でライトモードとダークモードの両方を切り替えてREADMEの表示を確認し、さらに実際のレジストリUIでもプレビューすることが大切だ。これが、ユーザーがあなたのサーバーを初めて目にする場所になるからだ。

MCPのブランドガイドラインも理解しておく必要がある。アイコンは固定されたマークとして扱い、縦横比を変えたり、回転させたり、色を変えたり、影をつけたりしてはならない。アイコンの周囲には、マーク内の文字の高さと少なくとも同じくらいのクリアスペース（余白）を確保し、その余白の中にテキストやバッジ、自身のロゴなどを配置してはならない。このアイコンはMCPプロトコル自体を示すものであり、あなたの製品を示すものではないということを忘れてはいけない。自身の製品ロゴと並べて使用する際は、同じ高さ（例えば24ピクセル）に揃え、同じ角丸の半径にし、アイコンの高さの半分以上のクリアスペースを間に設けるのが望ましい。「公式」や「認定」といった言葉を使ったり、アイコンを製品名のように扱ったりするなど、MCPチームからの推奨や承認を受けているかのように誤解させる表現は避けるべきだ。「built on MCP」や「MCP-compatible」（MCP互換）といった表現に留めるのが適切だ。

今回の記事で最も重要な教訓の一つが、「アイコンやツールリストなどの静的参照情報をパッケージに焼き付ける（組み込む）」という考え方だ。ディレクトリにとって、「記録」そのものが製品として扱われるからだ。ScriptMasterLabsの経験から、以下のような事実が明らかになった。レジストリの記録は、実際のライブサーバーの内容と乖離（かいり）することがある。例えば、ScriptMasterLabsの402Proofサーバーはレジストリでは11ツールと記載されていたが、実際には12ツールを提供していた。そこで、真の12ツール構成でバージョン1.0.2として再公開した。このような修正は、レジストリAPIからの再読み込みによって確認された。つまり、コミットしただけでは証明にならず、実際に読み込み直して確認することが必要不可欠なのだ。

一部のディレクトリでは、一度登録した情報をその場で修正できない場合もある。Smitheryというディレクトリでは、ScriptMasterLabsのサーバーのツール数が古いまま表示されていたが、サイト内での更新機能が削除されており、修正するためにはサポートに連絡して対応を依頼するしかなかったという。このように、情報が編集できない場所では、パッケージとレジストリの記録が唯一あなたがコントロールできる情報源となるため、それらが正確であることはさらに重要だ。だからこそ、定期的に情報を確認し、更新することが求められる。ScriptMasterLabsは、Glamaに登録しているVerdict ProtocolやOMNIGATEのリスティングを定期的に確認し、「Healthy」（健全）と表示されることを確認している。リスティング情報は時間とともに「腐敗」してしまうため、まるでサーバーのエンドポイントをプローブ（探査）するように、定期的に再確認する必要があるのだ。

そして、最終的には「自身がコントロールできるハブ（拠点）を所有する」ことが重要だと述べている。ScriptMasterLabsの全24サーバーは、エンドポイントやインストールコマンドと共に、彼ら自身のWebサイト（scriptmasterlabs.com/muse-connect）に集約されている。これは、ディレクトリが「借り物の土地」であるのに対し、彼らのWebサイトは「自分たちの土地」だからだ。静的資産が公開されたソースに含まれていなかったために、表示が誤ってしまい、3日間で4回のリリース修正を余儀なくされたという苦い経験から、この教訓を学んだという。最初から必要な情報をパッケージに組み込んでおけば、新しいサービスが公開されたときに、最初からどこでも正しく表示されるようになる。

最後に、MCPアイコンの商用利用についてだが、基本的には自由だ。MCPロゴはプロジェクトのマークであり、あなたのサーバーがModel Context Protocolに対応していることを示す目的であれば、ScriptMasterLabsの有料サーバーのように、商用サービスでも問題なく利用できる。ただし、公式の認証や承認を受けているかのように示唆する表現、例えば「公式MCPサーバー」という言葉を使ったり、アイコンを製品名のように扱ったりすることは禁止されている。アイコンはREADMEのバッジ、レジストリのリスティング、パッケージのメタデータでの利用に限定し、パッケージのホームページやリポジトリのフィールドには実際のURLを指定して、ディレクトリが正しく解決できるようにしておく必要がある。オープンソースであるか否かは関係なく、アイコンが「プロトコル互換性」を示していることが重要だ。

まとめると、MCPアイコンは公式のGitHub組織からダウンロードし、SVGをマスターとして、16、32、128、512ピクセルのPNGも用意する。ライトとダーク両方のテーマに対応できるよう、<picture>タグを使って表示を切り替える。互換性を示す場合は「built on MCP」といった表現を使い、「公式」という言葉は避ける。そして最も重要なのは、アイコンやツールリストなどの静的情報をパッケージに組み込み、定期的にリスティング情報が正確であることを確認することだ。大規模なシステムを運用する上では、ディレクトリに表示される「記録」こそが、世界に公開されるあなたの「製品」そのものだからである。