FoundryNet — Industrial Machine Intelligence

Foundry Labs の Forge — 産業機械インテリジェンス

メーカー横断型の産業用 MCP サーバーです。自然言語で、あらゆる CNC、ロボット、産業機械と対話できます。機械の識別情報、20 の業種にわたる 46 のベンダーパックでのテレメトリ正規化、平易な英語による自動化、改ざんを検知できる作業記録を提供します。

Streamable HTTP によるホステッド MCP です。32 個のツールで Forge v1 API をラップし、安定した機械識別情報のプロビジョニング、OEM 生テレメトリの標準スキーマへの正規化、稼働履歴の照会、平易な英語による自動化の解析と有効化、故障予測（TimesFM）、フリートの健全性スコアリング、状態を変更するすべての操作の検証可能で改ざんを検知できる作業記録への記録を行います。

• ウェブサイト： https://foundrynet.io/?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
• ドキュメント： https://foundrynet.io/docs?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme · 無料キー： https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
• MCP エンドポイント（Streamable HTTP）： https://mcp.foundrynet.io/mcp
• レガシー SSE エンドポイント（引き続き提供）： https://mcp.foundrynet.io/sse
• ヘルスチェック： https://mcp.foundrynet.io/health
• サーバーカード： https://mcp.foundrynet.io/.well-known/mcp/server-card.json

できること

18 のメーカー系列から取得したOEM 生テレメトリを、数千件の確認済みフィールドマッピングを備えた単一の標準語彙に正規化します。これにより、機械が Fanuc の CNC でも、KUKA のアームでも、Universal Robots の協働ロボットでも、エージェントは同じフィールド名を使って処理できます。さらに、平易な英語の指示を構造化された自動化に変換し（確認後に有効化）、状態を変更するすべての操作を改ざん検知可能な作業記録に記録します。

アーキテクチャ

純粋な HTTP プロキシです。すべてのツールは https://forge.foundrynet.io/v1/* を呼び出す薄いラッパーです。状態を持たず、forge-prod との共有インポートもありません。別個の Railway サービスで、依存関係も別です（fastmcp + httpx）。

