🐍 ☁️ - Connect AI agents to industrial equipment across protocols and manufacturers: cross-OEM telemetry…
Forge by Foundry Labs — Industrial Machine Intelligence
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
The cross-manufacturer industrial MCP server. Talk to any CNC, robot, or industrial
machine in natural language — machine identity, telemetry normalization across 46
vendor packs in 20 verticals, plain-English automation, and tamper-evident work records.
Hosted MCP over Streamable HTTP. 32 tools wrap the Forge v1 API: provision a stable machine
identity, normalize raw OEM telemetry into a canonical schema, query operational history,
parse and activate plain-English automations, predict failures (TimesFM), score fleet health,
and record every state-changing action as a verifiable, tamper-evident work record.
- **Website:** https://foundrynet.io/?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
- **Docs:** https://foundrynet.io/docs?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme · **Free key:** https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
- **MCP endpoint (Streamable HTTP):** https://mcp.foundrynet.io/mcp
- **Legacy SSE endpoint (still served):** https://mcp.foundrynet.io/sse
- **Health:** https://mcp.foundrynet.io/health
- **Server card:** https://mcp.foundrynet.io/.well-known/mcp/server-card.json
What it does
It normalizes raw OEM telemetry from **18 manufacturer families** into one canonical
vocabulary with thousands of confirmed field mappings — so an agent writes against one set
of field names whether the machine is a Fanuc CNC, a KUKA arm, or a Universal Robots cobot.
On top of that it turns plain-English instructions into structured automations (review then
activate), and records every state-changing action as a tamper-evident work record.
Architecture
Pure HTTP proxy. Every tool is a thin wrapper around https://forge.foundrynet.io/v1/*.
No state, no shared imports with forge-prod — separate Railway service, separate
dependencies (fastmcp + httpx).
**Tenancy.** The upstream call is made as the CALLER, not as this server. It used
to be made with the server's own FOUNDRYNET_API_KEY for every caller, with no
caller named: forge-prod scopes rows to the authenticated key's owner, so every
MCP tenant read and wrote inside one shared Forge account — and fleet_oee,
shift_report, list_agents and prediction_accuracy take no machine argument,
so they returned that whole account. The upstream hop now REFUSES to run when it
cannot name the caller: there is no fallback, because the only fallback is the
shared key. OAuth access tokens carry a key id but not a key, so they cannot be
presented upstream and are refused on tool calls with
tenant_context_unavailable.
POST /a2a/tasks and GET /a2a/agents go through the same gate function
(gating.enforce_call) as tools/call, by skill→tool mapping. They previously
authenticated the caller and then dispatched with no tier check, no cap and no
payment gate, which made the A2A route a free pass to the paid inference tools.
Tests and the release gate
The suite drives the real ASGI app over real Streamable HTTP through the real
gate; only Supabase and the upstream hop are substituted, and the upstream
substitute RECORDS requests, because what identity this server presents to
forge-prod is the thing most worth asserting. tests/test_rest_mcp_parity.py
measures free-tier parity against forge-prod's own _endpoint_to_billing_meter,
read out of its source at test time rather than copied.
CI runs the whole tree on every push and pull request
(.github/workflows/release-gate.yml, pinned to ubuntu-24.04): measured
**223 passed, 6 skipped, 229 collected** in 2m04s. The 6 skips are the checks
that read forge-prod's api.py off the local disk — 5 parity plus the
cost-ledger single-writer check — and they skip loudly, with their reason