Claude Media
NATSのMCPサーバーでClaudeからPub/Subを操作する
Claude CodeMCPClaude連携チュートリアル

NATSのMCPサーバーでClaudeからPub/Subを操作する

非公式のmcp-natsを使い、SubjectやJetStreamストリームをClaudeから探索する手順と、認証方式ごとの使い分け・公式実装が存在しない点を扱います。

読了目安 約15分

NATSのMCPサーバーとは何か

mcp-natsは、Go製のNATSメッセージングシステム向けMCPサーバーです。作者個人(sinadarbouy)が開発しているコミュニティ実装で、NATS本体を開発するnats-ioorganizationは公式のMCPサーバーを提供していません。README上も「NATS公式」であるとは書かれておらず、独立した第三者ツールとして配布されています。第三者レビューサービス「MCP Review」による認証(Certified)バッジは付いていますが、これはNATS.io自身の公式認定ではありません。

このサーバーが対象にするのは、Subject階層の探索・Stream(JetStreamの永続化されたメッセージ列)の状態確認・Key-Valueバケットの読み書き・Object Storeの操作といった、NATSクライアントライブラリでいちいちコードを書かないと確認できない情報です。既定の操作は読み取り専用に寄せて設計されており、サーバーの状態確認やStreamの中身の閲覧はすぐに使えます。

導入前に確認すること

  • Go 1.25以上(ソースからビルドする場合)、またはDockerでコンテナイメージを使う方法
  • 接続先のNATSサーバー(URLと、必要なら認証情報)
  • Claude CodeまたはClaude Desktopなど、MCPクライアントとして動く環境
  • JetStreamのStreamやKey-Valueバケットを扱う場合は、対象アカウントにその権限があること

インストールする

Goのツールチェーンがあれば1コマンドでインストールできます。

go install github.com/sinadarbouy/mcp-nats/cmd/mcp-nats@latest

Dockerイメージも公開されており、マルチアーキテクチャのイメージにSigstore Cosignで署名されています。タグ付きリリースを検証したい場合は次のコマンドで署名を確認できます。

cosign verify ghcr.io/sinadarbouy/mcp-nats:0.1.4 \
  --certificate-identity-regexp 'https://github.com/sinadarbouy/mcp-nats/.github/workflows/(release\.yml@refs/tags/v.*|sign-image\.yml@refs/heads/main)' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Claude Desktopに接続する

Dockerイメージをstdioトランスポートで起動する構成であれば、次のような設定になります(公式のCursor向けインストールリンクに埋め込まれた設定をClaude Desktop形式に書き直したものです)。

{
  "mcpServers": {
    "nats": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--init",
        "-e", "NATS_URL",
        "-e", "NATS_NO_AUTHENTICATION",
        "ghcr.io/sinadarbouy/mcp-nats:0.1.4",
        "--transport", "stdio"
      ],
      "env": {
        "NATS_URL": "nats://localhost:4222",
        "NATS_NO_AUTHENTICATION": "true"
      }
    }
  }
}

ローカルで動かしているNATSサーバーに、認証なしで接続する最小構成です。本番相当の環境に繋ぐ場合は、後述の認証方式に沿ってNATS_USER/NATS_PASSWORDまたは資格情報ファイルに切り替えてください。

Claude Codeにリモートサーバーとして接続する

mcp-natsはトランスポートの既定値がStreamable HTTPです。--transportフラグを省略してサーバーを起動すると、--addressで指定したアドレス(既定は0.0.0.0:8000)の/mcpエンドポイントで待ち受けます。Claude Codeからはネイティブ対応のHTTPトランスポートとしてそのまま追加できます。

claude mcp add --transport http nats http://localhost:8000/mcp

複数のNATSアカウントを資格情報ベースで扱う場合、.mcp.jsonのようなurl型登録ではenvに書いた値はmcp-natsプロセスへ渡りません(envはローカル起動するコマンドの環境変数を差し込むためのフィールドで、リモートのHTTPサーバーには効きません)。資格情報は、次のようにmcp-natsサーバーを起動する側のコマンドで環境変数として渡します。

NATS_URL=nats://localhost:4222 \
NATS_SYS_CREDS=<SYSアカウントcredsのBase64> \
NATS_A_CREDS=<Aアカウントcredsのbase64> \
mcp-nats --address 0.0.0.0:8000

.mcp.json側はサーバーのURLだけを指定すれば済みます。

{
  "mcpServers": {
    "nats": {
      "url": "http://localhost:8000/mcp"
    }
  }
}

3つの認証方式をどう使い分けるか

mcp-natsは接続認証の方式を3種類サポートしており、どれを選ぶかは環境の性質で決まります。

方式設定方法向いている場面
資格情報ベース設定方法NATS_<ACCOUNT>_CREDS環境変数(Base64エンコードした.credsファイル)向いている場面複数アカウントを使い分ける本番運用。全ツール呼び出しにaccount_nameパラメータが必要
ユーザー名/パスワード設定方法NATS_USER/NATS_PASSWORD環境変数、または--user/--passwordフラグ向いている場面シンプルな認証設定のサーバーに繋ぐ場合
匿名接続設定方法NATS_NO_AUTHENTICATION=true環境変数、または--no-authenticationフラグ向いている場面ローカル開発環境や検証用サーバー

資格情報ベースを選んだ場合だけ、ツールを呼ぶたびにaccount_nameパラメータで対象アカウントを明示する必要がある点が、他の2方式と違うところです。複数のNATSアカウントを1つのサーバープロセスから扱えるのはこの方式だけなので、マルチテナント構成ではこちらを選びます。

