MCPサーバーやAIクライアント内アプリのようなエージェント向けサービスでは、利用者がWeb検索やSNS投稿からLPへ来る経路だけでなく、クライアントのディレクトリ閲覧、自然言語プロンプトへの会話内提案、既存プラグインからのインストールが主要な発見経路になる。したがって、ツール名・説明・入力スキーマ・UIリソース説明は実装詳細ではなく獲得面のコピーとして扱う。

判断基準

サービス名や内部概念を説明するより、利用者が実際に言う行動をツール説明に書く。「目標管理ツール」のようなカテゴリ語だけでなく、「パートナーと今週話す議題を整理したいときに使う」のように、困りごとと期待する結果が読める記述にする。広すぎる説明は無関係な会話で選択され、狭すぎる内部語は候補に上がらない。

公開経路は、対象クライアントのプラグインディレクトリと、公式または下流マーケットプレイスが参照するMCPレジストリの両方を使う。リリース時のレジストリ更新はCIへ組み込み、公開バージョンとメタデータの不一致を防ぐ。ただし登録自体を需要の証拠とはみなさない。

検証

想定利用者の自然な依頼をgolden promptとして、呼ばれるべきプロンプト、呼ばれるべきでないプロンプト、別ツールと競合するプロンプトに分ける。開発者モード等で選択結果を繰り返し確認し、precision（無関係な会話で出ない）とrecall（必要な会話で出る）を記録する。

事業側は、ディレクトリ表示やインストール数ではなく、接続完了、最初の価値ある操作、再利用、招待・共有、課金の転換を測る。発見されても最初の価値まで進まない場合、宣伝量を増やす前に認証・初期データ・説明の摩擦を直す。