Boomi MCP Server

Boomi MCP Server

Claude Code から Boomi Platform API と連携するためのセキュアな MCP サーバー

OAuth 2.0 認証と安全な認証情報ストレージを使用して、Claude Code などの MCP クライアントが Boomi Platform API を操作できる、本番環境対応の Model Context Protocol（MCP）サーバーです。

🌐 ライブサービス：https://boomi.renera.ai

---

主な機能

• 🔐 Google OAuth 2.0 - 同意画面を使用した安全な認証
• 🔒 GCP Secret Manager - ユーザーごとの暗号化された認証情報ストレージ
• 👤 複数プロファイルのサポート - ユーザーごとに最大10件の Boomi アカウントプロファイルを保存
• 🌐 Web UI - ブラウザーから認証情報を管理
• ✅ 認証情報の検証 - 保存前に認証情報をテスト
• 🚀 自動デプロイ - GitHub へのプッシュ → Cloud Build（固定 KB リリース）→ Cloud Run
• 📦 MCP ツール - 取引先、プロセス、コンポーネント、ランタイム、デプロイ、スケジュール、アカウント管理などを網羅する29個のツール
• 📚 Boomi Docs KB - 固定されたナレッジベースリリースを利用する、任意の検索拡張生成ツール search_boomi_docs / read_boomi_doc_page
• ☁️ クラウドネイティブ - Google Cloud Run で稼働

---

クイックスタート

ユーザー向け

1. Web UI にアクセス：https://boomi.renera.ai

2. Google でログイン - OAuth 認証

3. Boomi の認証情報を追加：

   • Email：Boomi アカウントのメールアドレス
   • API Token：Boomi API トークン
   • Account ID：Boomi アカウント ID
   • Profile Name：この認証情報セットの名前（例：「production」、「sandbox」）

4. Claude Code に接続：

claude mcp add --transport http boomi https://boomi.renera.ai/mcp

5. 認証 - ブラウザーが開いて OAuth の同意画面が表示されるので、「Approve」をクリックします

6. MCP ツールを使用：

Show me my Boomi account information from the production profile

---

アーキテクチャ

┌──────────────┐
│    User      │
│  (Browser)   │
└──────┬───────┘
       │ 1. Visit https://boomi.renera.ai
       │ 2. Google OAuth Login
       ▼
┌──────────────────────────────────────┐
│      Boomi MCP Server (Cloud Run)    │
│  ┌────────────┐    ┌──────────────┐ │
│  │  Web UI    │    │  MCP Server  │ │
│  │ (FastAPI)  │    │  (FastMCP)   │ │
│  └────────────┘    └──────────────┘ │
└───────┬──────────────────┬───────────┘
        │                  │
        │ Store            │ Retrieve
        │ Credentials      │ Credentials
        ▼                  ▼
┌──────────────────────────────────────┐
│      GCP Secret Manager              │
│  boomi-mcp-{user-id}-{profile-name}  │
└──────────────────────────────────────┘
                    │
                    │ API Calls
                    ▼
             ┌──────────────┐
             │  Boomi API   │
             └──────────────┘

動画：1つのリクエストを最初から最後まで追跡

上の図はデプロイのトポロジーを示しています。コードの処理経路、つまり MCP クライアントが query_components を呼び出してから Boomi が応答するまでに実際に何が起きるのかを、4つの境界をまたいで1つのリクエストを追いながら解説し、処理が到達する箇所の Python コードも説明します。

14分間の動画です。ツール登録を制御する条件付きインポート、インポート時に実行される @mcp.tool、AnyIO のワーカースレッド上の同期ラッパー、信頼境界での json.loads、get_secret による認証情報の解決、そしてアクションルーターへの **params の受け渡しを取り上げています。

動画に表示される行番号は、録画時点の main に基づいています。

---

利用可能な MCP ツール

サーバーは29個のツールを公開しています。すべてのツールを使用するには、認証済みセッションと、保存済みの Boomi 認証情報セットを指定する有効な profile パラメーターが必要です。

アカウントとプロファイルの管理