Subject階層の探索とJetStreamの確認

NATSはトピックにあたる概念を「Subject」と呼び、ワイルドカードを使った階層構造で管理します。mcp-natsはこのSubject階層をClaudeから覗けるツールと、JetStream(NATSの永続化・再送機能)のStream状態を確認するツールを分けて提供しています。

  • 「orders.*にマッチするSubjectで、直近メッセージが流れているものはどれ?」— Subject探索とメッセージ閲覧の組み合わせ
  • 「ORDERSストリームの保持ポリシーと現在のメッセージ数を教えて」— Streamの状態と情報を照会するツール
  • 「configバケットのfeature-flagキーを見て、最後に更新されたのはいつ?」— Key-Valueバケットの読み取り
  • 「サーバーのRTT(往復遅延時間)を測定して」— Server Management配下のping/RTTツール

読み取り専用の操作に加えて、Object StoreとKey-Valueのバケットに対しては作成・削除・Watch(変更の監視)まで一通りのCRUD操作がツール化されています。メッセージのPublish(発行)もサポートしており、非同期発行にも対応しています。ただしPublish操作はブローカーへの書き込みそのものなので、匿名接続や共有トークンのまま本番Subjectに向けて使うのは避けたほうが安全です。

アカウント運用まわりのツールも用意されています。アカウントの接続数や統計情報のレポート生成、アカウントの状態をバックアップとして保存・復元する操作、TLSで接続しているサーバーの証明書チェーンを検査する操作までカバーしており、「このアカウントの接続数が急に増えていないか確認して」のような運用監視の依頼にもそのまま使えます。複数アカウントを1つのNATSクラスタで運用している場合、アカウントごとの資格情報を切り替えながらこれらのレポートを横断的に見比べる作業は本来手間がかかりますが、資格情報ベースの認証と組み合わせれば、アカウント名を指定するだけで同じ依頼を繰り返せます。

Kubernetesで運用する場合

Helmチャートが同梱されており、単体でのインストールとOCIレジストリ経由のインストールの両方に対応しています。

helm install mcp-nats oci://ghcr.io/sinadarbouy/charts/mcp-nats \
  --version "0.1.4" --namespace mcp-nats --create-namespace

HTTPトランスポート(streamable-httpまたはsse)で動かす場合、/livez(プロセスの生存確認、NATSへの接続は見ない)・/readyz(NATS_URLへのTCP到達性を含めた準備確認)・/healthz(/livezと同等の互換エイリアス)の3つのヘルスエンドポイントが用意されています。Kubernetesのlivenessプローブには/livez、readinessプローブには/readyzを割り当てるのが本来の使い分けです。両方に同じエンドポイントを指定すると、NATSサーバー側の一時的な不調でPodごと再起動されてしまうことがあります。

Helmチャートには、HashiCorp Vault Agent Injectorを使って資格情報をPodに注入する構成例も同梱されています。NATS_<ACCOUNT>_CREDSのような機微な環境変数をHelmのvaluesファイルに平文で書かずに済むため、Vaultをすでに社内標準として使っているクラスタでは、この構成例から始めると秘密情報の管理方法を統一できます。

よくあるつまずき

  • 「NATS公式のMCPサーバー」だと思って導入する: nats-ioorganizationにMCPサーバーは存在しません。mcp-natsは個人開発者によるコミュニティ実装で、「MCP Review」の認証バッジもNATS.io自身の認定ではなく第三者サービスによるものです。導入前提として区別しておくと、障害時の問い合わせ先を誤らずに済みます
  • 資格情報ベースで接続したのに全ツールがエラーになる: NATS_<ACCOUNT>_CREDS方式は、ツール呼び出しのたびにaccount_nameパラメータが必須です。ユーザー名/パスワード方式や匿名接続からの移行時にこのパラメータを付け忘れるとエラーになります
  • livenessとreadinessを同じエンドポイントにする: /livezはNATSへの接続を見ない生存確認、/readyzはNATSへのTCP到達性まで確認します。Kubernetesで両方を/livezにすると、NATS側の障害を検知できずリクエストを送り続けてしまいます
  • --sse-addressを新規設定で使う: このフラグは--addressの非推奨エイリアスです。新規の設定では--addressを使います
  • Publish操作を匿名接続のまま本番Subjectに向ける: 匿名接続はローカル開発・検証用の位置づけです。書き込み操作(Publish、Key-Value/Object Storeの変更)を本番相当の環境で使う場合は、資格情報ベースかユーザー名/パスワード認証に切り替えます

まとめ

mcp-natsは、NATS公式ではなく個人開発者が公開しているコミュニティ製のMCPサーバーです。Subject階層の探索やJetStream Streamの状態確認、Key-Value・Object Storeの操作までを自然言語の依頼でカバーでき、Docker・Helmチャート・署名済みコンテナイメージまで揃った実装ですが、NATS.ioの正式なサポート対象ではない点は導入前に理解しておく必要があります。認証は資格情報・ユーザー名パスワード・匿名接続の3方式があり、本番相当の環境では匿名接続を避けて資格情報ベースに寄せるのが安全な運用です。

MCPの基礎から確認したい場合はMCPとは何か、claude mcp addのスコープや認証の詳細はClaude Code MCP設定ガイド、Kubernetes上でMCPサーバーをClaudeから操作したい場合はKubernetes MCPサーバーでClaudeからクラスタを操作するも参考になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →