Box Community MCPサーバー (セルフホストBox MCPサーバー) は、重大な問題を修正する更新をいくつか配信しました。3つの新機能により、さらに多くのツールが提供され、煩わしい認証手順が不要になります。
変更内容
新機能を以下に示します。
SSEトランスポート、HTTPトランスポート、CCG認証の3つが追加されました。それぞれがローカルでの開発の設定にとって重要である理由を説明します。
CCG認証: サービスアカウント
最大の改善点は、CCG (クライアント資格情報許可) 認証です。OAuthは実用的でしたが、煩わしさがありました。初めて使用する際には、アプリケーションの承認を求めるブラウザのポップアップによって作業を中断されることになります。
CCGにより、その流れは解消されます。さらに重要なことに、サービスアカウントが開設されます。Box管理者は、MCPサーバー専用のアカウントを作成し、そのアカウントでアクセスできる対象を正確に制御できます。
- 特定のフォルダへの読み取り専用アクセス
- ドキュメントの生成権限 (ただし、削除権限はなし)
- 個人アカウントに依存しない、共有コンテンツへのアクセス
これは、テスト向けによりわかりやすくなっており、管理者は、ローカルのMCPサーバーからアクセスできる対象を適切に制御できます。
トランスポートオプション: すべてがSTDIO対応とは限らないため
元のSTDIO向けのアプローチでは、互換性の問題が発生しました。多くのMCPクライアントはHTTPまたはSSEトランスポートのみをサポートしているため、Box MCPサーバーではまったく使用できませんでした。
現在は、複数の選択肢があります。ローカルMCPサーバーは、クライアントツールが想定するどのプロトコルにも対応できます。
実際の例: n8n統合
SSEトランスポートを活用しているワークフロー自動化ツールであるn8nで実際の動作を確認しましょう。n8nでは、MCPサーバーを使用できるのは、SSEトランスポートをサポートしている場合のみです。
サーバー構成
サービスアカウントのCCG認証用の環境の構成
n8nワークフローの設定
MCPノードの構成は、n8nでは次のようになります。
n8nのMCPノードの構成
以下に、簡単なチャットボットのワークフローの例を示します。
n8nチャットボットとBox MCPサーバーの対話
サーバーに戻ると、リクエストが送信されていることがわかります。
これが実際に重要な理由
今回の更新により、ローカルでの開発でも実際のユースケースを妨げていた特定の2つの問題が解決されます。
追加の認証オプション: CCG認証により、ブラウザベースのOAuthフロー全体が省略されます。今後は「ここをクリックして承認」というポップアップで作業の流れが中断されることはありません。さらに重要なことに、Box管理者は、アプリケーションに必要なだけのスコープを正確に設定したサービスアカウントを作成できます。特定のフォルダへの読み取り専用アクセスが必要な場合や、 ドキュメントの生成は必要でもファイルの削除が不要の場合にも 簡単に対応できます。権限を制御するのは管理者であり、「許可」をクリックするユーザーではありません。
MCPクライアントの互換性: 現実には、すべてのMCPクライアントがSTDIOトランスポートを実装しているわけではありません。HTTPのみを実装しているものもあれば、リアルタイム更新用にSSEを必要としているものもあります。今回の更新より前は、お使いのMCPクライアントがSTDIOに対応していなければ使用することができませんでしたが、今回の更新により、HTTPエンドポイントを想定する、n8nやその他のワークフロープラットフォームのようなツールを実際に使用できるようになりました。
n8nの例は理論上のものではありません。実際、Box MCPサーバーを実行しているhttp://localhost:8000にn8nを指定すると、Boxコンテンツを操作するワークフローの作成を開始できます。HTTP APIを使用するもののSTDIOトランスポートを認識していないその他のツールについても同様です。
これらは大規模なアーキテクチャの変更ではなく、「なぜ既存のツールでこれを使用できないのか」という問題に対する実用的な解決策です。
要点
今回の更新により、開発中にOAuthによって中断されることも、「このMCPクライアントはSTDIOに対応していません」という制限もなくなり、よりわかりやすい認証とより幅広いツールの互換性が実現します。
コミュニティのGitHubリポジトリをご確認ください。