• list_boomi_profiles() — 現在のユーザーに保存されている認証情報プロファイルを一覧表示します。
• boomi_account_info(profile) — 指定されたプロファイルのアカウント詳細を取得します。
• set_boomi_credentials(...) / delete_boomi_profile(...) — 認証情報の CRUD 操作を行います。
• manage_account(...)、manage_account_groups(...) — Boomi アカウントの管理を行います。

インテグレーションの構築、デプロイ、運用

• manage_process（プロセス一覧の取得・詳細の取得のみ）、manage_component、analyze_component、 query_components、build_integration、get_schema_template
• manage_environments、manage_runtimes、manage_deployment、 execute_process、troubleshoot_execution、manage_schedules、 manage_listeners、manage_integration_packs
• manage_trading_partner、manage_connector、manage_shared_resources、 manage_folders、monitor_platform

追加の呼び出し手段

• invoke_boomi_api(...) — 専用ツールがない場合に、任意の Boomi REST エンドポイントを呼び出します。
• list_capabilities() — 登録済みのすべてのツールを要約して確認できるツールです。

Boomi ドキュメントナレッジベース（任意）

サーバーの起動時に BOOMI_DOCS_ENABLED=true が設定され、BOOMI_DOCS_DB_PATH にデータが格納された KB がある場合にのみ登録されます。

• search_boomi_docs(query, ...) — インデックス化された Boomi ドキュメントコーパスを対象にしたセマンティック検索です。
• read_boomi_doc_page(page_key) — 指定したドキュメントページの Markdown 全文を取得します。
• リソース kb://boomi-docs/corpus — コーパスマニフェスト（リリースタグ、ページ数、生成日時のメタデータ）です。

KB コーパスは RenEra-ai/knowledge-base-builder で構築・リリースされ、ビルド時に deploy/kb-release.env を介してイメージに組み込まれます。詳しくは以下の KB リリースの昇格を参照してください。

コールドスタート時の動作（運用担当者向け）。 負荷の大きい KB のビルド（Chroma と埋め込みモデルの読み込み）は、サーバーが直ちに HTTP ポートで待ち受けられるよう、インポート処理の後に実行されます。KB の準備が整う前にドキュメントツールは登録されます。すべてのドキュメント呼び出しは準備状態をアトミックに解決し、次の 3 つの状態のいずれかになります。

1. 通常の待機後に応答 — コールドスタート中、最大 BOOMI_DOCS_WARMUP_MAX_WAITERS 件のドキュメント呼び出しが長時間待機する呼び出しとして受け付けられ、ビルドが完了するまで（BOOMI_DOCS_WARMUP_WAIT_SECONDS で上限を設定）待機し、その後実際の結果を返します。本番ビルドの所要時間は平均約 49 秒、p95 約 58 秒、最大約 63 秒のため、受け付けられた呼び出し元は通常、初回の呼び出しに時間がかかるだけです。
2. 上限超過またはビルドの大幅な遅延 — それ以降の同時呼び出し、または上限時間に達した待機中の呼び出し元には、BOOMI_DOCS_WARMUP_EXPECTED_SECONDS の残りの割合から算出した retry_after_seconds のヒントとともに、error: warming_up が直ちに返されます（5～60 に制限され、見積もり時間を超えた後は下限値になります）。
3. ビルド失敗 — 受け付けられたすべての待機中呼び出し元は、サニタイズされた error: kb_unavailable を受け取って直ちに起床します。BOOMI_DOCS_WARMUP_RETRY_COOLDOWN の経過後（デフォルトは 30 秒）、次の呼び出し時にビルドが自動的に再試行されます。

