KlavisでAIエージェントにMCP接続を組み込む
このプロジェクトは「Klavis AI: MCP integration platforms that let AI agents use tools reliably at any scale.」を基盤として、実践的に使えるオープンソース実装を提供し、再利用可能なツールチェーンと統合手段を備えています。
ひと目でわかる
- これは何？
- Strata、100以上のMCP連携、学習と強化学習向けMCP Sandboxをクラウド、セルフホスト、SDK、REST APIから扱う基盤。
- 誰に向いている？
- AIエージェントへGmailやSlackなどのツールを接続し、複数サーバーをまとめて扱いたい開発者に向きます。クラウド版、セルフホスト、SDK、REST APIでは秘密情報と運用責任が変わるため、READMEのサンプルを本番設定へ直結させてはいけません。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 106 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
三つの選択肢を先に分ける
KlavisのREADMEは、AIエージェント向けのMCP統合プラットフォームとしてStrata、MCP Integrations、MCP Sandboxを示しています。Strataはコンテキストウィンドウの最適化をうたうインテリジェントコネクター、MCP IntegrationsはOAuth対応の100以上の事前構築連携、SandboxはLLM学習と強化学習向けのスケーラブルなMCP環境です。
目的が既存アプリ接続なのか、複数サーバーの束ね合わせなのか、学習環境なのかで入口が変わります。サービスの紹介文だけで能力を同一視せず、公式docsのStrata、MCP server、Sandboxの各概念を対象機能と照合します。
クラウド、セルフホスト、SDK
Quick Startには四つの入口があります。クラウド版は`klavis.ai`のQuickstart、セルフホストはDocker、SDKはPythonまたはTypeScript、もう一つはREST APIです。セルフホスト例は`docker pull ghcr.io/klavis-ai/github-mcp-server:latest`と`docker run -p 5000:5000 ghcr.io/klavis-ai/github-mcp-server:latest`です。
クラウドではサービス側の認証とデータ境界を確認し、セルフホストではイメージ版、ポート5000、永続化、コンテナ権限を管理します。`latest`を使うサンプルは更新で内容が変わるため、試験時のイメージダイジェストを記録します。
StrataでGmailとSlackを束ねる
Python SDKでは`Klavis`にAPIキーを渡し、`mcp_server.create_strata_server`へ`user_id`と`McpServerName.GMAIL`、`McpServerName.SLACK`を指定してStrataインスタンスを作成します。個別のMCPサーバーは`create_server_instance`で作ります。
TypeScript SDKにも`KlavisClient`、`createStrataServer`、`createServerInstance`の対応する呼び出しがあります。サンプルの`your-key`や`user123`は置き換え前提です。テストではユーザーごとの接続が混ざらないこと、GmailとSlackで許可する操作が異なること、認証失敗が呼び出し元へ明確に返ることを確認します。
MCPサーバーをコンテナで確かめる
セルフホスト例には、KlavisのGitHub MCP serverをポート5000で動かす方法と、Open Source Strataを`pipx install strata-mcp`で導入する方法があります。StrataへPlaywrightをstdio型で追加するコマンドは`strata add --type stdio playwright npx @playwright/mcp@latest`です。
この例ではDocker、pipx、Node.js、npxなど複数の実行環境が関係します。コンテナが起動したことと、MCPのtoolsが期待した名前・引数で返ることを別に確認します。Playwrightのようにブラウザ操作を伴うサーバーは、対象URL、ファイル、認証状態をテスト用に限定し、エージェントの自動操作を無制限に許可しません。
REST APIはユーザー単位で呼ぶ
REST APIの例は`POST https://api.klavis.ai/v1/mcp-server/strata`へBearer APIキーとJSONを送り、`user_id`と`servers`としてGMAIL、SLACKを渡します。個別サーバーは`/v1/mcp-server/instance`へ`server_name`と`user_id`を送ります。
実装ではAPIキーをソースやブラウザへ埋め込まず、HTTP応答、タイムアウト、再試行、接続終了を記録します。READMEは各エンドポイントのレート制限、保存期間、詳細なエラー表を示していないため、公式docsと実際のレスポンスを確認します。ユーザーIDを固定値のまま本番へ持ち込まないことも必要です。
Apache-2.0と採用前の境界
リポジトリのライセンスはApache-2.0です。コードを利用・改変・配布する条件はLICENSE全文で確認しますが、ライセンスはMCP連携先の権限や第三者データの扱いを保証しません。READMEは公式docs、Discord、Issue、Klavis AIサイトをサポートと情報の入口として示しています。
向くのは、エージェントが呼べるツールを明示し、ユーザーごとの認証と実行範囲を管理できるチームです。まずStrataなしの個別サーバーを一つ動かし、次にGmailとSlackを束ね、最後にREST APIまたはSDKへ進みます。各段階でツール一覧、OAuth範囲、ログ、失敗時の再接続、データ送信先を確認してから運用範囲を広げます。
個別接続からStrataへ段階化する
テスト用のAPIキーと`user_id`を用意し、まず`create_server_instance`でGmailまたはSlackを一つだけ作ります。MCPのtools、OAuthの許可範囲、接続終了、認証失敗を確認し、実在データの変更を伴わない操作から始めます。Docker版ではポート5000への接続とコンテナログを別に確認します。
個別接続が安定したら`create_strata_server`でGmailとSlackを束ね、ユーザー接続が混ざらないこと、ツール名と引数が正しく渡ることを試します。最後にREST APIへ移し、Bearerキーをサーバー側に置いたまま異常応答を記録します。SDKと`latest`イメージの版を固定し、許可範囲を越えるツール呼び出しが拒否されることを確認してから本番へ進めます。
ツール権限を呼び出し単位で検査する
GmailとSlackは読み取りだけのテスト操作から始め、OAuthのscope、ユーザーID、MCPのtools一覧を保存します。Strataを作った後に一方の接続を無効にし、エージェントが許可されていないツールを選べないことを確認します。SDKとREST APIで同じ失敗応答、タイムアウト、再接続を比較し、APIキーをログやクライアントへ出さない状態を確かめてから外部データの変更へ進みます。 導入前には、個別サーバーとStrataのtools、認証、失敗応答を比較します。 OAuthを解除した後に以前のユーザーがツールを呼べないことも確認します。 さらに、接続ごとのユーザー、scope、ツール引数、外部サービスの監査ログを保存します。 接続を削除して再作成した場合のユーザー境界、OAuth再認証、監査ログ、利用停止手順もテスト記録に含めます。
編集部の結論
AIエージェントへGmailやSlackなどのツールを接続し、複数サーバーをまとめて扱いたい開発者に向きます。クラウド版、セルフホスト、SDK、REST APIでは秘密情報と運用責任が変わるため、READMEのサンプルを本番設定へ直結させてはいけません。まずテスト用のAPIキーとユーザーIDで一つのMCPサーバーを起動し、OAuth、ツール権限、接続終了、ログ、データ送信先を確認してください。
コミュニティノート