Kafka・RabbitMQ・NATSのMCPは本家不在 — 信頼できる実装の見分け方
Kafka・RabbitMQ・NATS向けMCPサーバーはいずれもApache・Broadcom・NATS本体からは提供されていません。star数・更新頻度・ライセンス・開発元という4つの軸で信頼度を見分けます。
メッセージング系MCPはプロトコル本体からの提供が無い
Kafka・RabbitMQ・NATSのMCPサーバーを探すと、いずれもプロトコル本体の開発元からは実装が出ていません。Apache Software FoundationはKafka向けMCPを公開していません。VMwareを買収したBroadcomも同様です。NATSを開発するNATS.io(Synadia)も出していません。GitHub組織検索で org:rabbitmq mcp や org:nats-io mcp を実行しても該当リポジトリは0件です。一方でKafkaだけは事情が異なり、org:confluentinc mcp で検索すると mcp-confluent を含む4件がヒットします。この違いが生む信頼度の差は、下の比較表とKafkaの節で具体的な数値を挙げながら見ていきます。
3製品とも読者が使うMCPサーバーは、個人開発者かクラウドベンダーが独自に公開した非公式実装になります。ここで問題になるのが信頼度の差です。個人が週末に書いて放置したリポジトリと、クラウドベンダーが自社の商用サービスの一部として保守しているリポジトリでは、同じ「非公式」でも中身がまったく違います。
GitHubで「kafka mcp server」を検索すると98件がヒットします。「rabbitmq mcp」は76件、「nats mcp server」は32件です。件数そのものはノイズも含みますが、Kafka向けの実装がもっとも層が厚く、NATS向けは選択肢が少ないという傾向は、実際に使う実装を選ぶ段階でも影響します。選択肢が少ないほど、1つの実装の更新停止がそのまま「使える実装が無くなる」事態に直結しやすくなります。
信頼度は4つの軸で見分けられる
本家の実装が無い前提で、これらのMCPサーバーを選ぶときに確認すべき軸は4つです。
- star数: 利用者数の目安。ただし単独では判断材料にならない(下記参照)
- 最終更新日: 直近のコミット・pushがいつか。半年以上止まっているリポジトリは、MCP仕様や対象プロダクトのAPI変更に追随できていない可能性がある
- ライセンスの有無:
LICENSEファイルが無いリポジトリは、商用利用時の権利関係が不明確なまま - 開発元の性格: 個人か、その技術を商用サービスとして提供する企業(ベンダー)か。ベンダー製は自社サービスの継続を前提に保守されやすく、突然のアーカイブ化も起きにくい
3製品を実装ごとに比較する
3製品それぞれの代表的な実装を、この4軸で比較すると差がはっきり出ます。
| 製品 | 代表的な実装 | star数 | ライセンス | 最終push |
|---|---|---|---|---|
| Kafka | 代表的な実装confluentinc/mcp-confluent | star数167 | ライセンスMIT | 最終push2026年9月12日 |
| Kafka | 代表的な実装tuannvm/kafka-mcp-server | star数54 | ライセンスなし | 最終push2026年3月9日 |
| RabbitMQ | 代表的な実装amazon-mq/mcp-server-rabbitmq | star数41 | ライセンスApache-2.0 | 最終push2026年8月21日 |
| RabbitMQ | 代表的な実装kenliao94/mcp-server-rabbitmq | star数38 | ライセンスApache-2.0 | 最終push2025年10月14日 |
| NATS | 代表的な実装sinadarbouy/mcp-nats | star数50 | ライセンスApache-2.0 | 最終push2026年9月2日 |
| NATS | 代表的な実装bmorphism/nats-mcp-server | star数7 | ライセンスなし | 最終push2025年1月6日 |
同じ製品でも、実装によって最終pushの間隔が半年から1年以上開くことがわかります。ライセンスファイルが無い実装は、star数だけ見ると悪くない数字でも、商用環境に組み込む前に必ず法務確認が必要です。
Kafkaにはさらに kanapuli/mcp-kafka という実装もあり、star数は81と表中の tuannvm/kafka-mcp-server より高い数字です。ただし最終pushは2025年3月で、表中の実装が軒並み2026年に入ってからも更新を続けているのに対し、1年半近く動きが止まっています。star数は公開直後に伸びた後で止まることも多く、単独の指標としては最終更新日ほど頼りになりません。
この4軸は、GitHubの画面を開かなくてもコマンドで確認できます。GitHub CLIが入っていれば、次の1行でstar数・ライセンス・最終pushをまとめて取得できます。
gh repo view confluentinc/mcp-confluent --json stargazerCount,licenseInfo,pushedAt導入前にこのコマンドを候補のリポジトリすべてに実行しておくと、READMEの見た目や説明文の丁寧さに引っ張られずに数値だけで比較できます。npm経由で配布されているパッケージなら、npm view <パッケージ名> license でも同じライセンス情報を確認できます。
Kafkaだけは「非公式」の中身が違う
3製品の中で、Kafkaだけ性格の異なる選択肢があります。confluentinc/mcp-confluent は、Kafkaの商用ディストリビューションを提供するConfluent社が自社リポジトリで公開しているMCPサーバーです。MITライセンスで、50以上のツールをKafka本体だけでなくFlink SQL・Schema Registry・コネクタ管理・Tableflowにまたがって提供しており、対応範囲の広さも他の実装とは一線を画します。
Confluentはこのリポジトリについて、コミュニティサポートであり保証は無いと明記しています。Anthropicが自ら保守するコネクタとは違い、Confluent自身が有償サポートを約束しているわけではありません。それでも、開発元がその技術を本業とする企業であり、Confluent Cloudの利用者向けにはリポジトリの配布とは別に、権限も既存のRBAC(役割ベースのアクセス制御)設定に従うフルマネージドのホスト型MCPサーバーまで用意されています。個人開発者の週末プロジェクトとは保守体制の前提が異なります。オープンソース版とホスト版のどちらを使うかは、Confluent Cloudの契約有無と、自社インフラで完結させたいかどうかで決まります。
RabbitMQの amazon-mq もこれに近い性格です。AWSのマネージドメッセージングサービスAmazon MQのチームが、パッケージ名 amq-mcp-server-rabbitmq で公開しています。RabbitMQ本体の開発元ではありませんが、クラウドベンダーが自社サービスの一部として保守している点でConfluentの例と共通します。ツール数は旧バージョンで61個、新バージョンでは用途別にまとめ直されて31個まで整理されています。設計面でも安全を優先しており、キューの削除やメッセージ送信のような書き込み系ツールは --allow-mutative-tools フラグを付けない限り無効化されています。既定では読み取り専用になる設計は、star数やライセンスと並んで確認する価値のあるポイントです。このリポジトリはSSRF(サーバー側でリクエストを偽装される攻撃)対策やログからの認証情報除去、TLS未設定時の警告表示も備えています。SSRF対策はプライベートIPアドレス帯やlocalhostへの接続をホスト名検証で遮断する仕組みで、キュー定義をエクスポートする際もパスワードや機密キーをエージェントに返す前に自動で取り除く設計です。開発元の性格が信頼度に直結する具体例といえます。
NATSにはこの種のベンダー系実装が見つかりませんでした。最も活発な sinadarbouy/mcp-nats も個人開発者によるプロジェクトです。3製品の中でNATSだけが、企業の保守体制を期待できる選択肢を持たないことになります。NATS.io自身がMCPサーバーを公開する予定があるかどうかは、公開されているロードマップ上では確認できませんでした。
使い分けの早見表
ここまでの4軸を、実際に選ぶときの早見表にすると次のようになります。
| 開発元の性格 | 信頼度の目安 | 商用利用での注意点 |
|---|---|---|
| クラウドベンダーの自社リポジトリ(Confluent・AWS等) | 信頼度の目安高い | 商用利用での注意点サポートはコミュニティ扱いのまま。障害時は自己対応が前提 |
| 個人開発者・活発に更新 | 信頼度の目安中程度 | 商用利用での注意点ライセンスと最終pushを都度確認。破壊的変更への追随が遅れることがある |
| 個人開発者・更新停止 | 信頼度の目安低い | 商用利用での注意点フォークして自社で保守する前提が無いなら避ける |
本家が無いことは変わらない
ベンダーが公開しているからといって、格上げされるわけではありません。前節で見たとおりConfluentのリポジトリもコミュニティサポートの扱いであり、Anthropicが保守するコネクタ(Google DriveやMicrosoft 365など)とは保守責任の重さが違います。信頼度が高い実装を選んでも、書き込み系のツールを本番環境で有効化する前に、権限を最小化した専用アカウントで検証する手順は変わりません。
具体的には3段階で進めるのが安全です。まず開発環境や検証用ブローカーに接続し、読み取り系ツールだけで挙動を確認します。次に、削除・送信・再起動のような不可逆な操作を伴うツールが存在するかを一覧で洗い出し、必要最小限だけを許可リストに残します。最後に、本番接続用の認証情報は読み取り専用のロールで発行し、書き込みが要る場面だけ別の認証情報に切り替える運用にします。トークンや接続文字列を1つに集約すると、MCPサーバー側の不具合がそのまま本番ブローカーへの誤操作につながります。この3段階は、今回挙げた6実装のどれを選ぶ場合にも共通して当てはまります。
各製品の具体的な使い方
星数・ライセンス・開発元の見分け方がわかったところで、実際の接続手順は製品ごとに異なります。トピックの調査だけなのか、スキーマ管理まで含むのか、キューの監視なのかによって、必要なツールと権限設計も変わってきます。
- Kafka本体のトピック調査とコンシューマーラグ確認はKafka MCPサーバーでトピックとコンシューマーグループを調べる
- Kafkaのスキーマ管理はKafka Schema Registry MCPサーバーでスキーマ管理をClaudeに任せる
- RabbitMQのキュー監視とデッドレターキュー調査はRabbitMQのMCPサーバーでClaudeからキューとExchangeを操作する
- NATSのSubjectとJetStream操作はNATSのMCPサーバーでClaudeからPub/Subを操作する
まとめ
Kafka・RabbitMQ・NATSのMCPサーバーは、いずれもプロトコル本体からの提供がありません。ただしKafkaとRabbitMQには、Confluent・AWSといったクラウドベンダーが自社リポジトリとして保守する実装があり、個人開発者のプロジェクトより保守体制の見通しが立てやすくなっています。NATSにはその種の選択肢が今のところありません。導入前にstar数・最終push・ライセンス・開発元の4点を確認する習慣をつけておくと、半年後に更新が止まったMCPサーバーを本番で使い続けるリスクを避けられます。この4点はKafka・RabbitMQ・NATS以外の非公式MCPサーバーを検討するときにも、そのまま使い回せる基準です。