調整用の環境変数（コード内のデフォルト値は cloudbuild.yaml と一致します。無効な値は運用担当者向けの警告とともにデフォルト値に戻されます）：BOOMI_DOCS_WARMUP_EAGER（デフォルトは true — 認証済みの最初の /mcp リクエストでビルドを開始します）、BOOMI_DOCS_WARMUP_WAIT_SECONDS（デフォルトは 65 — 受け付けられた待機中呼び出し元の待機時間の上限です。実測したビルドの p95／最大値を少し上回る値に設定されています）、BOOMI_DOCS_WARMUP_EXPECTED_SECONDS（デフォルトは 60 — warming_up の再試行までの時間のヒントを決定します）、BOOMI_DOCS_WARMUP_MAX_WAITERS（デフォルトは 4 — 長時間待機する呼び出しの受付上限です。上限を超えた場合は直ちに warming_up が返されます）。boomi.kb.warmup ロガーは、KB_WARMUP_STARTED/RETRY、KB_RESOLVE_ADMITTED/OVERFLOW、KB_WARMUP_ELAPSED と、可観測性向けのフェーズごとのビルド所要時間を出力します。

Boomi 運用上の注意事項 KB（任意）

サーバーの起動時に BOOMI_GOTCHAS_ENABLED=true が設定されている場合にのみ登録されます。これはドキュメント KB（公式ドキュメント）とは別の情報源であり、独立した専用フラグで有効化します。

• search_boomi_gotchas(query, top_k=5, issue_ids=None) — Boomi で知られている無言の失敗モードや現場での落とし穴をまとめたカタログを検索します。gotcha ID による決定的な完全一致検索を行うには、issue_ids を指定してください（指定した場合は query より優先されます）。結果が空の場合や一致項目がない場合の動作は明示され、項目を捏造することはありません。
• リソース kb://boomi-operational-gotchas/catalog — 各項目の症状、検出頻度の分類、出典、verification_status を含むカタログ全体です。

ドキュメント KB とは異なり、このカタログは標準ライブラリのみで動作します。リポジトリ内の厳選されたデータセットを使用し、決定的な字句ランキングを行うため、requirements-kb.txt、chromadb、埋め込みの依存関係はありません。項目は逐語的な転載ではなく、厳選した要約（OfficialBoomi の BSD-2-Clause 素材と、ローカルの issue／アーキテクト講座のトリアージに基づく）であり、エージェントが各主張の裏付けの程度を評価できるよう、verification_status（live_verified／docs_corroborated／companion_unverified／course_unverified／disputed）が付与されています。

---

デプロイ

現在の本番環境へのデプロイ

• ホスティング：Google Cloud Run（us-central1）
• URL：https://boomi.renera.ai
• CI/CD：GitHub 経由で自動化
• リージョン：us-central1
• 認証：Google OAuth 2.0

CI/CD パイプライン

main ブランチへのプッシュ時に自動でデプロイされます。

GitHub Push → Cloud Build (cloudbuild.yaml) → Docker Build (KB pin) → Artifact Registry → Cloud Run

パイプラインは cloudbuild.yaml でソース管理され、固定された Boomi Docs ナレッジベースのリリースをイメージに組み込みます。KB タグは deploy/kb-release.env に記載されているため、コーパスのバージョンを変更すると、リポジトリ上で変更を確認できます。ビルドでは、浮動する latest KB リリースを決して使用しないでください。

KB リリースの昇格

1. RenEra-ai/knowledge-base-builder で手動の workflow_dispatch リリースを作成します（例：kb-13）。リリースには boomi_knowledge_db.tar.gz をアセットとして公開する必要があります。
2. このリポジトリで、deploy/kb-release.env の1行を更新します。

   KB_RELEASE_TAG=kb-13
   

3. この変更を含む PR を作成し、main にマージします。
4. Cloud Build トリガーは cloudbuild.yaml を読み込み、GitHub リリースアセットに対して curl -fI の事前チェックを実行してから、--build-arg KB_RELEASE_TAG=$KB_RELEASE_TAG を指定してイメージをビルドします。ピン留めが未設定または空の場合、Docker の処理が始まる前にビルドが失敗します。
5. Cloud Run は BOOMI_DOCS_ENABLED=true、BOOMI_DOCS_DB_PATH=/app/kb/boomi_knowledge_db、BOOMI_DOCS_RELEASE_TAG=<tag> を設定して更新されます。これにより、起動時にサーバーが search_boomi_docs ツールと read_boomi_doc_page ツール、および kb://boomi-docs/corpus リソースを登録します。

Cloud Build トリガーの移行

