マーケットプレイスではなく、ディレクトリ

9月25日、Anthropic は Claude のディレクトリを外部の開発者に開放しました。有料の Claude プランを使っていれば誰でも、MCP サーバーや Agent Skills のセット、またはその両方をパッケージにしてポータルから提出できます。審査を通れば、Claude ユーザーが拡張機能を探す場所に掲載されます。発表はこのパッケージをプラグインと呼び、プラグインが今や「Claude のサードパーティ拡張を作る主要な方法」だとしています。

それ以来いちばんよく見かける要約は「Anthropic がプラグインマーケットプレイスを始めた」というものです。これは2つのものを混同しています。プラグインディレクトリは審査付きの無料の配布手段です。その審査は、公開記事から受ける印象よりも、ドキュメントを読むと重いものです。そして課金の仕組みはどこにもありません。有料製品は Claude Marketplace の別の申請を通り、企業が Anthropic に確約した利用枠から購入されます。そして「審査済み」という言葉が感じさせる信頼は、多くの人が思っているより狭い範囲しかカバーしていません。

オープンソースの MCP サーバーを2つ公開しているので、提出する側の目でドキュメントを読み、両方のサーバーをルールに照らしてみました。どちらもそのままでは提出できず、その理由はディレクトリが何のために作られているかをよく表しています。以下の内容はすべて、Anthropic の公開記事、ドキュメント、MCP 仕様、そして比較する箇所では各ベンダー自身のスキルとプラグインのドキュメントに基づいています。時点は2026年10月4日です。発表とドキュメントが食い違う場合は、ドキュメントに従います。

Anthropic は実際に何を公開したのか？

2日違いで2つです。9月23日には Claude Marketplace。プラグイン、コネクタ、パートナー製品、サービスパートナーを探せるウェブサイトで、発表によれば Atlassian、Google、Microsoft、Notion、Salesforce といった企業のコネクタとプラグインがすでに「2,000 以上」あります。9月25日には、開発者にとって重要な部分が来ました。claude.ai/directory/manage にある提出ポータルで、有料プランなら誰でも使え、事前に参加するパートナープログラムもありません。

この2つはつながっていますが、同じものではありません。プラグインとコネクタについて、Claude Marketplace に独自の提出窓口はありません。提出先はディレクトリで、Claude ユーザーがアプリの Customize > Plugins で目にするのもディレクトリです。ドキュメントははっきり書いています。

If you came here from Claude Marketplace, the website where you browse plugins, connectors,
partner products, and service partners, you're in the right place: there's no separate Claude
Marketplace submission, and you submit to the directory instead

変わったのは、誰が提出できるかです。パートナーの連携がすでに載っていたディレクトリが、1つのポータルと1つの審査パイプラインを通じて、有料プランの誰からでも提出を受け付けるようになりました。

Marketplace には有料の側面もあり、見落としやすい部分です。同じ発表は「Claude を使ったエージェントや製品を販売している」人に掲載を申請するよう呼びかけ、チームは「確約した Anthropic の利用枠の一部を使ってそれを購入できる」としています。これは Anthropic と契約している企業に販売する製品のための別の申請で、プラグインの決済機能ではありません。この2つを分けて考えれば、今回の公開をめぐる混乱の大半は消えます。

プラグインとは、具体的に何か？

フォルダです。正確には、.claude-plugin/plugin.json にマニフェストがあり、その横に任意の組み合わせのコンポーネントフォルダを置いたフォルダです。2025年10月から Claude Code がプラグインに使ってきたのと同じ形式で、これが今回の公開の目立たない本題です。Claude Code のプラグインとディレクトリのプラグインは同じものです。

my-plugin/
  .claude-plugin/
    plugin.json        # name, version, description, author, license
  .mcp.json            # MCP servers the plugin brings
  skills/
    my-skill/
      SKILL.md         # an Agent Skill: name, description, instructions
  commands/            # slash commands (Markdown files)
  agents/              # subagents (Markdown files)
  hooks/
    hooks.json         # lifecycle hooks
  README.md
  LICENSE

マニフェストは小さなものです。Anthropic 自身のドキュメントにある例を挙げます。

