Official description๐ โ๏ธ - Connect AI agents to industrial equipment across protocols and manufacturers: cross-OEM telemetry normalization, health index and failure prediction.
Config template (adjust for your client)
claude mcp add forge-mcp -- npx -y forge-mcp
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
0 โ ยท FoundryNet/forge-mcp ยท read from the repository page ยท (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list ยท type: MCP server
Harvest history
first seen 2026-10-09 ยท last seen 2026-10-16 ยท seen 32ร ยท listed by 7 sources
Score
score 703 ยท 7 sources ยท mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP ๆๅก. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository FoundryNet/forge-mcp๏ผfirst catalogued 2026-10-09๏ผlast seen 2026-10-16ใThere is no official certification or quality rating here โ we record sources and dates only.
Third-party quality signals
Forge by Foundry Labs โ Industrial Machine Intelligence
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