既存のトリガー 8623a6fa-3295-430a-b018-7c728ba941e8 は、KB_RELEASE_TAG を渡さず、KB の実行時環境変数も設定しない、インラインの自動生成設定から作成されました。一度だけ、ソース管理されている設定を参照するように変更します。

gcloud builds triggers update github 8623a6fa-3295-430a-b018-7c728ba941e8 \
  --project=boomimcp \
  --region=global \
  --build-config=cloudbuild.yaml

移行後は、main へのプッシュごとに cloudbuild.yaml の手順が実行され、git log -- cloudbuild.yaml deploy/kb-release.env で、現在適用されている KB のバージョンを正確に確認できます。

手動デプロイ

手動でデプロイする必要がある場合（GitHub トリガーをスキップします）。

# Authenticate with GCP
gcloud auth login
gcloud config set project boomimcp

# Submit the same pipeline that the trigger runs.
# REPO_NAME and COMMIT_SHA are populated by Cloud Build only for
# trigger-driven runs, so pass them explicitly via --substitutions
# when submitting from the CLI.
gcloud builds submit \
  --config=cloudbuild.yaml \
  --substitutions="REPO_NAME=boomi-mcp-server,COMMIT_SHA=$(git rev-parse HEAD)"

# Or use the trigger by pushing
git push origin main

---

設定

環境変数（Cloud Run）

OAuth プロキシの永続化

Cloud Run インスタンスのスリープや再起動後も MCP OAuth フローを維持するために必要です。OAuth の状態は、Fernet 暗号化を使用して MongoDB Atlas に保存されます。

OIDC_CLIENT_ID          # Google OAuth client ID
OIDC_CLIENT_SECRET      # Google OAuth client secret
OIDC_BASE_URL           # https://boomi.renera.ai
SESSION_SECRET          # Session signing key for web UI
MONGODB_URI             # MongoDB Atlas connection string for OAuth state
JWT_SIGNING_KEY         # Stable key for signing MCP JWT tokens
STORAGE_ENCRYPTION_KEY  # Fernet key(s) for encrypting OAuth tokens at rest.
                        # Single value or comma-separated list (newest first)
                        # to enable zero-downtime key rotation via MultiFernet.

認証の強化（任意）

4つすべてに安全なデフォルト値が設定されています。デバッグまたはキーのローテーションを行う場合にのみ上書きしてください。ロールバック手順の全容については、docs/oauth-migration-runbook.md を参照してください。

BOOMI_RT_GRACE_SECONDS          # default 60. Window during which a just-
                                # rotated refresh token still returns the
                                # same new tokens (defeats one-time-use
                                # replay race). Set 0 to disable.
BOOMI_RT_GRACE_MAX_SIZE         # default 512. LRU capacity for the grace cache.
BOOMI_OAUTH_DIAGNOSTICS_DISABLE # default off (diagnostics ON). Set true to
                                # silence the three OAuth diagnostic log
                                # patches. BOOMI_OAUTH_DIAGNOSTICS=false
                                # also works as a back-compat opt-out.
BOOMI_AUTH_HEAL_CORRUPT_CLIENTS # default true. When get_client raises
                                # InvalidToken/ValidationError, delete the
                                # corrupted MongoDB doc so the client can
                                # re-register cleanly.

OAuth キャッシュの強化（任意）

Google 呼び出しとインスタンス間に残るギャップを解消します。すべて安全なデフォルト値が設定されています。ロールアウトとロールバックの手順については、docs/oauth-migration-runbook.md を参照してください。

BOOMI_TOKEN_CACHE_DISABLE           # default off (cache ON). Set true to
                                    # restore the per-tool-call Google
                                    # tokeninfo/userinfo round trip.
BOOMI_TOKEN_CACHE_TTL_SECONDS       # default 300. Upper bound on per-entry
                                    # TTL; caps Google-revocation latency.
BOOMI_TOKEN_CACHE_MAX_SIZE          # default 256. LRU capacity.
BOOMI_TOKEN_CACHE_SWR               # default false. Opt-in stale-while-
                                    # revalidate against short Google outages.