Claude Desktop / agent
        │ Streamable HTTP (/mcp) — or legacy SSE (/sse)
        │ Authorization: Bearer <the CALLER's Forge API key>
        ▼
  foundrynet-mcp on Railway
        │ gate: validate key → tier → cap → bind caller
        │ HTTPS, Authorization: Bearer <the SAME caller's key>
        │        X-Forge-Caller-Key-Id: <their forge_api_keys.id>
        ▼
  forge.foundrynet.io/v1/*  — scopes every row to that caller

テナンシー。 上流への呼び出しは、このサーバーではなく呼び出し元として実行されます。以前は、呼び出し元を特定せず、すべての呼び出しでサーバー自身の FOUNDRYNET_API_KEY を使っていました。forge-prod は認証済みキーの所有者に応じて行をスコープするため、すべての MCP テナントが単一の共有 Forge アカウント内で読み書きしていました。また、fleet_oee、shift_report、list_agents、prediction_accuracy は機械の引数を取らないため、アカウント全体のデータを返していました。現在、上流へのリクエストは呼び出し元を特定できない場合、実行を拒否します。代替手段はありません。唯一の代替手段が共有キーだからです。OAuth アクセストークンにはキー ID は含まれていますがキー自体は含まれていないため、上流への提示ができず、ツール呼び出し時に tenant_context_unavailable で拒否されます。

POST /a2a/tasks と GET /a2a/agents は、スキルからツールへのマッピングを通じて、tools/call と同じゲート関数（gating.enforce_call）を通ります。以前は、呼び出し元の認証後に、ティアチェックも上限も決済ゲートもなしでディスパッチしていたため、A2A ルートが有料の推論ツールを無料で利用できる抜け道になっていました。

テストとリリースゲート

python3 -m venv .venv && .venv/bin/pip install -r requirements.txt pytest pytest-asyncio
.venv/bin/python -m pytest tests/ -q        # 229 checks
scripts/release_gate.sh                     # tree, deps, import, suite, version

テストスイートは、実際のゲートを通して実際の Streamable HTTP 経由で実際の ASGI アプリを実行します。置き換えるのは Supabase と上流へのリクエストだけです。上流の代替処理はリクエストを記録します。このサーバーが forge-prod にどのような ID を提示するかこそ、最も確認する価値があるためです。tests/test_rest_mcp_parity.py は、forge-prod 自身の _endpoint_to_billing_meter を実行時にソースから読み取り、コピーしたものではなく、無料ティアの同等性を測定します。

CI は、プッシュとプルリクエストのたびにリポジトリ全体を実行します（.github/workflows/release-gate.yml、ubuntu-24.04 に固定）。測定結果は 223 件成功、6 件スキップ、229 件収集、所要時間は 2 分 4 秒でした。6 件のスキップは、forge-prod の api.py をローカルディスクから読み取るチェック（パリティチェック 5 件と、コスト台帳の単一書き込み元チェック）です。forge-prod は別の非公開リポジトリでランナー上にないため、理由を表示して明示的にスキップします。チェックがひそかに除外されたまま緑のチェックマークが付くより、スキップが明示されるほうが適切です。

デプロイ

cd ~/forge-mcp && git checkout main && git pull --ff-only && ./deploy.sh

手作業で railway up を実行しないでください。deploy.sh は順番に7つの処理を行います。そのうち5つは、デプロイで起きた特定の問題を受けて追加されたものです。

1. 作業ツリーがクリーンでない場合、またはブランチが main でない場合は処理を拒否します。railway up は作業ツリーをアップロードするため、未コミットの変更があると、何がデプロイされるのかを示すコミットがありません。
2. scripts/release_gate.sh を実行し、失敗した場合は処理を拒否します。意図的に、上書きするフラグは用意していません。
3. デプロイロック（~/.forge-mcp-deploy.lock、アトミックな mkdir）を取得し、アップロードと検証で複数のデプロイが同時に競合するのを防ぎます。
4. railway up が誤ったディレクトリをアーカイブする場合は処理を拒否します。$PWD ではなく、~/.railway/config.json にある最も近いリンク済みプロジェクトディレクトリを上へたどって使用します。このディレクトリは以前、$HOME のリンクを継承していましたが、そのリンクが指していたのは別のサービスでした。
5. stamp_build.py を実行し、build_info.json にコミット、作業ツリーの状態、アップロード対象ファイルの集合に対する content_hash、ビルド時刻を書き込みます。
6. railway up --service 162115b7-… を実行します。サービス ID を明示するのは、引数なしの railway up が同じ祖先リンクからサービスを解決するためです。
7. https://mcp.foundrynet.io/health をポーリングし、build.commit_short と build.content_hash の両方が、直前に書き込んだスタンプと一致するまで待ってから、ステータスを検証します。Railway が SUCCESS と報告しても、アップロードとビルドが成功したという意味にすぎません。新しいコンテナがクラッシュループに陥ると、古いコンテナが引き続きサービスを提供するため、デプロイは成功したように見えます。railway up はツリーをアップロードするため、コミットだけでなく content_hash も確認します。同じコミットでもツリーが異なれば、別のデプロイになります。

/health の build ブロックは forge-prod と同じキー名を使うため、1つの検証ツールで両方のサービスを読み取れます。build_info.json がない場合は、そのことを明確に示します。commit、content_hash、built_at は存在するものの値は null で、build_info.json absent — deploy did not run stamp_build.py と記載されます。これは、値が null の場合にフィールドが欠落しているように見えると、スタンプ済みのビルドと区別できないためです。

ツール（32）

識別とデータ：identify_machine、normalize_telemetry、query_machine_history、get_coverage、correct_mapping。自動化：create_automation、activate_automation、list_automations、disable_automation、delete_automation、restore_automation、query_webhook_history。予測（TimesFM）：predict、predict_breach、remaining_life、predict_batch、fleet_health、detect_anomalies、machine_intelligence、prediction_accuracy。運用：calculate_oee、fleet_oee、energy_consumption、shift_report、diagnose_machine、health_index。ガードレール：check_guardrail、list_guardrails。カーネル上のエージェント：get_agent_card、list_agents。作業記録：verify_record。デモ：fire_sandbox（watch → fire → settle の全ループ、カード不要）。

get_agent_card と list_agents は、カーネルインスタンスに接続されたエージェント（その機能、信頼スコア、マシンへのアクセス権）のみに対象を絞っており、サブスクリプションに含まれています。呼び出しごとの料金はかかりません。これらは、自分の設備上のエージェントを連携させるための運用ツールであり、プラットフォームを横断した検出には使えません。あらゆるフレームワークを対象とするプラットフォーム横断のエージェント信頼性については、Assay（assay.foundrynet.io）をご覧ください。verify_record は、完了した作業について、改ざんを検知できるハッシュ検証済みの記録を作成します。

無料プランでは読み取り専用ツールを利用できます。従量課金で、プレミアムの予測ツールと診断ツールを利用できます（https://forge.foundrynet.io/pricing?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme を参照）。

接続（Claude Desktop、Cursor、任意の MCP クライアント）

claude mcp add --transport http foundrynet-forge \
  https://mcp.foundrynet.io/mcp \
  --header "Authorization: Bearer fnet_YOUR_KEY"

または、mcp-remote ブリッジを使い、claude_desktop_config.json から接続できます。

{
  "mcpServers": {
    "foundrynet-forge": {
      "command": "npx",
      "args": ["-y", "mcp-remote",
               "https://mcp.foundrynet.io/mcp",
               "--header", "Authorization:Bearer ${FNET_KEY}"],
      "env": { "FNET_KEY": "fnet_…  (get a free key at foundrynet.io/signup)" }
    }
  }
}

レガシー SSE（https://mcp.foundrynet.io/sse に対する --transport sse）は既存の設定との互換性のため引き続きサポートされますが、新しい連携では上記の Streamable HTTP /mcp エンドポイントを使用してください。

無料の fnet_ キーは https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme で取得できます（カード不要、normalize を50回利用できます）。

必須環境（サーバー側）

変数	必須	デフォルト
FOUNDRYNET_API_KEY	ツールの実行では使用しなくなりました	起動時の設定レポートでのみ保持されます。ツールの呼び出しは呼び出し元自身のキーで実行されます
SUPABASE_URL / SUPABASE_SERVICE_KEY	ゲーティングに必要	未設定の場合、ゲーティングは無効になり、フェイルオープンします
MCP_JWT_SECRET	いいえ	未設定の場合、OAuth トークンの発行は無効になります（503）。キー認証には影響しません
FORGE_BASE_URL	いいえ	https://forge.foundrynet.io
PORT	いいえ	8080（Railway が自動的に設定します）
REQUEST_TIMEOUT	いいえ	120（秒）

ファイル

• mcp_server.py — サーバー（32 個のツールと /health および /.well-known/mcp ルート）
• gating.py — クライアントごとのティア別ゲーティング（Free と Pro のツール／クォータ制御）
• server.json — MCP レジストリのメタデータ（名前、説明、キーワード、リモートエンドポイント）
• smithery.yaml — Smithery の掲載情報メタデータ
• requirements.txt — fastmcp>=3.4.5,<4、httpx>=0.27、PyJWT>=2.14.0、supabase、stripe
• tests/ — 動作テストスイート（認証、テナント管理、同等性、冪等性、キャッシュのスコープ）
• scripts/release_gate.sh — デプロイ前に、対象のコミットで成功している必要があります
• deploy.sh — 本番環境への唯一のデプロイ手段。ゲート制御、ロック、スタンプ付与、検証を行います
• stamp_build.py — build_info.json を書き込みます。/health の build ブロックが参照する情報です
• Procfile — Railway の起動コマンド（スタンプを付与してから python mcp_server.py を実行します）
• .github/workflows/release-gate.yml — CI。プッシュ時と PR 時に全テストスイートを実行します

ライセンス

プロプライエタリ（商用）。© Foundry Labs LLC. お問い合わせ先：[email protected]