{
  "name": "expense-reports",
  "displayName": "Expense Reports",
  "version": "1.0.0",
  "description": "File, track, and approve expense reports from a conversation, using your finance system's connector and your company's approval rules.",
  "author": { "name": "Example Corp", "url": "https://example.com" },
  "license": "MIT"
}

MCP サーバーは .mcp.json で宣言します。URL を指定するリモートサーバーか、アプリが起動するローカルコマンドのどちらかです。mcpServers のラッパーに注意してください。うっかり抜けやすい部分です。

{
  "mcpServers": {
    "expenses": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

スキルはオープンな Agent Skills 形式の、ただの SKILL.md ファイルです。名前と説明、そして説明がタスクに合ったときに Claude が読み込む指示が入っています。ドキュメントの警告の1つは、間違える人が出るはずなので、そのまま繰り返す価値があります。API キーなどのシークレットを MCP ファイルに入れてはいけません。「プラグインをインストールした人は全員、そのファイルを受け取るから」です。

ディレクトリは掲載を2種類に分けていて、この違いが以降のすべてを左右します。

スキル単体は提出の種類になりません。スキルしかないなら、バンドルに入れます。もう1つ区別しておきたい名前があります。claude-plugins-official は Anthropic 自身の Claude Code マーケットプレイスで、このポータルからの提出は受け付けていません。自前でホストする Claude Code マーケットプレイス (マーケットプレイスファイルを置いた Git リポジトリ) も、独立した配布経路として引き続き使えます。ただ、ディレクトリの審査や露出は得られません。

プラグインはどこで動くのか？

インストールできる場所すべてで動くわけではありません。claude.ai で追加したプラグインはアカウントに保存され、Cowork や Claude Code にもついてきます。ただし プラットフォームサポートのページによれば、どの部分を読み込むかは環境ごとに違います。公開記事の冒頭にあってほしかったのはこの表です。

実際の帰結はこうです。ツールがローカルプロセスなら、プラグインはそれを Claude Code と、ユーザー自身のマシン上の Cowork には届けますが、チャットには誰にも届けません。チャットのユーザーが受け取るのはスキルだけです。トップレベルに bin/ フォルダがあるものは、claude.ai と Cowork で問答無用で拒否されます。

ユーザーとしてはどうインストールし、管理するのか？

claude.ai またはデスクトップアプリの Customize > Plugins > Discover からです。ディレクトリのプラグインは Pro、Max、Team、Enterprise プランで表示されます。1つ選んで中身を確認し、Add を選びます。すると次にタスクを始めたときに Cowork に、同じアカウントでサインインして次にセッションを始めたときに Claude Code に届き、Claude Code では同期されたプラグインとして表示されます。Claude Code ユーザーは、バージョン 2.1.287 からは /plugin directory でも一覧を見られます。

ここで見落としやすい点が2つあります。プラグインを追加しても、何も接続されません。「プラグインを追加しても、アカウントにコネクタが追加されたり、何かにサインインしたりはしません」。同梱されたリモートサーバーは、プラグインの Connectors タブから別途接続します。そして更新は何の通知もなく届きます。

Get updates: plugins from a marketplace or the directory update from their source. After a new
version syncs from the source, you get it on your account automatically, with nothing to accept.

プラグインの管理では、トグルで無効にするか、メニューから削除できます。プラグインが持ち込んだコネクタは別に切断します。Team と Enterprise プランでは、メンバーに何を見せるかを Owner が決めます (管理者向けの制御)。各プラグインは Not available、Available to install、Installed by default (メンバーがオフにできる)、Required (常にオンで、メンバーは削除できない) のいずれかにできます。Anthropic のディレクトリ全体に対して Owner が設定するデフォルトのアクセスは Not available か Available to install に限られ、Owner はディレクトリをソースから完全に外すこともできます。Enterprise ではユーザーグループごとの提供設定が加わります。コマンドラインの Claude Code には独自のポリシー層があり、マネージド設定でマーケットプレイスを許可リストに入れたりブロックしたり、インストールを強制したりできます。

誰が、どうやって提出できるのか？

Pro、Max、Team、Enterprise の誰でもです。無料アカウントはできません。Team と Enterprise では Owner が提出し、Enterprise では Owner がカスタムロールを通じてほかのメンバーに Directory permission を与えられます。掲載は提出した組織のものになり、バンドルの場合はあるリポジトリのフォルダを最初に提出した組織がそれを保持します。長期的に掲載を所有すべき組織から提出してください。1つの組織が作れる提出は24時間あたり 10 件までで、保存した下書きや取り下げた提出もこの数に含まれます。

ルート1：リモート MCP サーバーをコネクタとして

ポータルに https:// URL を渡し、Connection、Tools、Listing、Use cases、Company、Authentication、Data handling、Test & launch、Compliance、Review と進みます。通るかどうかを左右する要件がいくつかあります。

• サーバーはリモートで、HTTPS で到達できる必要があります。ローカルサーバーはコネクタとして提出できず、バンドルに入れます。
• すべてのツールに title と、readOnlyHint か destructiveHint のどちらかのアノテーションが必要です。ないツールはポータルが指摘します。
• データが一通りそろったテストアカウントの認証情報を提供します。見られるのはレビュアーだけです。
• 認証は、動的クライアント登録による OAuth、Client ID Metadata Document による OAuth、Anthropic が保持するクライアント認証情報、ユーザーが自分の URL や認証情報を持ち込むカスタム接続、またはなし、のいずれかです。
• ポリシーへの同意が7項目あり、すべて必須です。ディレクトリのガイドライン、ファーストパーティ API の利用、金融取引、AI によるメディア生成、プロンプトインジェクション、会話データの収集、公開ドキュメントが対象です。
• 掲載用の素材：ドキュメントとプライバシーポリシーの URL、サポートの連絡先、アイコン、そして公開後は変更できない URL スラッグ。
• サーバーが MCP Apps を使う場合は、幅 1000 ピクセル以上の PNG スクリーンショットを3〜5枚、それぞれを生成したプロンプトと一緒に用意します。動画と GIF は受け付けません。

認証のページは、ホストされたコネクタ向けに Claude 固有の OAuth 要件をいくつか記載しています。サインインを始めるには 401 が必要です。Claude は authorization_servers メタデータの最初のエントリだけを使います。Client ID Metadata Document を選ぶのは、メタデータが client_id_metadata_document_supported: true と、トークンエンドポイントの認証方式としての none の両方を示している場合だけです。サーバーは S256 PKCE に対応している必要があり、登録すべきホスト側のリダイレクト URI は https://claude.ai/api/mcp/auth_callback です。Claude Code は代わりにループバックのコールバックでサインインするため、サーバーはポートに関係なく localhost と 127.0.0.1 に一致させる必要があります。ディスカバリー、登録、トークンの各エンドポイントには応答まで 10 秒、リフレッシュのリクエストには 30 秒が与えられます。Anthropic が保持するクライアント認証情報とカスタム接続は審査チームとの調整が必要で、静的ヘッダーによる認証は限定ベータです。マシン間の client_credentials グラントには対応していません。Anthropic のトラフィックは 160.79.104.0/21 から来るので、IP でフィルタリングしているなら知っておく価値があります。

ルート2：GitHub からのプラグインバンドル

ポータルの前に、ローカルでテストします。claude plugin validate ./my-plugin はポータルがチェックする内容の一部を検出し、claude --plugin-dir ./my-plugin で実際にプラグインを試せます。それから、気にかけるすべての環境でテストしてください。チャット、Cowork、Claude Code はそれぞれ違う部分を読み込むからです。claude.ai で GitHub アカウントを接続し (ポータルはリポジトリに push できるかを確認し、プライベートリポジトリには Claude GitHub アプリも必要です)、次の順に進みます。ポータルを開く、ソースを入力してバリデーションする (リポジトリ、任意でプラグインのパス、任意でブランチかタグ)、掲載の詳細を確認する (plugin.json と README から読み取られます)、データの扱いに関する質問に答える (個人データ、宣言していないサービスへ送るデータ、保持期間、18歳未満向けかどうか)、コンプライアンスの手順を完了する、確認して提出する。

審査中、リポジトリはプライベートのままで構いません。その代わり、ソースはスキャンのために Anthropic にアップロードされてレビュアーに見え、掲載が公開される前に public にする必要があります。複数のプラグインを持つ Claude Code マーケットプレイスのリポジトリは、1件の提出にはなりません。プラグインフォルダごとにバリデーションと提出を行い、提出後にリポジトリやフォルダは変更できません。

最初の提出のあとは、いつもどおりにリリースします。追跡しているブランチにマージすると、ディレクトリがそのコミットを取り込み (デフォルトは GitHub の Webhook、またはスケジュール)、スキャンします。公開はプラグインの公開設定に従い、デフォルトでは、後述するように自分がリクエストしてレビュアーがそのバージョンを公開します。ユーザーは、後継のバージョンが公開されるまで最後に公開されたバージョンを使い続けます。新しいバージョンがセキュリティスキャンに通らなかった場合、レビュアーがプラグインを承認するまで以降のバージョンは待たされます。plugin.json でバージョンを指定しているなら、リリースのたびに上げてください。撤退するときは、プラグインはポータルから掲載を取り下げ、コネクタはメールで依頼します。

審査は何をチェックするのか？

バンドルのバージョンはすべてスキャンされ、新しい掲載には人の目も入ります。これで雑なパッケージや欺瞞的なパッケージは見つかります。挙動を保証するものではありません。

バリデーションは Validate を押したときと、新しいコミットのたびに実行されます。結果は Blocks、Held for a reviewer、Warning、Note の4段階です。提出をブロックするものの大半は、基本的な衛生面の問題です。

• 40 語未満の README、またはライセンスがない。
• 予約された名前 (名前全体が claude、anthropic、official、plugin、mcp、test のいずれか)。有名ブランドに似た名前は、ブロックではなく保留になります。
• バージョンを固定していないパッケージを実行するランチャー。npx <package>@1.2.3 や uvx <package>==1.2.3 は通り、範囲指定や @latest は通りません。
• ドキュメントやサンプルを含め、ファイルのどこかにある本物の認証情報。
• https:// でも wss:// でもないリモート MCP の URL。
• 5 MiB を超えるファイル、または制限 (アーカイブで 50 MiB、展開後 256 MiB、10,000 エントリ) を超えるリポジトリ。

ほかのルールで先にブロックされない限り、通常は人のレビューに回される構成もあります。サイズ制限内のバイナリやコンパイル済み実行ファイル、画像やフォント以外で 256 KiB を超えるファイル、512 を超えるファイル数、ロックファイルからインストールされるパッケージ、バージョンを固定した npx や uvx のパッケージ (「パッケージ自体の依存関係はインストール時に解決される」ため)、そしてユーザーの環境にすでに設定された認証情報を読んでサーバーに送るプラグインです。保留は却下ではありません。そのバージョンが先に進む前に、人が確認するという意味です。

次がセキュリティスキャンです。Anthropic の言葉ではこうです。

The security scan looks for behavior that a plugin doesn't disclose, such as sending data
elsewhere, running hidden code, or changing Claude's permission settings.

初回の提出がスキャンに通らなければ却下され、後のバージョンが通らなければ公開できません。ドキュメントの助言はここから来ています。プラグインが実行するもの、送信するもの、取得するものはすべて README に書き、コンパイル済みやミニファイされたコードではなく読めるソースをコミットすること。スキャンが読めないものは保留になるからです。そして、README が完全でも挙動が許可されるわけではない、とも公平に付け加えています。

そして、公開記事が柔らかく書いている部分です。記事には「準備ができたら公開」とあります。ドキュメントにはこう書かれています。

A version that passes every check isn't live until it's published. When the version passes,
select Publish on the plugin's page. By default, the portal records this as a request for an
Anthropic reviewer, who then publishes the version.

自分で公開できる形は2種類あります。最初のバージョンだけレビュアーが公開し、以降は自分で公開する形と、最初のバージョンから自分で公開する形です。ドキュメントは後者を、Anthropic のレビュアーがプラグインを承認するときに適用する設定だと説明しています。自分では選べません。審査にかかる時間は「決まっていません」。ステータスは Draft、Scanning、Needs changes、In review、Approved、Published に加えて Not live yet、Delisted、Withdrawn があり、ドキュメントは Approved ではインストールできないと注意深く書いています。インストールできるのは Published だけです。

審査がカバーしないものは何か？

主に、この先のことです。プラグインバンドルはリモート MCP サーバーを URL で参照し、バンドルのスキャンはアップロードされたファイルを読みます。サーバーはコネクタとして掲載されるときに独自の審査を受けます。Community のコネクタはスクリーニングされ、Verified の審査では人が各ツールをテストします。ただしそれは、その日のサーバーのテストです。Anthropic は、それが何ではないかをはっきり書いています。

Verification means Anthropic has reviewed the connector more closely than a Community
connector. It isn't a security audit or a guarantee of how the connector will perform. The
developer operates the connector and controls its tools, which can change after review.

これを同じドキュメントにある2つの事実と並べてみてください。コネクタのツールの変更はサーバー側でデプロイされ、再提出はいりません。プラグインの更新は「自動で、承認するものもなく」ユーザーに届きます。ただし、新しいバンドルのバージョンは毎回スキャンされます。重要な挙動は開発者が管理する場所にあり、誰にも聞かれることなく審査後に変わりえます。これを Anthropic の設計の欠陥だとは思いません。リモートのサービスを一度審査する以上のことは誰にもできないからです。これは「ディレクトリに掲載されている」を「掲載された時点でチェックされた」と読む理由であり、それは「安全だ」よりも小さな主張です。審査がカバーするのもディレクトリだけです。マーケットプレイスの URL から追加したプラグインや手動でアップロードしたプラグインは、審査をまったく受けません。この一般的な話は数週間前に書きました。コネクタは信頼できない書き手である。ディレクトリはそれを変えません。

公開後に何が得られるのか？

最大 90 日分をカバーし、CSV にエクスポートできる Usage タブです。インストール数、アクティブなアカウント、リテンションを数え、インストールを環境別と流入元別 (たとえば Discover タブ) に分け、各バージョンを使うアカウントの割合を示し、スキル、コマンド、エージェント、フック、MCP サーバーのそれぞれが実際にどれくらい使われているかを教えてくれます。品質面では、Claude Code のバージョンごとの読み込みエラーと、MCP サーバーごとの呼び出し数、エラー率、レイテンシを報告します。ディレクトリのファネルもあります。掲載の表示、インストールのクリック、インストールです。数値は UTC で1日1回計算され、実際の利用データが届くまで、タブには Preview と表示されたサンプルの数値が出ます。

コネクタには別のダッシュボードがあります。ヘルスバッジ (リクエストエラーが 2% までなら Healthy、2% を超えると Worth a look、5% を超えると Degraded)、Trending タグ付きのディレクトリ内順位、30 日間のツール呼び出しとエラー率、製品別のレイテンシのパーセンタイル、上位 15 のツールです。

公開記事は「どんな検索がそこに人を導いたか」も見られると約束しています。ドキュメントの指標の一覧に検索語は含まれていないので、タブに出てくるまでは約束として扱ってください。そしてコネクタのダッシュボードは、自分の死角を率直に書いています。「ほかの MCP クライアントからあなたのサーバーへの接続と、ユーザー自身のマシンで動くローカルサーバーは Anthropic から見えず、カウントされません」。プラグインの Usage タブは、プラグイン内のローカルサーバーがカウントされるかどうかを書いていないので、カウントされると思い込まないでください。

「MCP 2.0」は実在するのか？

仕様の名前としては存在しません。MCP 仕様は日付付きのリビジョンを使い、現在のものは 2026-07-28 です。公開記事は Claude が「一般に MCP 2.0 と呼ばれる最新の MCP 仕様」に対応していると書いていますが、これは通称で、おそらく SDK から借りたものです。Claude Code のドキュメントは「MCP プロトコルリビジョン 2026-07-28 を追加した MCP TypeScript SDK 2.0」と説明しています。MCP のリビジョンは日付で識別され、「2.0」はそのどれでもありません。

リビジョン自体は実在し、破壊的変更を含みます。プロトコルレベルのセッションはなくなり、initialize のハンドシェイクもなくなりました。すべてのリクエストが _meta でプロトコルバージョンを宣言し、サーバーはバージョン、機能、識別情報を1回のリクエストで返す server/discover 呼び出しを実装する必要があり、クライアントはほかの何よりも先にそれを呼べます。正式な extensions の仕組みもあります。Roots、Sampling、Logging、Dynamic Client Registration は非推奨になりました。仕様には、ハンドシェイク前提の古いサーバーとも通信を続けられるフォールバックの手順が書かれているので、既存のサーバーがリビジョンそのものによって切り捨てられることはありません。

コネクタを作るなら知っておきたい食い違いが1つあります。Claude のコネクタ認証のドキュメントは、今も 2025-03-26、2025-06-18、2025-11-25 の認可仕様を挙げていて、Claude はリソースのサブスクリプション、サンプリング、「高度な機能やドラフト段階の機能」にまだ対応していないとしています。「最新の仕様に対応」はコア部分については正確です。最新仕様のすべてが Claude で動くという約束ではありません。

MCP Apps とは何か？

MCP サーバーがツールにインタラクティブなインターフェースを付けるための仕組みで、UI に対応していないクライアントも引き続きテキストの結果を受け取ります。公式の拡張 io.modelcontextprotocol/ui で、2026年1月から安定版です。ツールの説明に _meta.ui.resourceUri があり、ui:// リソース (スクリプトとスタイルを含む HTML ページ) を指します。ホストはそれを取得してレンダリングし (ウェブのホストは通常サンドボックス化された iframe で、Claude のモバイルはネイティブの WebView で)、postMessage でやりとりします。仕様から引用します。

The sandbox prevents your app from accessing the parent window's DOM, reading the host's
cookies or local storage, navigating the parent page, or executing scripts in the parent
context.

アプリは追加の権限を求めたり、読み込み元にできる外部オリジンを宣言したりでき、何を許可するかはホストが決めます。Claude では、まずユーザーに確認が出ます。Allow か、信頼するサーバーなら Always allow です。

ウェブ版の Claude、Claude Desktop、Claude のモバイルは MCP Apps をレンダリングします。MCP プロジェクトのクライアント一覧によれば、GitHub Copilot 付きの VS Code、Microsoft 365 Copilot、Goose、Postman などもそうです。Cowork や Claude Code がレンダリングするかどうかを書いた Claude のドキュメントは見つけられませんでした。プラグインの価値がインターフェースにあるなら、ユーザーが実際に使う環境でテストしてください。

Enterprise Managed Auth とは何か？

MCP サーバー向けのシングルサインオンで、従業員がコネクタごとに OAuth の同意画面をクリックして進まずに済むようにするものです。仕様では Enterprise-Managed Authorization と呼ばれています。ユーザーが会社の ID プロバイダー経由で Claude にサインインすると、クライアントはそのプロバイダーから署名付きの ID アサーション (ID-JAG) を取得します。次に、RFC 7523 の標準的な JWT bearer グラントを使い、サーバーのトークンエンドポイントでそのアサーションをアクセストークンに交換します。ブラウザーのリダイレクトも同意ページもなく、誰がアクセスできるかは会社の ID プロバイダーが決めます。

制限もあります。Claude では Team と Enterprise プランだけで使え、2026年8月24日から一般提供されています。リリース時点の ID プロバイダーは Okta だけです。動的クライアント登録とは併用できません。そして SSO を使っている会社なら自動で有効になるわけでもありません。管理者が設定する必要があり、あなたの認可サーバーも顧客の ID プロバイダーを信頼し、JWT bearer グラントを公開する必要があります。ユーザーが企業ではなく個人なら、この拡張は関係ありません。

1つのリポジトリですべてのエージェントに対応できるのか？

スキルはできます。パッケージングは、多少の手間をかければできます。

スキルは持ち運べます。Agent Skills はオープンな形式で、SKILL.md のフォルダは OpenAI Codex と ChatGPT、GitHub Copilot、Cursor、Gemini CLI、そのほか多数のクライアントで読み込めます。GitHub Copilot と Cursor は .claude/skills まで読みます。良いスキルを一度書けば、業界の大半で使えます。

バンドルはそうはいきません。2026年8月6日、AWS、Cursor、Microsoft、OpenAI、Vercel は、ベンダー中立のプラグイン標準である Agent Plugins 1.0.0 を公開しました。公開された運営委員会に Anthropic の名前はありません。そのマニフェストはプラグインのルートにある plugin.json で、MCP ファイルは mcp.json です。Claude ではそれぞれ .claude-plugin/plugin.json と .mcp.json です。Claude のドキュメントは Agent Plugins のレイアウトに触れていません。OpenAI は Claude 側にある程度歩み寄っています。ChatGPT のデスクトップアプリは Claude 形式の .claude-plugin/marketplace.json を読み、Codex は独自の拡張でプラグインのフックを読み込みます。ただし、そのプラグインのドキュメントは、MCP ファイルの名前を変えるだけで済ませないよう警告してもいます。ポータブルな形式は、サーバーごとにトランスポートの type を宣言するからです。

実際の答えはこうなります。1つのリポジトリで Claude と Agent Plugins のクライアントの両方に対応するには、両方のマニフェストを持ち、サーバーを同梱するなら両方の MCP ファイルも持つ必要があります。どちらの形式もスキルを skills/<name>/SKILL.md に置くので、スキル自体は共有できます。フックはポータブルなコアの外にあり、クライアント固有のままです。リポジトリに何を入れるかについて、業界は収束しました。包み方については、まだです。

自分の2つのサーバーをパッケージにしてみたら、どうなったか？

どちらもそのままでは提出できません。その理由は、自分のコードよりもディレクトリについて多くを語っています。

clipboard-mcp は、クリップボードを読み書きする Rust のサーバーです。コネクタとしては、今の形では動きません。リモートのコネクタは自分がホストするインフラで動き、Claude は Anthropic のアドレス範囲からそこに接続します。つまりホストしたクリップボードサーバーが公開するのはユーザーのクリップボードではなく、自分のサーバーのクリップボードです。既存の HTTP モードでもこれは変わりません。localhost にバインドし、認証もありません。ユーザーのクリップボードをコネクタに届けるには、ユーザーのマシン上のエージェントと、そこへの安全なリレーという新しいものが必要です。一般的なルールとして、ユーザー自身のマシンへのアクセスに価値があるツールは、URL だけではコネクタになれません。

バンドルとしては、バイナリのルールにぶつかります。手元のリリースビルドは約 7.9 MB で、ファイルあたり 5 MiB の制限を超えるので、コミットするとバリデーションで止まります。制限内のコンパイル済み実行ファイルでも、レビュアー待ちで保留になります。トップレベルの bin/ に置くと、claude.ai と Cowork がプラグインを拒否します。.mcp.json からダウンロード可能なバンドルを指すとブロックされます。単体のデスクトップ拡張として掲載する道も、今はもうありません。プラグイン内にコミットした .mcpb は保留になり、このサイズではそもそもファイルの制限で先に止まります。別途インストールしたバイナリを必須にする方法もありますが、コマンドがプラグイン内のファイルではないので保留になり、ワンクリックでのインストールもできなくなります。どの方法でも、動くのは Claude Code とローカルの Cowork だけです。チャットはローカルサーバーを無視するからです。

agent-recall は、ローカルの SQLite ファイルを使う Python のメモリサーバーです。コネクタにするには、今は持っていないリモートのトランスポートとアクセス制御の設計が必要です。現在は stdio のみで、意図的にローカルファーストにしています。バンドルとしては可能性はあるものの、すっきりとはいきません。サーバーとフックは事前の pip install に依存していて、チェックリストはフックやサーバーが使うファイルをすべてプラグインフォルダ内に置くよう求めています。バージョンを固定した uvx のランチャーは固定のルールを通りますが、依存関係がインストール時に解決されるので、やはり審査待ちで保留になります。そしてパッケージングは半分にすぎません。自発的に記憶を保存するメモリサーバーは、会話データの収集に関するディレクトリのポリシーの制限と折り合いをつける必要があり、それはこうしたリポジトリの監査では決着がつきません。

この作業で、どのチェックリストでも最初に置きたい落とし穴も見えました。MCP サーバーがプラグインから来る場合、Claude Code はそのツールを mcp__plugin_<plugin-name>_<server-name>__<tool-name> という名前空間に入れます。ドキュメントははっきり書いています。

A hook matcher written against the bare server key, such as `mcp__database-tools__.*`, never
fires for a plugin-bundled server.

自分のプラグインは変わったケースです。フックは同梱していますがサーバーは同梱しておらず、.mcp.json は空で、README ではユーザー自身に memory というキーでサーバーを追加してもらっています。なので今のところ、素のマッチャーで正しく動きます。サーバーをプラグインに同梱した瞬間、そのマッチャーはエラーもなく発火しなくなり、その裏のハンドラーも止まります。ハンドラーも素のツール名でフィルタリングしているからです。記憶が静かに書き込まれなくなるまで、誰も気づかないでしょう。MCP のツール名をキーにしたフックがあり、サーバーをプラグインに移すなら、マッチャーと、名前をチェックしているコードをすべて書き直してください。

両方に共通するパターンはこうです。ディレクトリは、ちゃんとした認証を持つリモートサーバーと、その使い方を Claude に教えるスキルのために作られています。ローカルのツールは Claude Code とローカルの Cowork には届きます。そしてユーザーを守るルール (読めるソース、インストール時にレビュアーの見えないところで何も解決されないこと、すべてのファイルがフォルダ内にあること) こそが、ローカルのツールを人のレビュアーへ回すルールです。

誰が、どう使うべきか？

まともな OAuth 構成のリモートサービスを運用しているなら、ドキュメント自身の推奨が正解です。2回提出してください。サーバーを MCP コネクタとして、次にその使い方を Claude に教えるスキルを入れたプラグインバンドルとして提出し、バンドルの .mcp.json は同じ URL を指すようにします。そうすれば両方を入れた人にもツールは1セットだけ見えます。掲載、審査、Anthropic が Verified に引き上げてくれる可能性、アナリティクス、そして Team と Enterprise では、あなたのプラグインをデフォルトにできる管理者が手に入ります。

ツールがローカルなら、プラグインで Claude Code ユーザーに届け、すべてをプラグインフォルダ内に読めるソースで置き、チャットのユーザーにはスキルしか届かないと割り切ってください。

プラグインを売りたいと思っていたなら、ディレクトリはそれを代わりにやってはくれません。価格設定、収益分配、支払いの話は、公開記事、ディレクトリのドキュメント、Directory Terms、Directory Policy のどこにもありません。ポリシーはさらに踏み込んでいて、お金を動かしたり金融取引を実行したりするソフトウェアはサポート対象外のユースケースで、広告やスポンサーコンテンツを配信するソフトウェアも同じです。ビジネスモデルは、これまでどおり自分のサーバーと自分のアカウントの裏側に置くことになります。企業に製品まるごとを売るのなら、見るべき入り口は Marketplace の別の有料申請です。

結局、これは何なのか？

プラグインについて言えば、マーケットプレイスではなくディレクトリです。配布と審査を担い、販売はほかの場所で行います。Claude Code のプラグイン形式をそのままディレクトリの形式にしたのは賢い判断でした。すでに Claude Code のプラグインを作っているなら、ほとんど準備はできています。

審査はアップロードされたものを読み、コネクタの審査はその日のサーバーをテストします。その後サーバーが何をするか、次の通知なしの更新が何をするかは、開発者とユーザーの間の問題として残ります。掲載のバッジはそのつもりで読んでください。そして公開するなら、README を契約書のつもりで書いてください。スキャンにとっては実際にそうだからです。ただし、挙動を説明してもそれが許可されるわけではない、というチェックリスト自身の警告も忘れずに。自分の2つのサーバーにとって、次の一歩は提出ではありません。パッケージングを直し、それからポリシーの問いに正直に答えることです。