BOOMI_TOKEN_CACHE_SWR_WINDOW        # default 30. Seconds before expiry at
                                    # which SWR serves stale + refreshes.
BOOMI_TOKEN_CACHE_STALE_IF_ERROR_SECONDS  # default 0 (off); Cloud Run pins =0
                                    # (off). Opt in by raising it. When the
                                    # Google verifier returns None after a cache
                                    # entry expired, serve the last positive
                                    # token for this many seconds past expiry --
                                    # only while the token's own expiry is still
                                    # future. Note: the verifier returns None for
                                    # BOTH transient failures and explicit Google
                                    # rejections, so enabling this extends the
                                    # cache's revocation-latency window (see
                                    # BOOMI_TOKEN_CACHE_TTL_SECONDS) by up to this
                                    # many seconds. Negatives are never cached.

BOOMI_RT_GRACE_SHARED               # default true. Backs the refresh-token
                                    # grace cache with a MongoDB collection
                                    # (mcp-rt-grace, Fernet-encrypted) so
                                    # multi-replica deployments coalesce
                                    # rotations across instances.
BOOMI_RT_GRACE_SHARED_COLLECTION    # default mcp-rt-grace.
BOOMI_RT_GRACE_DISTRIBUTED_LOCK     # default false. Opt-in cross-instance
                                    # singleflight via mcp-rt-inflight-locks.
                                    # Enable only if logs show duplicate
                                    # orig_exchange calls within ms.
BOOMI_RT_GRACE_LOCK_TTL_SECONDS     # default 30. Auto-release safety bound.
BOOMI_RT_GRACE_LOCK_POLL_MS         # default 100. Follower poll interval.

BOOMI_RT_RECOVERY_ENABLED           # default true. Durable recovery of stale
                                    # refresh JWTs that still verify but whose
                                    # storage rows were deleted (hours/days
                                    # later). Uses an encrypted alias ledger
                                    # (mcp-rt-recovery) to mint fresh tokens.
BOOMI_RT_RECOVERY_MAX_AGE_SECONDS   # default 2592000 (30d, matches the sliding
                                    # refresh lifetime). Max durable alias
                                    # lifetime; older stale tokens must re-auth.
BOOMI_RT_RECOVERY_COLLECTION        # default mcp-rt-recovery.
BOOMI_RT_RECOVERY_MAX_HOPS          # default 64 (scaled with the 30d window).
                                    # Max alias-chain depth walked when resolving
                                    # a stale token to its latest live successor.
BOOMI_RT_REFRESH_JWT_LEEWAY_SECONDS # default 60. Clock-skew tolerance on the
                                    # refresh JWT exp, durable-recovery path only.
BOOMI_RT_SLIDING_REFRESH_EXPIRY     # default true. When upstream omits
                                    # refresh_expires_in, stamp the new FastMCP
                                    # refresh token with a fresh sliding window
                                    # (fixes the frozen 30-day expiry).
BOOMI_RT_SLIDING_REFRESH_TTL_SECONDS # default 2592000 (30d). Sliding lifetime.

BOOMI_AUTH_PROTECTION_STRICT        # default true in production / false in
                                    # local. Fail startup if an ENABLED shared-
                                    # grace or durable-recovery backend cannot
                                    # initialize, instead of silently degrading.
BOOMI_RT_PATCH_STRICT               # default true in production / false in
                                    # local. A FastMCP-contract incompatibility
                                    # raises instead of silently leaving
                                    # recovery/sliding unpatched.

永続的な復旧レイヤー（refresh_token_recovery_patch）は、60秒の猶予キャッシュの内部で適用されます。猶予キャッシュは即時の再試行に対応し、復旧レイヤーは数時間または数日後の古いトークンを処理します。その後にのみ、実際の FastMCP ローテーションが実行されます。復旧レイヤーは、キャッシュされた古いアクセストークンを再利用しません。常に新しいアクセストークンとリフレッシュトークンのペアを発行します。診断イベント（ロガー boomi.refresh_token_recovery）：RT_DIAG event=rt_recovery_hit（古いクライアントが復旧した）および event=rt_recovery_miss（エイリアスは解決されたが、その後継トークンがすでに有効でなくなっている）。ロールバックするには、BOOMI_RT_RECOVERY_ENABLED=false（復旧を無効化）または BOOMI_RT_SLIDING_REFRESH_EXPIRY=false（FastMCP の固定ウィンドウ動作に戻す）を設定します。mcp-rt-recovery エントリーは TTL によって期限切れになるため、データ移行は必要ありません。

ユーザー認証情報の保存

ユーザーの Boomi API 認証情報は、GCP Secret Manager に個別に保存されます。

SECRETS_BACKEND         # gcp
GCP_PROJECT_ID          # boomimcp

• 形式：boomi-mcp-{user-id}-{profile-name}
• 例：boomi-mcp-glebuar-at-gmail-com-production
• 暗号化：保存時および転送時
• アクセス：IAM による制御、監査ログに記録

Boomi ドキュメントのナレッジベース

起動時に KB ツールを登録するよう、cloudbuild.yaml で Cloud Run に設定されています。

BOOMI_DOCS_ENABLED       # true to register KB tools and resource
BOOMI_DOCS_DB_PATH       # /app/kb/boomi_knowledge_db (in-image corpus path)
BOOMI_DOCS_RELEASE_TAG   # operational marker, mirrors deploy/kb-release.env

BOOMI_DOCS_ENABLED が未設定または false の場合、KB モジュールはインポートされず、requirements-kb.txt の依存関係も読み込まれず、KB ツールと kb://boomi-docs/corpus リソースも登録されません。

MCP ステートレス転送（ワークストリーム B — 本番環境で有効）

BOOMI_MCP_STATELESS_HTTP=true は、2026-06-01 以降、cloudbuild.yaml で固定されています。本番環境では FastMCP のストリーミング可能な HTTP をステートレスで実行するため、インスタンスごとの MCP セッションと、それが引き起こしていた障害がなくなります。コールドスタート時に、ステートフルなツール呼び出しの POST でサーバーからクライアントへの応答チャネルが失われ（回収された場合や、再接続時に 2 つ目のインスタンスへ 404 で接続された場合）、Cloud Run の 300s リクエストタイムアウトによって終了されるまでハングすることがありました。ステートレスでは各 POST が自己完結したリクエスト→応答→終了となるため、このハングや、再デプロイ後の 404 Session not found は発生しません。

BOOMI_MCP_STATELESS_HTTP   # PINNED true in cloudbuild.yaml. Builds the MCP app
                           # with stateless_http=true and skips the stream guard,
                           # session-manager binding, JWT-issuer binding, and
                           # session reaper (none apply without per-instance
                           # sessions). Set false to revert to stateful.
BOOMI_MCP_JSON_RESPONSE    # PINNED true in cloudbuild.yaml (since 2026-06-07).
                           # Honored ONLY in stateless mode; passes
                           # json_response=true so each POST tool result is a
                           # single buffered JSON response instead of SSE-on-POST.
                           # Required: SSE-on-POST large results stalled in the
                           # Cloud Run managed-domain-mapping proxy and hung the
                           # client indefinitely. Set false only to debug.

✅ 採用：stateless=true / json_response=true（2026-06-07 に固定）。以前のデフォルトである json_response=false（POST で SSE を使用）では、大きなツール結果（例：query_components の action=get が約 30 KB のプロセス XML を返す場合）が Cloud Run のマネージドドメインマッピングプロキシで停止することが判明しました。応答が配信されず、クライアントはエラーもなくハングしていました。バッファー処理された JSON 応答は確実に配信されます。さらに、バックアップ対策として、コンポーネント XML の読み取りには実時間の期限（BOOMI_COMPONENT_GET_DEADLINE_SECONDS、デフォルト 90s、1～240 に制限）が設定されています。バックエンドの取得自体が停止した場合、ハングする代わりに構造化された COMPONENT_GET_DEADLINE_EXCEEDED エラーを返します。この修正ではスケール・トゥ・ゼロ（最小インスタンスなし）が維持されます。起動ログには、有効な POST フレーミング方式と、ストリームガード用の環境変数がステートレスモードでは無効であるかどうかが表示されます。ロールバックするには、BOOMI_MCP_JSON_RESPONSE=false を設定して再デプロイします。true と判定される値は true、1、yes、on です（大文字と小文字は区別されません）。

---

ローカル開発

前提条件

• Python 3.11+
• Google Cloud SDK
• Secret Manager が有効な GCP プロジェクトへのアクセス

セットアップ

# Clone repository
git clone https://github.com/RenEra-ai/boomi-mcp-server.git
cd boomi-mcp-server

# Create virtual environment
python3 -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -r requirements.txt -r requirements-cloud.txt

# Configure environment
cp .env.example .env
# Edit .env with your OAuth credentials

ローカルで実行

# Set environment variables
export OIDC_CLIENT_ID="your-google-oauth-client-id"
export OIDC_CLIENT_SECRET="your-google-oauth-client-secret"
export OIDC_BASE_URL="http://localhost:8080"
export SESSION_SECRET="$(python3 -c 'import secrets; print(secrets.token_urlsafe(32))')"
export SECRETS_BACKEND=gcp
export GCP_PROJECT_ID=boomimcp

# Run server
python server_http.py

http://localhost:8080 にアクセスして、Web UI を開きます。

---

プロジェクト構成

boomi-mcp-server/
├── server.py                  # Core MCP server (FastMCP, all tool definitions)
├── server_http.py             # HTTP wrapper with OAuth middleware
├── src/boomi_mcp/
│   ├── cloud_secrets.py       # Secret Manager backends (GCP/AWS/Azure)
│   ├── local_secrets.py       # Local filesystem secret backend
│   ├── sanitize.py            # Response sanitization helpers
│   ├── categories/            # Tool category groupings
│   ├── models/                # Pydantic models for SDK payloads
│   ├── utils/                 # Misc utilities
│   └── kb/                    # Boomi Docs knowledge-base (gated by BOOMI_DOCS_ENABLED)
│       ├── service.py         # Search + page retrieval over Chroma corpus
│       ├── manifest.py        # kb://boomi-docs/corpus resource
│       └── errors.py          # KB-specific exception types
├── templates/                 # Jinja2 web UI templates (credentials, login, ...)
├── static/                    # Web UI static assets
├── tests/                     # Unit + integration tests (incl. tests/kb)
├── docs/                      # Specs, plans, runbooks
├── agents/                    # Subagent configs (boomi-qa-tester, ...)
├── examples/                  # Usage examples
├── scripts/                   # Operational scripts
├── local_atom/                # Helpers for the local-atom dev profile
├── requirements.txt           # Core dependencies (FastMCP, ...)
├── requirements-cloud.txt     # Cloud provider SDKs
├── requirements-kb.txt        # KB dependencies (chromadb, sentence-transformers)
├── Dockerfile                 # Multi-stage Docker build (KB pin via ARG)
├── cloudbuild.yaml            # Cloud Build pipeline (pinned KB release)
├── deploy/
│   └── kb-release.env         # Pinned knowledge-base release tag
└── README.md                  # This file

---

セキュリティ機能

認証と認可

• ✅ PKCE を使用した Google OAuth 2.0
• ✅ OAuth 同意画面（混乱した代理人攻撃を防止）
• ✅ 暗号署名を使用したセッションベースの認証
• ✅ ユーザーごとの認証情報の分離

データ保護

• ✅ HTTPS のみ（Cloud Run によって強制）
• ✅ 保存時の認証情報の暗号化（GCP Secret Manager）
• ✅ 転送中の認証情報の暗号化（TLS）
• ✅ 環境変数に認証情報を保存しない
• ✅ Cloud Logging による監査ログ

アクセス制御

• ✅ IAM に基づくシークレットへのアクセス
• ✅ プロファイル数の上限（ユーザーごとに 10 件）
• ✅ 保存前の認証情報の検証
• ✅ セッションの自動有効期限切れ

---

モニタリングとログ

ログを表示

# Recent logs
gcloud run services logs read boomi-mcp-server \
  --region us-central1 --limit 50 --project boomimcp

# Follow logs in real-time
gcloud run services logs tail boomi-mcp-server \
  --region us-central1 --project boomimcp

# Check service status
gcloud run services describe boomi-mcp-server \
  --region us-central1 --project boomimcp

Cloud Console

• サービス：https://console.cloud.google.com/run/detail/us-central1/boomi-mcp-server
• ログ：https://console.cloud.google.com/run/detail/us-central1/boomi-mcp-server/logs
• ビルド：https://console.cloud.google.com/cloud-build/builds?project=boomimcp

---

トラブルシューティング

MCP サーバーに接続できない

1. サービスが実行中であることを確認します：

curl https://boomi.renera.ai/

2. OAuth の同意が完了したことを確認します：

   • claude mcp add の実行中にブラウザーが開くはずです
   • 同意画面で「Approve」をクリックします
   • 成功メッセージが表示されていることを確認します

3. Claude Code の MCP 設定を確認します：

claude mcp list

認証情報が保存されない

1. Web UI のすべてのフィールドに入力したことを確認します
2. 認証情報の検証に成功することを確認します
3. ブラウザーコンソールでエラーを確認します（F12）
4. サーバーログでエラーメッセージを確認します

API エラー

1. Boomi の認証情報が正しいことを確認します：

   • メールアドレスが Boomi に登録されている必要があります
   • API トークンが有効である必要があります
   • アカウント ID がご自身のアカウントと一致している必要があります

2. 認証情報を直接テストします：

curl -u "[email protected]:your-token" \
  "https://api.boomi.com/api/rest/v1/YOUR_ACCOUNT_ID/Account/YOUR_ACCOUNT_ID"

---

貢献

貢献を歓迎します！以下の手順に従ってください。

1. リポジトリをフォークします
2. フィーチャーブランチを作成します（git checkout -b feature/amazing-feature）
3. 変更をコミットします（git commit -m 'Add amazing feature'）
4. ブランチにプッシュします（git push origin feature/amazing-feature）
5. プルリクエストを作成します

---

技術的な詳細

FastMCP のバージョン

現在、requirements.txt では FastMCP 3.1.1 に固定されています。以下が含まれます。

• OAuth 同意画面
• セッションミドルウェアのサポート
• Google OAuth プロバイダー
• サーバーのブランディング（カスタムアイコン、サイト URL）

セッション管理

• Starlette の SessionMiddleware を使用します
• セッションシークレットは GCP Secret Manager に保存されます
• 暗号署名付き Cookie により、リクエスト間でセッションが維持されます
• 最大有効期間：1 時間（設定可能）

プロファイル管理

• ユーザーごとのプロファイル数は最大 10 件です
• プロファイル名は必須です（デフォルトプロファイルはありません）
• プロファイル名はユーザーごとに一意である必要があります
• 例：「production」、「sandbox」、「dev」、「staging」

---

リソース

• 稼働中のサービス：https://boomi.renera.ai
• GitHub リポジトリ：https://github.com/RenEra-ai/boomi-mcp-server
• FastMCP ドキュメント：https://gofastmcp.com
• Boomi Python SDK：https://github.com/RenEra-ai/boomi-python
• MCP 仕様：https://modelcontextprotocol.io
• Boomi Platform API：https://help.boomi.com/docs/atomsphere/integration/platform_management/c-atm-platform_api_2cf25c18-ca93-43d2-a53e-048017d0b102/

---

ライセンス

MIT ライセンスの詳細については、LICENSE ファイルを参照してください。

---

サポート

問題、質問、機能リクエストがある場合は、以下を行ってください。

• GitHub で Issue を作成します
• 関連するログを添付します（シークレットは伏せてください）
• お使いの環境と再現手順を説明します

---

謝辞

• FastMCP フレームワークを使用して構築
• Boomi Python SDK と統合
• Model Context Protocol を実装
• Google Cloud Platform を利用

---

最終更新日：2026-05-18 ステータス：✅ 本番運用（安定） バージョン：FastMCP 3.1.1